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?
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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With