3

So I'm trying to understand how Git handles certain processes and what are some already used practices.

Let's say we have a Git repository with a branch called master. We also have two branches that are created simultaneously from master. We'll call them branch_one and branch_two.

branch_one already has work completed for a specific feature. I am currently developing on branch_two. For the sake of this conversation, let's assume that I can't merge branch_one to master because it's pending approval from other developers.

Here's the issue:

I need all of the work from branch_one in order to continue work on branch_two.

Here is my current flow:

1) merge branch_one into branch_two.
2) work on branch_two.
3) rebase branch_two with master before submitting a pull request.

Uh-oh. The rebase has conflicts on 30+ patches. I assume this is because the merge (step 1) changes the head of branch_two. I may be assuming incorrectly.

Obviously I would like to avoid a massive conflict resolution step in my version control process.

So my questions:

Is there a better way to handle this type of process, where a feature branch requires changes from another feature branch, that doesn't include massive conflicts?

shaneb
  • 1,314
  • 1
  • 13
  • 18
Frank
  • 915
  • 1
  • 7
  • 22

2 Answers2

6

You need an integration branch, made from master HEAD:

  • merge branch1 in integration
  • rebase branch2 on top of integration.

If branch1 needs additional work in the context of its validation, merge the new branch1 commits in integration again.
At some point, branch1 will be merge into master.

Then, whenever you want to validate branch2, rebase it first on top of the updated integration branch. Then merge it to integration (using --no-ff: no fast-forward merge).

Finally, merge branch2 to master when ready. No conflict there.

For more on this workflow, see gitworkflow (far better than Gitflow)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Why was this answer downvoted? It seems correct to me. – SergeyA Aug 24 '18 at 19:56
  • Off course, you would never merge integration to any of the feature branch. Ideally, merge flows only one way. That way, you keep both integration and feature branch lightly coupled: a simple git revert is enough to remove a feature from integration. – VonC Aug 24 '18 at 20:06
  • @VonC to be clear, when you say "rebase branch2 on top of integration" this means `git rebase integration`, correct? – Frank Aug 25 '18 at 03:55
  • @Frank Yes, that is how the rebase is done: "on top of" – VonC Aug 25 '18 at 03:57
0

You are running into a common pitfall in GIT. The solution is always, think ahead. In your scenario, knowing whether or not you'll need a feature from one branch ahead of time will give you the ability to branch in a way that avoids this issue:

create a branch off of master that will be an epic-branch

git checkout -b epicBranch

create both branch_one & branch_two off of epicBranch

git checkout -b branch_one git checkout -b branch_two

Once you need a feature from branch_one you PR and merge branch_one into epicBranch then merge epicBranch into branch_two

git checkout branch_two
git merge epicBranch

Now you have the change from branch_one in branch_two without the overhead of closing branches.

You will have the commit history and shouldn't run into any issues when merge or rebasing.

You can also save a lot of headache by cherry picking your needed feature commit into a branch of its own that can be shared between branches.

Chris
  • 470
  • 1
  • 4
  • 15
  • thanks for the response. Unfortunately the scenario posed above is that I can't merge branch_one first because of some reason. – Frank Aug 25 '18 at 03:56