We're currently in the following situation, where a feature branch has been branched for a sub-feature branch (like, working on backend and frontend things for the same feature):
o
|
o development
|\
| o feature-a
| |
| o
| |\
| | o feature-a-sub
| | |
| | |
| \
| o merged feature-a into feature-a-sub
| /
o feature-a-sub merged into development
| |
| o feature-a with future work on it
|
o development
A developer first merged feature-a into his feature-a-sub branch to be up-to-date, and then merged his feature-a-sub into development. Whereas the initial feature-a branch is still existent, and not yet finished.
In my point of view, this yields the problem that the feature-a branch is now rendered obsolete, as all changes are merged into feature-a-sub and then into development. In addition, work has continued on feature-a, which leads to future merge conflicts and a lot of manual labor.
Where did we take the wrong turn, and how would a proper workflow with less trouble look like?
1 Answer 1
One should only merge to and from parent branch. For feature-a-sub, this is feature-a, not development.
Merging to the grandparent branch means that the reason that the parent branch was created hasn't been fulfilled, and yes, as noted this does create future problems where development continues on feature-a and development leading to an increased divergence of the code lines and more conflicts down the road.
This was assuming that feature-a-sub depended on the code in feature-a. If feature-a-sub was instead independent of feature-a, it shouldn't have been branched from feature-a at all and instead should have been branched (and merged) into development.
If feature-a needed feature-a-sub to work (not sure it did as feature-a continued work without a merge of feature-a-sub into it), and feature-a-sub was independent of feature-a, feature-a-sub should instead have been feature-b with a branch from development, a merge back into development, and then either a merge of development or feature-b (if one doesn't want to pick up other changes from development) into feature-a.
The workflow should either be:
o
|
o development
|\
| o feature-a
| |
| o
| |\
| | o feature-a-sub
| | |
| | |
| | |
| | o merged feature-a into feature-a-sub
| |/
| o feature-a-sub merged into feature-a
| |
| o feature-a with future work on it
|
o development
or
o
|
o development
|\
| \
| \
| o feature-a
|\ |
| b | feature-b
| | |
| | |
| | |
| b | feature-b complete
|/ \|
o o feature-b merged to development and feature-a
| |
| o feature-a with future work on it
Related - a favorite read of mine on the philosophy of branching: Advanced SCM Branching Strategies. While the white paper is targeted to centralized version control systems, the ideas behind the roles each branch can take are important in making sure you understand what is going on and can reason about what should be done next with any given branch.