Friday, October 23, 2020

Best Practices for Managing Feature Branches

Feature branches are a popular source code management tactic used to manage and coordinate changes made by development teams. Developers create a feature branch is created from the main branch (typically master) and then merge the changes made to that feature branch back to the main branch when they are complete. This isolates changes made for a specific feature and limits the effect of feature enhancements on other team members until the change is ready.

When using feature branches, it's rare to directly develop using the master branch. In the example below, one developer might be working on a change called "feature 1" while another developer works on a separate enhancement "feature 2".  Each developer writes/commits code in isolation in separate branches.  When the enhancement is ready, that developer creates a pull request and merges the change back into master. The diagram below illustrates this example. Each bubble is a commit. 



Observations

The longer a feature branch lives, the higher the probability of integration problems when the feature branch is merged into master. In the example above, the developer for feature 2 might make changes that conflict with the changes made for feature 1. The longer a feature branch lives, the higher the likelihood that change conflicts occur.

Feature branches work best if the branch contains one targeted enhancement. Including multiple changes in a feature branch often lengthens the time the feature branch lives. It also makes code reviews more difficult as the change is more complicated.

The more developers working on a codebase, the more discipline the team needs regarding source control and change management. Even with feature branches, the chance of code integration issues on merge increases with each developer added. That is because the more developers making changes, the higher the probability of integration issues and code conflicts. The higher the probability that multiple developers are working on the same section of code at the same time. Yes, each developer is working in a separate branch, but those changes will be merged to master at some point.

Recommended Tactics

Feature branches should have a short life. Most of my feature branches live for less than one business day. They are narrow and targeted. If I need to make a "large change", I break it up into separate smaller changes using multiple feature branches.If a feature branch must live longer due to forces beyond my control, I rebase or merge in changes from master and address any needed merge issues.

Feature branches should represent changes from one and only one developer. When multiple developers make changes to the same feature branch, the chance of one developer of that feature branch negatively impacting other developers on that same feature branch greatly increases.

Feature branches should be removed after they are merged into master. If you don't, the resulting branch pollution will become confusing. The list of existing branches will grow to a large number. It won't be obvious which branches are active and which are historical.

Frequently rebase the feature branch against the master branch. Definitely rebase before merging back into the master branch (or creating a pull request which will accomplish the merge when completed). More importantly, it will consolidate changes made for the feature branch in git history. It's common for developers to merge rather than rebase to incorporate new changes from master.  Using merge is more intuitive.  That said, rebase makes git commit history easier to interpret as feature branch commits will be consolidated.  Additional information on rebasing can be found here.

An example series of commands to accomplish this follows:

git checkout master
git pull
git checkout feature_branch
git rebase master



Some teams prefer to squash commits when merging the feature branch into the master branch. This consolidates log history on the master branch as feature branches typically have multiple commits. For example, feature 1 with three committed changes can optionally be merged into master as one change.  This makes git history more concise and easier to read. Squashing commits will lose commit history detail on the feature branch, however.

Promptly respond and participate in requested code reviews. Most teams will use pull requests with code reviews as part of the process for merging feature branches into the master branch. It is common for developers to be slow to perform code reviews as they don't want the distraction. The trouble is that as long as the pull request is open, the feature branch it's associated with lives with it. The longer the feature branch lives, the greater the chance of integration issues.

Conclusion

Thanks for taking the time to read this article. I'd love to hear your thoughts.


No comments:

Post a Comment