3

我了解到 git 有不同文件状态的概念： 1. 新 2. 修改 3. 暂存 4. 已提交

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

现在，假设文件在开始代码审查过程之前处于状态 A，并且它经历了 10 次以上的审查返工，即 10 次以上的修改，即 10 次以上的本地存储库提交，最后文件处于状态 B，最终应该被提交。

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

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

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

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

据我所知，我对最终状态 B 感兴趣，只需一次提交即可将其推送到存储库。

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

因此，最终当代码审查接受时，我将进行一次提交我的分阶段更改，并且只需要一次最终推送。

4

3 回答 3

2

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

于 2012-10-03T19:29:17.683 回答
1 
git push origin stash@{0}^1:refs/heads/tmp/for-code-review

这将推动您的隐藏索引可供审查

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

以下是为什么最好使用独特创建的单独分支的原因：

  • 如果代码审查通过，您可能会在某处合并您的更改。你不能将 stash 合并到任何东西中。
    • 父母的历史是丑陋的。您的两个存储提交都共享同一个父级。“WIP”在技术上是一个合并提交，但这并不能真正说明正在发生的事情。
    • 提交消息很糟糕。
  • 有了一个分支，您实际上可以根据代码审查的反馈更改您的代码——这就是代码审查的全部意义所在。你可以添加更多的提交、删除提交、rebase、squash 等等。你不能用 stash 来做到这一点。（或变基等）

对我来说，我觉得我真的不需要“说服”任何人使用分支，因为每个尝试使用像这样（或其他方式）的 stash 的人都会自己发现正确/更好/更简单的方法是只需使用侧分支进行工作/代码审查。又名git branch bugfix/xyz; edit...; git push origin bugfix/xyz;

于 2016-06-24T13:42:56.710 回答
0

我相信大多数代码审查工具都会有差异，所以只需使用“git diff”来生成要审查的代码的适当差异。

至于将您的多个提交合并为一个，嗯，有不止一种方法可以做到：

  1. 您可能想在手册页上--squash查看git merge. 或阅读这篇SO 文章。

  2. 或者，您可以在您的 dev 分支上本地执行您想要的所有提交，但在合并到主线之前，使用git rebase将它们压缩在一起。有关详细信息，请参阅手册页或阅读此SO 文章。

于 2012-10-04T14:50:39.447 回答