-
Notifications
You must be signed in to change notification settings - Fork 21
Git Flow
We follow the git-flow model.
The trunk branch should always contain the latest stable/production code, and the develop branch is used for the next normal release.
The develop branch is the staging area for the next major or minor release.
We use Release branches for preparing Major/Minor releases.
Release branches should be created with develop as the base branch.
Release branches should be created with the prefix release/ e.g. release/4.9.0.
Release branches should be merged into both trunk and develop.
We use Hotfix branches for preparing Patch releases.
Hotfix branches should be created with trunk as the base branch.
Hotfix branches should be created with the prefix hotfix/ e.g. hotfix/4.9.4.
Hotfix branches should be merged into both trunk and develop.
We use Feature branches for preparing new planned features.
Feature branches should be created with develop as the base branch.
Feature branches should be merged back into develop.
When naming other branches for specific fixes, it’s important to ensure the branch is clearly understandable by everyone on the team, as well as others outside of the team who may need to scan the branch list to quickly find the one branch they’re looking for.
Where possible we use the following structure :
(break|add|update|fix|tweak|dev|doc)/(issue-number)-short-slug
For example
fix/1122-incorrect-order-status
Fix branches should be merged into the agreed Release or Hotfix branch.
The beginning/prefix identifies what is being done (e.g. adding, updating, fixing, etc.) or identifies the type of thing being prepared (e.g. release, hotfix, etc.) in cases where git-flow is being followed.
After the prefix the issue number can be added – this is useful for those who prefer to identify pull requests using the issue number as it helps with scanning the list quickly.
Lastly, you can add a short slug (WordPress style) – this is useful for those who don’t remember what every issue number means. Something that’s 2-3 words long that is sufficiently descriptive and unique so as to not cause confusion is fine. Remember, it also may need to be typed in, from time to time, so consider that when writing this. Don’t spend too long thinking of the perfect slug. If it means something to you and to others on the project, that’s good enough.