基于另一个功能分支合并功能分支，回到 master

Question

As often the case withour team, changes on the next release need to start before the current release is completely tested and merged back into master, from which to start a new branch from for the next release.

So I can create a new feature branch based on the current feature-branch, and start work on the next release there. The problem is that this sometimes gets messy if one doesnt remember that you actually still have another feature branch or something else changes that lead to merge conflicts.

Something like this. So in this case, Feature-1 is being tested, but for one reason or another, we wont do a release from here, rather work will continue on Feature-2. However, notice there is a commit that happened AFTER Feature-2 was created. So, correct me if Im wrong, but one way to handle this if in fact Feature-1 was NOT going to be released, then ... assuming the head is pointed at /Feature2, will the following get the change from Feature-1 AND then everything back into master?

git merge Feature-1 
git push origin Feature-2
git checkout master
git merge Feature-2
git push origin master

Answer 1

If you have one "feature branch" per release, they're not feature branches. (Unless you're doing continuous delivery, in which case you just release master.)

Feature branches should be about a single feature, preferably one that either isn't going to take very long, or isn't going to mess much with other code. Once that feature is done it should be tested, merged, and the branch deleted never to be used again.

Unless you explicitly need something in an incomplete feature branch, don't branch feature branches off other feature branches . With short, sharp feature branches this should rarely be an issue. Even then often it's just a bug fix or refactoring. Try to extract just the bit you need, get that merged, and continue on your way.

If you often find yourself needing to branch off other feature branches, your feature branches are doing too much.

That's your first problem. If you use feature branches correctly, this should be a rare a problem. Doing too much in one branch complicates everything.

---

Let's sort out how Git does branches. Unlike other version control systems, commits connect to other commits and branches are just labels. Branches have no life of their own. Your situation looks like this.

                    G - H - I [feature-2]
                   /
          D - E - F - K [feature-1]
         /
A - B - C [master]

The kinks are entirely notional. We can also look at it like this.

                    K [feature-1]
                   /
          D - E - F - G - H - I [feature-2]
         /
A - B - C [master]

Looked at this way it should be more clear what is in feature-2 . All of master , most of feature-1 (which is untested), and all of feature-2 . feature-2 cannot be done until feature-1 is done, and that sort of dependency is undesirable.

---

If you're working on top of a branch and want to stay up to date, the simplest thing to do is to git rebase upstream-branch . This will rewrite your commits as if they were written on top of the upstream-branch all along. This avoids a bunch of confusing notional merges.

Before
                    G - H - I [feature-2]
                   /
          D - E - F - K [feature-1]
         /
A - B - C [master]

git checkout feature-2
git rebase feature -1

After
                        G1 - H1 - I1 [feature-2]
                       /
          D - E - F - K [feature-1]
         /
A - B - C [master]

feature-2 can then be safely pushed with git rebase --force-with-lease . People can safely update their copy of feature-2 if they pull with rebase, instead of merging. git pull --rebase or setting pull.rebase = merges in your Git config.

Again, this should be rare .

---

But, as above, feature-2 should probably never have been built on top of feature-1 at all. If they were small and independent features, it would look like this.

          D - E - F - K [feature-1]
         /
A - B - C [master]
         \
          G - H - I [feature-2]

Now you can have multiple independent features being developed and tested simultaneously. When they're done, in any order, they're merged into master and deleted. master is always in a known good state and can be released at any time. Releases are tracked with tags, not branches.

git checkout master
git merge feature-2
git branch -d feature-2

          D - E - F - K [feature-1]
         /
A - B - C ---------- J [master]
         \         /
          G - H - I

That's referred to as a "feature bubble".

Everyone else then rebases their feature branch on top of master to update, deals with any conflicts or breakage, and goes about their business.

git checkout master
git pull
git checkout feature-1
git rebase master

                       D1 - E1 - F1 - K1 [feature-1]
                      /
A - B - C ---------- J [master]
         \         /
          G - H - I