0

I have been checking out to new branches from the older branch, instead of checking out to the master. currently, I have created four new features: home_feature, admin_user-feature, customer_request, blog_feature.

I forgot to checkout to the master before creating the "customer_request" branch, and create the feature by moving into the blog feature. now I am faced with a lot of conflicts. I have tried using 'git rebase' but the commits are up to 80 commits per branch, so it not practical. How can I resolve these conflicts?

enter image description here

halfer
  • 19,824
  • 17
  • 99
  • 186
ife brand
  • 51
  • 6
  • What I tend to do is to create a new feature branch off master, then list the commit hashes in the existing feature branch, in chronological order, in a text editor. Then take the first one and try to cherry pick it in your new (master copy) branch. If there is a conflict then you know that you amended files/folders that are not in master in the same state, and a manual conflict resolution may be in order. – halfer Apr 20 '20 at 15:21
  • I have been stuck on this issue for the past 2 days. Thanks this worked for me, cherrypicking from the first commit to the last relevant commit of the older branch to a new feature of the master reduce the conflicts. – ife brand Apr 21 '20 at 14:06

2 Answers2

0

You could either do a merge and fix the conflicts only once instead of perhaps multiple times as you might have to do with a rebase.

Or you could let Git automatically pick either your changes or master's changes when there are conflicts.

For example, if you do a rebase, you could add the ours (or theirs) option to the recursive merge strategy.

For example, the following command would rebase your branch on top of master and for any conflicts, it will choose your changes instead of the changes from master:

git rebase master -Xtheirs

The theirs and ours is a bit counter-intuitive in this case. -Xtheirs will choose your changes and -Xours will pick the changes from master.

D Malan
  • 10,272
  • 3
  • 25
  • 50
-1

From the comments, this appeared to be the solution. You had three branches:

  • Master (M)
  • Old feature branch (O)
  • New feature branch (N)

N was branched off O accidentally, rather than M, which is what you intended. This means that there is a series of commits starting at a certain point in time in N and you want to recreate the branch with those commits as if you had branched from M.

The solution was to create a new branch:

  • Newer feature branch (N2 from M)

Then identify a series of commit hashes from N, and apply them to N2. You can do that manually by cherry-picking each one in turn.

There was a risk that these would not apply cleanly, because M might have changed some files compared to O, and thus your work in N would have been based on outdated files/folders. Text change merging is a fairly simple algorithm, it does not understand code structure like humans can (in other words, not everything is mergeable).

However, as it turned out, the cherry-picks applied cleanly. If you had not been able to do that, you might have had to create a diff for each failing one, and see how to apply it manually to N2 given the changes in M. Where this happens, it is worth still trying to cherry-pick following commits, as they might not all need manual conflict resolution.

halfer
  • 19,824
  • 17
  • 99
  • 186