CODEWITHSUNDEEP
gitbitbucket
Qwertie
Qwertie

Reputation: 6493

Keeping git history clean while retaining change log for code review

A common situation I have been encountering is a developer submits a pull request, a reviewer then makes some comments, the developer fixes the problems and then uses git rebase to update the original commit so the history is easier to read in the future. The problem now is its seemingly impossible to see what has changed between the original commit and the new changes that were added to the commit.

This makes reviewing the code difficult because its not possible to see if the new changes fixed the raised issue or if other changes were made that caused new issues so the whole PR must be reviewed again or blindly accepted.

Does git provide tools to view changes caused by rebasing or is there an alternative workflow that allows the git history to contain single commits per change without extra "Fixes" commits but still allows reviewers to see each change as the code was in the PR stage. For context I am using bitbucket but I would be interested if raw git or other websites can do this.

Upvotes: 1

Views: 204

Answers (2)

scarletlights
scarletlights

Reputation: 11

So I hope I understood what you just described. From what I understand, basically after the reviewer posts comments on the pull-request(PR), the developer updates the said commit and then after it's pushed, you will still see just one commit (in which it is the new and updated one after the fix, and the original commit is 'gone'). Yes?

If so, I do recommend to update your workflow. It's as easy as just commiting the fix after the original commit. No need to rebase/change history as this is still readable.

develop   o---o---o
                   \
feature             A

then let's say A is the original commit and is now for PR, and a reviewer reviews commit A. Next thing to do by the dev is just simply commit after A:

develop   o---o---o
                   \
feature             A---A'

With A' being the 'fix' after the reviewer's comment. You can check the delta from A' to A by invoking:

git diff hashidAprime hashidA

I would suggest to rebase the branch only when updating from the develop/trunk. Do not rebase when you are still working. Now if you are kind of 'trapped' with that workflow in which you are strictly one commit per feature before PR, then i suggest everytime you make a fix you just note it in the commit message. Kind of a changelog if you may. But that would only show descriptions of what has changed and not the code blocks that were affected. I would personally pick just committing and committing everytime there's a review. It will still look neat, you don't really need to be strict to one commit if you ask me.

Upvotes: 0

VonC
VonC

Reputation: 1323723

There is no native (GitHub or BitBucket or GitLab) solution.

GitHub PR keep a reference to the old history (before each rebase), but comparing old with new history is too cumbersome.

The alternative would be to encourage the developer to rebase/clarify the history:

  • only at the end of the review process, for a final test, before accepting the PR.
  • not during the review process, where the problem articulated in the OP's question would arise.

Upvotes: 2

Related Questions