A very simple git workflow to keep the team happy!
The gist,
mastermust always be deployable.- all changes made through feature branches (pull-request + merge)
- rebase to avoid/resolve conflicts; merge in to
master
# everything is happy and up-to-date in master
git checkout master
git pull origin master
# let's branch to make changes
git checkout -b my-new-feature
# go ahead, make changes now.
$EDITOR file
# commit your (incremental, atomic) changes
git add -p
git commit -m "my changes"
# keep abreast of other changes, to your feature branch or master.
# rebasing keeps our code working, merging easy, and history clean.
git fetch origin
git rebase origin/my-new-feature
git rebase origin/master
# optional: push your branch for discussion (pull-request)
# you might do this many times as you develop.
git push -u origin my-new-feature
# optional: feel free to rebase within your feature branch at will.
# ok to rebase after pushing if your team can handle it!
git rebase -i origin/master
# But when you do that overwrite your published branch
# See this discussion: http://stackoverflow.com/questions/33123802/merge-after-rebasing-feature-branch-in-git/33125444?noredirect=1#comment54063368_33125444
git push origin my-new-feature --force-with-lease
# merge when done developing.
# --no-ff preserves feature history and easy full-feature reverts
# merge commits should not include changes; rebasing reconciles issues
# github takes care of this in a Pull-Request merge
git checkout master
git pull origin master
git merge --no-ff my-new-feature
# Then get rid of the feature branch
git branch -d my-new-feature
# Delete the branch also on origin: http://stackoverflow.com/questions/2003505/delete-a-git-branch-both-locally-and-remotely/2003515#2003515
git push origin --delete my-new-feature
# And prune it for it to stay gone
git remote prune origin
# optional: tag important things, such as releases
git tag 1.0.0-RC1Using the above workflow we can maintain a really nice git history,
