我们的代码在Github上,我们使用Pull Requests来检查代码。作为审核的结果,可以还原或更改提交。这可能会使提交历史变得混乱。不建议使用rebase
命令,因为提交已经“公开可用”。
如果您以类似的方式执行代码审核:您如何处理此问题?你如何保持历史清洁?
答案 0 :(得分:6)
即使它们已发布,也可以重新定位非主(maint *,next)分支。
只需使用主题分支来发布要审核的新内容。然后在它们合并到主服务器之后或者在拉取请求被拒绝之后的任何情况下删除它们。
看到
man gitworkflows
答案 1 :(得分:1)
我建议简单地将提交历史弄得一团糟。
请记住,当你查看历史时,你通常会查看当前提交的祖先。如果你的代码审查过程为被拒绝或重新提交为不同提交的代码创建了死胡同分支,那么那些不会成为任何这样的祖先,并且通常不会被看到。
这是一个冗长而完整的例子,使用git log
作为历史记录查看器:
$ 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 <twic@urchin.earth.li>
Date: Sat Mar 10 09:15:48 2012 +0000
bad
commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <twic@urchin.earth.li>
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 <twic@urchin.earth.li>
Date: Sat Mar 10 09:17:30 2012 +0000
good
commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <twic@urchin.earth.li>
Date: Sat Mar 10 09:15:28 2012 +0000
base
即使错误提交在存储库中,它也不会显示在git log输出中。在这种情况下,我创建了一个新分支来进行我的审核后工作,但在实践中,您可能希望将新工作转移到新工作中,将旧工作留在死分支上。