-
Notifications
You must be signed in to change notification settings - Fork 0
Branch Convention
| Branch Type | Branch | Description |
|---|---|---|
| Code Flow | master | This is the main branch for production. |
| develop | Base branch should always be master | |
| Temporary | feature | Base branch should always be develop. |
| release | Base branch should always be develop. | |
| hotfix | Base branch should be master. |
In any software, every day many branches are created and pushed to the GitHub repository. Having a manageable code repository is important and mandatory when working with a team.
These branches which we expect to be permanently available on the repository follow the flow of code changes starting from development until the production.
All new pull requests related to features and bug fixes shoulb be merged into this branch after code reviews. Resolving developer codes conflicts should be done as early as here.
This is the main branch for production. Nothing should be directly pushed into this branch except for the hot-fix errors and the develop branch after the complete testing of the issues or bug fixes.
As the name implies, these are disposable branches that can be created and deleted by need of the developer or deployer.
Any code changes for a new module or use case should be done on a feature branch. This branch is created based on the current development branch. When all changes are Done, a Pull Request/Merge Request is needed to put all of these to the development branch.
Examples:
- feature/30-dark-theme
This branch is used to prepare for the release and is utilized during the QA period just before the release.
Examples:
- release/21-mail-not-sending
If there is an issue in the master branch then it needs to be fixed immediately, then that issue should be created as a Hotfix. The hotfix branch should be pulled from the master branch.
Examples:
- hotfix/44-0disable-endpoint-zero-day-exploit
- hotfix/10-increase-scaling-threshold
- Each commit represents a single unit of work.
- Avoid splitting a single task into multiple commits.
- Do not include multiple tasks in a single commit.
Commit messages are written explicitly to describe what work has been done.
Gitmoji [#ISSUE_NUMBER] Subject
Body (optional)
Footnote (optional)
🎨 [#5] Create Git Convention
- Branch Convention
- Commit Convention
See Also : #100, #120
| Type | Description |
|---|---|
| BUG | Bug or error resolution. |
| TEST | Addition of test code. |
| FEAT | Implementation of new features.. |
| DOCS | Revisions to documentation such as README or wiki. |
| UI | Screen operations of a service or product used by the users. |
| REFACTOR | Refactoring that improves existing code without altering internal logic. |
| DEPLOY | The task of deploying the developed program source code to the system for integration. |
| CI/CD | Automating the application development stages to deliver applications to customers at shorter intervals. |
| HOTFIX | Patch programs that are urgently deployed for bug fixes, vulnerability enhancements, or performance improvements occurring during product usage. |
- describe the content of the commit.
- Provide a more detailed explanation of the commit's content when necessary.
- Use the Body when the description may be ambiguous based on the Subject.
- When developing new features, Picker creates a feature branch from the develop branch, and once the development is completed, sends a Pull Request for merging.
- Furthermore, all Pull Requests are requested based on the associated issues.
[#ISSUE_NUMBER] [ISSUE_TITLE]
Body (Pull Request Template)
Footnote (optional)
#5 Create Git Convention
🎯 Related issue
- Issue Create Git Convention #5
🛠 Implementation
🔍️ summary
- Create Git Convention
📌 tasks
- [X] Branch Convention
- [X] Commit Convention
Close #5