- Reserve the master branch for production, staging, and hotfixes
- Write new code on a feature branch
- Rebase feature branches onto master as often as reasonable
- Merge feature branches into master with a no-ff, no-squash merge commit
- Preserve branch names for reference
git fetch # ensure origin/master is fresh
git checkout -b feature-branch origin/master # create local feature branch based on origin/master
git push -u origin feature-branch # create remote feature branch and track it locally
git fetch # get latest remote master
git rebase origin/master # rebase onto latest remote master
git push -f origin feature-branch # push local rebased changes to remote
git checkout master # start on master
git pull # ensure master is fresh
git checkout feature-branch # change to the feature branch
git pull # make sure the feature branch is fresh
git rebase master # resolve potential conflicts
git checkout master # change to master
git merge --no-ff feature-branch # create the merge commit
git push # avoid conflicts
git branch -d feature-branch # delete local feature branch
I'd probably change two things:
git push -u
, at least in newer versions of gitgit push origin feature-branch -f
to be safe.Also, it'd be good to address the naming of feature branches. For instance, at Svpply each branch was tied to a ticket in Redmine where we could discuss and track the progress of the feature. The branch names took the format
123-ticket-title-here
where123
was the ticket number andticket-title-here
was a git-friendly reformatting of the ticket title. These titles did their best to be grok-able in terms of what the purpose of the branch was, but the ticket always provided additional context if need be. And the sequential numbers as a prefix helped date them to some extent; it was easy to see which branches were relatively current and which ones were abandoned.P.S. If you haven't already installed an autocomplete script for git, you should.