BCTO is a service that provides analysis based on developers' Git activity data.
Therefore, understanding basic development terms will make interpreting reports and communicating with the development team much easier.
Below are the terms necessary for non-developer managers.
[Git]
Git is a tool that developers use to record and manage the history of code changes. It is a work logging system that records who modified what, when, and why.
[Github]
This is a representative platform for managing Git records online. Most developers store their work logs on GitHub, and BCTO analyzes the records left on GitHub to provide monitoring data.
[Commit]
A commit is a record of a unit of work, indicating "this task was completed at this time." Developers make commits whenever they finish a certain amount of work, such as adding a feature, making a modification, or fixing a bug.
[Commit Message]
A commit message is a one-line note explaining "what was done in this commit." It provides hints about the work, such as 'Fixed login error' or 'Added exception handling for payment API.'
[Repository]
A repository is a project-level space that contains the code and history of a single project. It can be thought of as a project folder and is a space that holds data.
[Line of Code]
Line of code refers to the number of lines added, modified, or deleted. However, a large number of lines does not necessarily mean better work, as simpler modifications can often be more valuable.
Below is a developer work guideline for effectively utilizing BCTO. Managers do not need to fully memorize this.
<BCTO Usage Guide for Developers>
This commit writing standard is not for the purpose of simply unifying the format.
It is intended to improve code review and collaboration efficiency by clearly recording the developer's work intent, and to enhance the accuracy of development pattern analysis provided by BCTO. Consistent commit logs serve as a foundation for recording individual developer work tendencies without distortion.
Commit Log Type Identification Criteria
All commit messages should be written using an identifier to clearly indicate the nature of the work. The identifier should be placed at the very beginning of the commit message, followed by a concise description of the work after a colon.
(Example) hotfix: Remove console.log
Identifiers are case-insensitive, but using standard tags is recommended for team consistency.
Commit Log and Ticket Linking Criteria
Commit messages must specify the ticket associated with the work. This allows tracking which requirements or issues a particular task is linked to. Tickets should be written using their identifier number or exact title, enclosed in square brackets as the default format.
(Example) update: Improve statistics logic structure [BCTO-API-17]
[BCTO-API-18] update: Modify statistics API
When using ticket titles, they must be written exactly as they appear. If an identifier code exists, using the code is recommended.
<Usage Guidelines by Tag>
Use when adding a new feature.
Use when fixing a bug.
Use for changes related to the user interface, such as CSS modifications.
Use when a change occurs that breaks compatibility with existing APIs or features.
Use for critical bug fixes that require immediate action in the production environment.
Use for style modifications that do not affect functionality, such as code format changes or fixing missing semicolons.
Use for refactoring tasks that improve code structure without changing functionality.
Use for adding or modifying comments.
Use for document modifications.
Use for adding or modifying test code. This applies when there are no changes to the actual production code.
Use for tasks that do not involve changes to the production code, such as build configuration, package manager settings, or environment setup changes.
Use when renaming or moving files or folders.
Use when only file deletion operations are performed.
Commit messages should be written based on the unit of work. Do not include tasks of different natures in a single commit.
The description of the work should not be excessively detailed but should be clear enough to understand the intent of the change. Avoid using colons and square brackets except in the two cases defined in this guide.
