The common reaction was to think that each person has their own branch to work with, rather than a branch serving as a unit of work. This highlights one barrier to better collaboration, but also can limit the effectiveness that branching in Git provides.
The best way I've found to deal with branching in Git is as follows:
- Branch - When starting a new feature, branch from the head of the development branch. This ensures you are working with the latest deployable code.
- Code - Your regular development work. Commit as needed as it backs up your work, as well as allowing for collaboration.
- Merge - When your coding is done, merge it back into the development branch.
- Delete - After you merge the branch back to the development branch, delete it. Leaving it just creates clutter, and clutter that goes quickly out of date at that. (if needed) Repeat - If it turns out steps 1-4 didn't cover the feature, start the process again. Don't worry about maintaining a branch for the possibility that feature still needs to be worked on.
The ideal is that branches are short-lived. The longer a branch lives, the more likely there are to be merge conflicts when it's brought back.
With JIRA and Bitbucket, it's easy to create a branch named for a particular feature. So anyone seeing a branch will at a glance know what unit of work that branch is for. And since this can be done multiple times, having to recreate a branch when more aspects of a user story emerge is simple.