It depends on the project requirements and internal culture, and whether your a rebaser or not...
One of the most popular workflows is git flow.
Git flow is a successful workflow...
Things I would change with git flow
- Branch and code review bug fixes (like the feature branches).
- Rebase all bug/feature branches onto develop (rather than merging develop into the branch).
- Use 'master' instead of 'develop' - If you need a emergency severe bug fix then I would do the following:
What it would look like before:
v1 v2 | | o-o-o-o-o-o-o master
You would think you could only add a fix into master.. and deploy ALL the changes. Your wrong...
git checkout v2 git commit -m "Fixes foobar"
looks like (detached HEAD):
v1 v2 | | o-o-o-o-o-o-o master \ -o
git tag v3 looks like:
v1 v2 | | o-o-o-o-o-o-o master \ -o v3
then merge v3 into master (dont rewrite history):
git checkout master git merge v3 v1 v2 | | o-o-o-o-o-o-o-m master \ / -o---- v3
or rebase master onto v3 with (all current open feature branches will need to be rebased onto the NEW master (new commits) and remove the old master commits.
git checkout master git rebase v3 v1 v2 | | v3 o-o-o-o | \| -o-x-x-x master
if you rewrote master (ensure nothing TAGGED is rewritten! just commits in 'master' which isnt in production yet).
tell developers to:
git fetch git checkout feature-x git rebase master --onto origin/master
Use the above command to recover from master being rewritten carefully. Please learn exactly what it is doing. Which is... take commits from feature-x and local master.. and apply it on top of origin/master.