0

At work we use gerrit for codereview and as a git server. Also we have the following workflow:

  1. For each feature create a new feature branch
  2. If feature is ready, push it to git push origin HEAD:refs/for/feature for codereview
  3. After codereview, submit your change and merge origin/feature in your local master: git checkout master && git merge --no-ff origin/feature
  4. After resolving all conflicts push it a second time to gerrit git push origin HEAD:refs/for/master
  5. If the change from step 4 is okay, submit it.

Problem: Lets say everything works smooth until step 5. My change was reviewed and I´m ready to submit the change. In the meantime another developer pushes some changes directly to master. Gerrit gives me now a "merge conflict" in my change without the option to submit my change.

Now i´m a little bit lost in how I should resolve this issue...at the moment I can only come up with the following three solutions:

  1. Checkout the change and git rebase origin/master (losing my previous merge commit, rewriting history)
  2. Checkout the change and git rebase --rebase-merges origin/master (rewriting history)
  3. Checkout the change and 'git merge --no-ff origin/master' (history is a little bit f*cked up...)

Is there a safe and elegen solution to this problem ? How would you solve it ? I´m quite new to git/gerrit and dont want to mess up our repo...

RobPorgstrom
  • 11
  • 1
  • 1
  • Does this answer your question? [How to resolve merge conflicts in Git repository?](https://stackoverflow.com/questions/161813/how-to-resolve-merge-conflicts-in-git-repository) – mkrieger1 Mar 14 '21 at 16:10
  • Not rly. I know how to resolve merge conflicts in git ^^ – RobPorgstrom Mar 14 '21 at 16:14
  • Then I didn't understand what you are asking. – mkrieger1 Mar 14 '21 at 16:14
  • Did you already read this? https://stackoverflow.com/questions/53209237/how-to-solve-merge-conflict-in-a-approved-review-in-gerrit/53213237 – mkrieger1 Mar 14 '21 at 16:18
  • Do you know how gerrit works ? – RobPorgstrom Mar 14 '21 at 16:19
  • Rewriting history would be frustrating. So I think the 3rd way is better. To make the history look clean, you could also merge `feature` to the latest `master` again. If you find resolving conflicts repeatedly annoying, you could enable `git rerere`. – ElpieKay Mar 15 '21 at 07:14
  • I used the third solution. Went way smoother than with rebasing ^^ – RobPorgstrom Mar 21 '21 at 11:58

1 Answers1

0

I'd recommend a workflow that relies on rebasing. That is, your solution 1.

I would also recommend periodically rebasing to HEAD between steps 1 and 2 during development to minimize surprises at review time.

Generally this makes it easier to understand the change as a simple application of your commits. I find it is generally much easier from the perspective of the reviewer too, and also for everyone to reason about should there ever be a need to roll back a change.

Tinkerer
  • 865
  • 7
  • 9
  • Can you think of any implications with solution 2 ? Usually I dont want to throw away the merge commit... – RobPorgstrom Mar 14 '21 at 16:25
  • I guess I'm mostly a fan of leaving a clear trail of what **actually** happened at HEAD. The cost of discarding some transient info that doesn't contribute to understanding the actual history of the committed HEAD is mostly a win as I see it. That is, less of a cognitive burden to those looking back at how things got to where they ended up. – Tinkerer Mar 14 '21 at 16:49