为了保持代码评审的简洁性,我提交了一个比完整特性更小的代码评审。这是一个更大的更改之前的清理,但是为了避免将最终评审与清理弄乱,我做了这个评审。
我以后的工作将建立在这个目前活跃的评论的基础上,我需要在评论的结果中做出一些改变。不过,我也希望在审查这段代码的同时继续研究最后的特性。
如何正确地跟踪我在功能上的开发,同时仍然能够对代码进行修改。
当前场景:
master -x-x-x---x---|
feature \-x-x-x| code review
未来情景(分支)
master -x-x-x---x---|
feature \-x-x-x|-x--x--|
feature2 \x--x--x| code review complete (merge)
未来情景(隐藏)
master -x-x-x---x---|
feature \-x-x-x|-x--x--| code review complete (merge)
work on feature branch, stash changes if needed to make code review updates
我认为分支模式更有意义,但创建另一个同名、目的相同的分支似乎违背了某种“git property”的含义。
最佳答案
我认为分支是正确的方法;您可能只需要一个好的分支名称,而不是为您的工作创建一个新的分支,而是使用新的分支来“冻结”代码的快照以供代码检查。
当您想提交feature
进行代码评审时,假设您的存储库是这样的。
* -- * -- * -- * -- * -- * -- * master
\
* -- * -- * -- * feature, HEAD
只需创建一个名为(
cr/feature
)的新分支,其中cr
是“代码评审”的缩写。git branch cr/feature
现在,您当前的分支负责人有两个分支引用它。
* -- * -- * -- * -- * -- * -- * master
\
* -- * -- * -- * feature, cr/feature, HEAD
在继续处理功能时,不会影响正在进行代码审阅的代码。
* -- * -- * -- * -- * -- * -- * master
\
* -- * -- * -- * -- * -- * -- * feature, HEAD
|
cr/feature
代码评审完成后,评审的代码是否合并到
master
中?git checkout master
git merge cr/feature
git branch -d cr/feature # Optional
* -- * -- * -- * -- * -- * -- * -- * master
\ /
* -- * -- * -- * -- * -- * -- * feature, HEAD
|
cr/feature (if not deleted)
这样,代码审阅者就永远看不到您在
feature
上的继续工作,直到您通过显式地创建一个分支来将其提交给代码视图。如果需要对已审阅的代码进行更新,则可以将这些更新添加到
cr/feature
分支:* -- * -- * -- * -- * -- * -- * master
\
* -- * -- * -- * -- * -- * -- * feature, HEAD
\
* -- * cr/feature
或者将
cr/feature
合并回feature
* -- * -- * -- * -- * -- * -- * master
\
* -- * -- * -- * -- * -- * -- * -- * feature, HEAD
\ /
* ----- * cr/feature
或者在代码评审分支上重新设置
* -- * -- * -- * -- * -- * -- * master
\
* -- * -- * -- * * -- * -- * feature, HEAD
\ /
* -- * cr/feature