45

As a git best practice, one should commit frequently, but to review the code you may need to review a patch consisting of multiple commits at once. Is there a way multiple commits can be reviewed and either merged or rejected at once?

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
Nonos
  • 2,450
  • 2
  • 23
  • 34

3 Answers3

38

One thing you can do a squash merge to a temporary branch and then post that change for review.

git checkout -b feature
git commit -m "start feature"
...
git commit -m "finish feature"
git checkout -b feature-review master
git merge --squash feature
git commit

Now your feature-review branch will contain the same diff relative to master as feature did but with only a single commit.

Emil Sit
  • 22,894
  • 7
  • 53
  • 75
  • 1
    Thanks for your reply. But how do you then push/merge to master after code reviews that may involve code changes? – Nonos Aug 30 '13 at 17:37
  • You can continue to work on whatever branch (either `feature` or `feature-review`) you want, and push that when it's done. You can even repeat the process of doing a squash merge for your final commit to master, depending on how much you care about history and breaking down the commits. – Emil Sit Aug 30 '13 at 19:30
  • 6
    `git merge --squash`will rewrite the history and will not allow you to use `git bisect` on the feature – summerbulb Jan 13 '15 at 09:53
  • 2
    @summerbulb yeah, that's my exact problem with this solution. I often don't want to have a bunch of commits squashed into one giant commit. It can make reading the git history difficult in the future, which can cause all sorts of issues. I prefer small self contained commits generally, but Gerrit makes that hard to do. – Nate Jun 09 '17 at 15:29
  • why not just use a decent git tool like Bitbucket that does it all for you? – Ramonster Jun 05 '19 at 12:26
20

No, Gerrit does not currently support batching commits into one review. However, there are a couple other options.

At $DAYJOB, my team uses feature branches for larger changes. The smaller commits are reviewed/merged to the feature branch individually, but the feature branch is only merged in once everything is in a good place and all developers are happy.

Gerrit also supports topic branches - which are a convenient way to group related commits. They are discussed briefly in the documentation. These commits must still be reviewed/merged individually, but they can be quickly grouped together in the web UI.

matli
  • 27,922
  • 6
  • 37
  • 37
Brad
  • 5,492
  • 23
  • 34
0

If you need to update already posted review requests then you can leverage amend commits:

git commit --amend -C HEAD

and then push for consequent review.

I believe that public commits should be atomic and contain the complete bunch of functionality which you want to contribute. Usually you do not want to share all of your intermediate commits. So squashing commits before review is good idea.

akirillov
  • 77
  • 2
  • 9
    One school of thought says it's best to make disruptive changes as a sequence of tiny atomic commits, each of which is pushable to prod. Preserving these tiny commits makes it easier to see what you did and why, easier to do reverts, makes bisections more useful, and reviews easier and faster (eg. when a data file was sorted and had one line added, these two commits with two tiny commit messages make it very clear what happened and why. Squashing means the big diff from the sort obscures the insertion.) This idea is popular at the best places I've worked. – Jonathan Hartley Aug 08 '17 at 20:59