I've been using the git branching strategy outlined here http://nvie.com/posts/a-successful-git-branching-model/
So far its been working really well for me.
The question I often find my self asking is while working on a feature branch I'll end up needing to implement code that is relevant to the entire project. What is the best way to handle these situations?
a) Check out the main development branch, commit the change and rebase the feature branch off of develop.
b) Make the change on the feature branch, then merge back into develop so that other feature branches can have access to that code.
c) Create a new branch for the common code and merge that into Develop as well as any feature branches that need to use it.
Here's another question. How often do you merge a feature branch back into the main development branch? Do you wait until the feature is completely done then merge it and delete it? Or do you merge back into develop several times throughout its lifetime any time that it's stable?
The two primary branches in Git flow are main and develop. There are three types of supporting branches with different intended purposes: feature, release, and hotfix.
A branching strategy helps define how the delivery team functions and how each feature, improvement, or bug fix is handled. It also reduces the complexity of the delivery pipeline by allowing developers to focus on developments and deployments only on the relevant branches—without affecting the entire product.
Feature Flag Branching Strategy for Continuous Delivery The advantage is that all work can be done right from in the mainline. This means less branches and minimal merging. By using the feature toggle, portions of the code can be turned on or off for the build process.
I like option a/, but the reality is, when you are doing commits after commits, you only realize that some of them are actually common code much later in the process.
When that happens on a feature
branch (that usually hasn't been pushed yet and shared with), I prefer doing an interactive rebase
, re-ordering the commits for common code first, and then merging the master
branch to the feature
branch for those n first commits (fast-forward merge).
From there, I can rebase onto master
any other branch that have to benefit from those new common features.
Merging back a feature branch only makes sense if the state of that feature branch must be visible for others (because you want to push master
while keeping feature
branch private to your repo).
If the rest of the development:
feature
branchmaster
and feature
branches), then I prefer merging feature
branch later.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With