At work we adopted use of the simple branching strategy for our use of git. The goal of this approach over something like Git Flow is to reduce the complexity of branching and create a workflow that is easy to follow.
What is 'Simple'
At its core it means following these two rules:
mastershould alway be deployable
- feature branches are
In addition to the basic semantics we've evolved the workflow to include two more rules.
Story Card == Feature Branch
To help keep branches small we scope each feature branch to just one story card from our Kanbanery board. This also means that we create a lot of branches so to help manage the naming we include the card number in the branch name, such as
This makes it simple to find branches and ensure they stay in sync with corresponding card.
Meaningful Merge Messages
If you are using Github and Pull Requests then you already have the benefit of slightly better merge commit messages which include the Pull Request number. In most of our projects, however, it's also useful to include the story card number in the commit for tracking purposes. This also gives us more values to search.
To do that we developed a standard merge commit message format.
<feature summary> [<card system abbrev> #<number>] (<source abbrev> #<number>) <feature long description, optional>
Filled out it looks something like this:
Refactor API to proper 404 responses [KB #1142645] (GH #67) Updated the API so when a user does not have access to a resource they will get a 404 status code rather than 403.
To make filling out this message even easier I'd suggest taking a look at the gitprettyaccept gem. It allows you to create a merge commit message template and automatically removes local and remote branches after the merge.
Optimizing processes for ease of use and maximum effectiveness is always a moving target, but this strategy has been working well on the projects I've used it.
For practical explanation of 'simple' branching with examples checkout this gist.