Keep It Simple and Git 10/12/2014
TL;DR: Branch only from master, merge back when done and immediately deploy.
Git proposes a branch system with the possibility to merge them together, allowing you to separate released code from work in progress one.
Git flows have been created to help you keep the same process in your team. In this article, we'll have a look at @jbenet's simple git branching model:
mastermust always be deployable.- all changes are made through feature branches (pull-request + merge)
- rebase to avoid/resolve conflicts; merge in to
master
Working on a change
Changes can be new features, bug fixes, enhancements. They're all coming from master:
git checkout master
git checkout -b my-changes
Making the change ready
Once you're happy with your branch, you need to update it with the last changes from master:
git checkout master
git pull --rebase
git checkout my-changes
git rebase master
git push -fu origin my-changes
Note:
rebasewill rewrite your commits, their dates will be changed (therefore their hash will be changed).
Check your tests, the coding standards and ask for a code review.
Managing conflicts
You can list conflicts (if any):
git status
Edit your files and then mark them as solved:
git add <file>
When all conflicted files have been resolved, you can continue:
git rebase --continue
When to merge
Here's a to do list you can use to know if a branch is ready to be merged:
- is it compliant with the coding standards?
- has the code been reviewed?
- do the tests pass?
- has the Quality Assurance team checked the feature?
- will someone be available in the next hour in case of emergency?
- does the product owner want this feature now?
Deploying the new change
If everything is ok with your change, then you can merge it into master:
git checkout master
git merge --no-ff my-change
git push
git push origin :my-changes
git branch -D my-changes
It's now time to deploy! You can make a tag:
git tag -a <version>
git push --tags
Conclusion
Make small changes, release often.