2

My git flow looks like the following:

                        x - x (feature/branch-a)
                      /
(master) x- x (develop) 
                      \
                        x - x (feature/branch-b)

There is currently a commit and PR for branch-a to develop. I'll be waiting a bit before branch-a PR is accepted but branch-b reuses quite a bit of logic from branch-a that I need.

Before I start copying code from branch-a to branch-b, is there a better way to merge this code without creating a feature branch-b off branch-a.

TTT
  • 22,611
  • 8
  • 63
  • 69
user0000001
  • 2,092
  • 2
  • 20
  • 48
  • 1
    I honestly didn't think it would be this simple, considering that the remote branch will eventually go away once the PR is accepted. Yes, that seemed to work. This won't produce any conflicts so long as `branch-a` PR is accepted / merged to `develop` first? – user0000001 Apr 30 '21 at 13:05
  • 1
    Use rebase to move feature-b around. You can put it on top of feature-a and then rebase it on top of develop or master when feature-a is merged. I am not saying that it's a no-brainer. You might have to use the rebase where you provide revisions to _skip_ (like `git rebase --onto master feature-b~3 feature-b` to only rebase the last 3 revisions from feature-b), but it's very simple to pull off. – eftshift0 Apr 30 '21 at 13:28
  • 3
    Rule of thumb: git doesn't care about your branches, only your commits. "Merge branch-b to develop" just means "find commits on branch-b that aren't already on develop, and apply those changes". – IMSoP Apr 30 '21 at 13:28
  • 2
    Unfortunately the title of this question caused people to think you were asking *how* to do the merge, rather than *if* you could/should. I've changed the title and voted to reopen. – TTT Apr 30 '21 at 17:49

2 Answers2

1

I would highly recommend taking the fancy rebase approach described in eftshift0's comment. It's not trivial because you first need to learn and become comfortable with doing git rebase --onto. But once you really git it, you can surgically move your commits around a repo at will.

With that in mind, it actually doesn't matter if you merge feature/branch-a into feature/branch-b right now, or rebase B onto A right now like you said you wanted to avoid. Both methods will enable you to keep working, and once A's PR is merged into develop you can just fancy rebase your own commits onto the latest develop in preparation for your PR. Note you don't have to rebase and clean up your branch before your PR, but if you don't, you may be pulling in duplicate commits (that differ only by commit ID) from an older version of feature/branch-A, and possibly conflicting with them too.

Side Note: one of the gotchas when you first learn a fancy rebase is that if you use it with commit IDs instead of branch names, when you're done you end up detached. If you find yourself in that situation, to set your branch to your desired commit, after the rebase is done you can just run the command:

git checkout -B feature/branch-b

Note the checkout -B means create the branch and overwrite if it already exists.

TTT
  • 22,611
  • 8
  • 63
  • 69
0

Cherry-pick (see 1 and 2) is easy and works well for a few changes. On the branch-b you can pick single commits of branch-a (like 1) before starting your work and copy it onto your current brunch (1*):

git cherry-pick <commit-hash>

If you only need a few changes:

                        1 - 2 (feature/branch-a)
                      /
(master) x- x (develop) 
                      \
                        1*- x - x (feature/branch-b)

For bigger modifications I wouldn't use it. I asked a similar question for this situation here because I got a couple of merge conflicts when I did the PR of branch-b afterwards.

If you need the hole branch-a:

                             3 - 4 (feature/branch-b1)
                           /
                 x - x (feature/branch-a) 
               /
(master) x - x  - - - - - - - - - - merged-a (develop)
                                          \
                                            3* - 4* - x (feature/branch-b2)

You can create a temporarily branch-b1 and continue work. When the develop branch becomes the merge commit from PR of feature a you can start a branch-b2 with the right base. Now we move our work on b1 to b2. Use git cherry-pick <commit3-hash>^..<commit4-hash> to copy all commits in one command from branch-b1 to b2 and you are fine.

Please let me know if somebody knows a better solution using git rebase.

r2d2
  • 592
  • 5
  • 15