-1

I created 2 branches from master at about the same time to work on 2 different features. But in the process of working on them, I will have to make different changes to the same class A in both of these 2 branches. Moreover, the same class A has already been changed in master after I created my branches. And when I created a merge request into master from first of them, it shows me there are conflicts. How can I resolve these conflicts in the most painless way possible? enter image description here

Both of these branches are not in master yet, I don't have permissions to merge them into master and it will be done by other engineers and only after codereview. But how can I now merge these branches with each other before codereview in order to avoid conflicts in the future when I merge both of my branches into master?

I have already totally finished my work on 1st branch and created merge request for my 1st branch, I just have to pull master changes and resolve conflicts. And on the 2nd branch, I have so far worked only on other classes, and have not started implementing changes in class A yet. What should I do in this situation? And which git commands to use? I'm new in git. First of all need I merge master with 1st branch having with a created merge request? Then merge 1st updated branch into 2nd branch which not having changes in class A yet? I can’t push any my changes into master. Only after the review and not by me. Now I just want to resolve all conflicts to the maximum before future merge into master of both my branches.

Most importantly, I want there to be no conflicts during merge into master after codereview. Can I somehow merge these 2 my branches to achieve this? How exactly? And while leaving two different merge requests for code review? So that every merge request is for separate feature

François Esthète
  • 855
  • 2
  • 9
  • 15
  • when merging and conflict arises there is option, "use yours", "use theirs" these are the options to merge conflicts. Sometimes more than that is needed, manual interventio of code (which some git clients also allow) – Nikos M. Oct 31 '20 at 19:01
  • In any case, I will need manual resolving, since some changes the code in the same lines of the same class. The question is how can I make merge between 2 my branches before merging to master. So that when merging to master there are no conflicts and there is no need to merge anything manually – François Esthète Oct 31 '20 at 19:06
  • 3
    This is pretty straightforward stuff. To avoid conflicts with changes on `master` made subsequent to your branch history diverging, rebase on its new tip or merge from it. To avoid/resolve conflicts between changes on your two side branches, factor those changes out into a common base. – jthill Oct 31 '20 at 19:26
  • 2
    "Most importantly, I want there to be no conflicts during merge into master after codereview." Stop wanting that. As long as master is live, with other people able to commit to it, there is absolutely no way to guarantee no conflict when merging into it. "How can I resolve these conflicts in the most painless way possible?" In the normal way. Just examine the conflicts and resolve them. No pain is involved, unless thinking for a moment is painful. Conflicts are not some sort of evil. They are normal. Resolve them and move on. – matt Oct 31 '20 at 23:54

1 Answers1

0

As soon as you know there are new commits in master that conflict with your branch(es), then this is what you can do for each of your branches (note this assumes your remote name is origin):

git fetch # get the latest code for master

# deal with your first branch
git checkout my-branch-1
git rebase origin/master
# now resolve any of the conflicts that you have, and when you're done
git rebase --continue
git push --force-with-lease # push your latest code out to the server

# now repeat the previous steps for your second branch

If after completing your first Merge Request you have conflicts when trying to complete your second Merge Request, then repeat the process for your second branch again.

If you know for sure that your second branch depends on the first and will have conflicts due to this, after you're done getting the first branch how you want it, you could create your second branch off of your first. This doesn't guarantee you won't have conflicts, but it lessens the chances. There is a downside though, in that if you end up changing your first branch again before completing the merge, then your second branch may have to be rebuilt too. (Though this is simple if you use rebase with the advanced --onto argument.)

TTT
  • 22,611
  • 8
  • 63
  • 69