Question

我了解到git具有不同文件状态的概念： 1.新的 2.修改 3.上演 4.承诺

经过大量搜索后，我发现如果我想向任何工具发送代码审查，我必须提交本地存储库并将其推送到某个中央存储库进行代码审查（通过任何代码审查工具）例如Gerrit）。

现在，假设文件在开始代码审查过程之前处于状态A，并且它经过了10次审核返工，即10次更改，即10次提交到本地存储库，最后文件处于状态B，最终应该提交。< / p>

从状态A到B 10完成了提交。

假设这些10个，4个提交在同一部分/文件的一部分。

所以，最后，当我将审查并接受文件的最终状态B推送到主中央存储库时，我将不得不进行10次提交，其中一些中间提交需要返工，即不需要的提交。

但我不想要那些不必要的提交。

从我能想到的是，我感兴趣的是最终状态B只需一次提交即可推送到存储库。

所以我正在寻找任何这样的方法/工具，它允许发送git阶段的更改以供审核。审稿人将审查。如果他拒绝并建议一些更改，那么我会取消之前的更改。应用建议的更改，暂存这些更改并再次发送以供审核。

因此，当最终审核代码时，我将进行单个提交我的分阶段更改，并且只需要单个最终推送。

Answer 1

无法在git存储库中推送未经修改的更改。但是，您可以使用不同的分支来实现您想要的。您可以在开发分支上工作，并根据需要进行尽可能多的提交。您可以将它们推送到远程服务器上的某个开发分支。审阅者接受更改后，您可以将提交合并到主分支中。如果需要，可以将git rebase用于merge提交到单个提交中。

Answer 2

$('.newQuestion').on('click', function() {
  var template = document.querySelector('#newQuestion');
  var clone = document.importNode(template.content, true);
  $(clone.childNodes).hide().appendTo('.questionsList').fadeIn(); 
});

这会将您的隐藏索引推向可审核

将“origin”替换为其他人可以访问的遥控器
将“@ {0}”替换为您想要审核的任何隐藏号码
如果您希望审核隐藏的文件系统更改，请删除“^ 1”部分。
如果你想要检查你的存储索引和存储文件系统，那么首先推送索引（使用^ 1），然后推送非索引（no ^ 1）。

以下是使用独特创建的独立分支更好的原因：

如果代码审核通过，您可能会在某处合并您的更改。你不能将stashes合并成任何东西。
- 父母的历史非常丑陋。您的两个存储提交都共享同一个父级。 “WIP”在技术上是一个合并提交，但这并不能说明发生了什么。
- 提交消息不好。
通过分支，您可以根据代码审查的反馈实际更改代码 - 这是进行代码审查的全部要点。你可以添加更多提交，删除提交，变基，壁球等。你不能用存储器做到这一点。（或反叛等）

对我来说，我不觉得我真的需要“说服”任何人使用分支代替，因为每个尝试使用这种（或其他方式）的藏匿处的人都会自己想出正确/更好/更容易方法是只使用侧枝进行工作/代码审查。又名git push origin stash@{0}^1:refs/heads/tmp/for-code-review

Answer 3

我相信大多数代码审查工具都会有差异，所以只需使用'git diff'来生成代码的相应差异以供审核。

至于将多个提交合并为一个，那么，有多种方法可以实现：

您可能需要查看--squash的{{1}}选项manpage。或者阅读this SO文章。
或者，您可以在dev分支上本地执行所有提交但在合并到主线之前，使用git merge将它们压缩在一起。有关详情，请参阅manpage或阅读this SO文章。

我可以发送git staged区域的更改以进行代码审查（到任何代码审查工具）吗？

3 个答案: