You already use git, and you heard about the git workflow, but you never used it before ? Here is a short explanation. You can read a more complete explanation here
Workflow: Pros & Cons
“elegant mental model that is easy to comprehend and allows team members to develop a shared understanding of the branching and releasing processes” nvie, father of this workflow
Pros:
- fits any project
- avoid complex git conflicts
- best method if working with others
Cons:
- more complex than the simple monobranch pull push
- slows you down if you push releases often
When to use it
All the time, except if you are alone on your project.
If you are alone (probably on some side-project) then this workflow may slow you down, but it is still a good practise.
Summary
Explanations: master VS develop
The central repo, usually refered to as origin, holds two main branches:
- master (production-ready)
- develop (latest delivered development)
When the code in the origin/develop branch reaches a stable point and is ready to be released,
we merge it into origin/master with a release number
Explanations: Temporary branches
- Release
- Hotfix
- Feature
1. Release branches
WHY
Preparation of a new production release.
minor bug fixes & preparing meta-data for a release (version number, build dates, …)
NAMES
release-*
REPOS
origin repo
CODE
- create branch:
git checkout -b release-1.2 develop
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”
- changing the version number:
Here, bump-version.sh is a fictional script that changes some files to reflect the new version. (This could of course be a manual change)
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"
- merge with origin/master
git checkout master
git merge --no-ff release-1.2
git tag -a 1.2
- merge with origin/develop as well
git checkout develop
Switched to branch 'develop'
git merge --no-ff release-1.2
Possible action on release branches:
This new branch may exist there for a while. During that time, bug fixes may be applied in this branch (rather than on the develop branch).
But adding large new features here is strictly prohibited (They must be merged into develop).
2. Hotfix branches
WHY
Fix immediatly a critical bug in a production version
NAMES
hotfix-*
REPOS
origin repo
CODE
- create branch
git checkout -b hotfix-1.2.1 master
./bump-version.sh 1.2.1
git commit -a -m "Bumped version number to 1.2.1"
- commit your fix, merge, and delete the hotfix branch
git commit -m "Fixed severe production problem"
git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
One exception: when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop.
3. Feature branches
WHY
Develop new features
NAMES
anything except master, develop, release-*, or hotfix-*
REPOS
the developer repo
CODE
- create branch
git checkout -b myfeature develop
- merge your code and delete the branch
git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop
Note about –no-ff:
The –no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature
It is important when you have to revert a whole feature (= a group of commits). It is a true headache without the –no-ff! see this illustration:
