Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to keep a clean history after GitHub Pull Request code review?

Our code is on Github and we use Pull Requests to review the code. As a result of the review a commit might be reverted or changed. This might clutter the commit history. The rebase command is discouraged because the commits are already "publicly available".

If you perform code reviews in a similar way: How do you deal with this? How do you keep your history clean?

like image 906
Lars Schneider Avatar asked Mar 09 '12 22:03

Lars Schneider


2 Answers

Rebasing non-master (maint*, next) branches is ok even they are published. Just use topic branches to publish new stuff to be reviewed. Then delete them in any case after they are merged into master or after the pull request has been declined. See man gitworkflows

like image 74
rudimeier Avatar answered Oct 17 '22 20:10

rudimeier


I'd suggest simply getting over the commit history being cluttered.

Bear in mind that when you look at history, you're usually looking at the ancestry of some current commit. If your code review process creates dead-end branches for code which got rejected or resubmitted as a different commit, then those won't be in any such ancestry, and won't usually be seen.

Here's a long-winded but complete example of this, using git log as the history viewer:

$ git init example
Initialized empty Git repository in /private/tmp/example/.git/
$ cd example/
$ date >date
$ git add date
$ git commit -am base
[master (root-commit) 5108762] base
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 date
$ date >date
$ git commit -am bad
[master 440c3b6] bad
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git log
commit 440c3b61b279e8b7cd5f5f656984b63ba18e518b
Author: Tom Anderson <[email protected]>
Date:   Sat Mar 10 09:15:48 2012 +0000

    bad

commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <[email protected]>
Date:   Sat Mar 10 09:15:28 2012 +0000

    base
$ git branch postreview 5108762ba7011464fe3c57cf762d0d18f337f68c
$ git checkout postreview
Switched to branch 'postreview'
$ date >date
$ git commit -am good
[postreview 42e5257] good
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git log
commit 42e5257addf73b516676d24e7092b0e4768d3564
Author: Tom Anderson <[email protected]>
Date:   Sat Mar 10 09:17:30 2012 +0000

    good

commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <[email protected]>
Date:   Sat Mar 10 09:15:28 2012 +0000

    base

Even though the bad commit is in the repository, it doesn't show up in the git log output. In this case, i've created a new branch to do my post-review work, but in practice, you probably want to move master for the new work, leaving the old work on a dead branch.

like image 33
Tom Anderson Avatar answered Oct 17 '22 20:10

Tom Anderson