在我工作的公司中，我们的政策是所有代码在签入SVN存储库之前都应该进行审核。通常情况下，在我提交之前，我只是要求一位同事进行审核，但此时此刻几乎没有人在一起，并且我有几个任务与同一个班级有关。
我安装了git，并使用git-svn创建了一个本地存储库。我承诺在一段时间后我将提出的每一项改变，并且git-svn dcommit，我可以在主存储库中同步我的内容。
现在的问题是：如果我的同事在几天内审核我的内容不同意一次提交，或者希望我做一些额外的更改（例如代码注释），会发生什么？如何在不进行额外提交的情况下执行此操作，最终将显示在我的SVN主存储库中？
示例，让我们说 - 为了理解 - 我正在处理一个文件。
现在，我的同事接受了更改A和C，但不同意更改B，并希望更多评论与更改B一起进行。我最终希望最终得到的结果是：
我对git不太熟悉，对SVN非常熟悉。如何在不进行第四次提交的情况下更改我提交到代码更改B的贡献？
答案 0 :(得分：2)
只需创建一个分支并在该分支上进行提交。让你的同事迟到检查代码，然后将代码合并回主干（例如）或其他分支。
答案 1 :(得分：2)
关键是在批准之前不要将您的更改推送到svn。运行git svn dcommit后，您将失去git编辑和重新排序提交的能力。 dcommit公开您的更改，并且svn的历史（大部分）是不可变的。
我通常在分支中进行更改并将它们推送到公共git存储库，该存储库的位置我提供给我的代码审阅者。然后，我可以继续在另一个分支中处理另一个项目。根据审核的反馈，我可以更改我的工作存储库中的分支并重新发布以供审核，当一切准备就绪时，我会做最后的git svn dcommit来完成对svn的更改。
答案 2 :(得分：1)
首先，在提交trunk之前，您不需要其他 VCS来在贵公司执行代码审核。 khmarbaise's answer是正确的。正确（和理智）的方法是create a branch，在分支中进行更改，让您的同事在完成后检查该分支，查看代码，提交补救更改您的分支，然后拥有权限的任何人都会将您的分支合并到trunk。这是基本的VCS协议。如果这不是贵公司的做法，那么对于VCS来说，这肯定是贵公司做错了。
如果您绝对必须使用外部工具，因为您的公司政策是无效的，那么要解决问题的以下部分
例如，让我们说 - 为了 可理解性 - 我正在工作 在一个文件上。
- SVN获取了rev 1000
- 添加了代码更改A，git commit。
- 添加了代码更改B，git commit。
- 添加了代码更改C，git commit。
现在，我的同事接受了更改A. 和C，但不同意变化B， 并希望得到更多评论 随着变化B.我想要的结果 最终归结为：
- SVN rev 1001 - 代码更改A
- SVN rev 1002 - 修改后的代码更改B +附加注释
- SVN rev 1003 - 代码更改C.
我对git不是很熟悉，而且 我非常熟悉SVN。我如何能 改变我承诺的贡献 进入代码更改B而不进行 第四次提交？
如果你被允许进行三次影响一个功能的提交，我甚至不明白你为什么要首先避免第四次提交。
如果你真的，真的打算完成整个想法，那么是的，你可以做到这一点，并且这样做，你需要非常小心使用git rebase --interactive。这个强大的命令可以让你返回你的提交并完全改变每个提交中所做的更改。我必须强调，这有很大的失去工作的可能性（或至少花费你大量的恢复时间），并且只有在你对git本身有非常坚定的知识时才应该这样做。
但你确实应该使用SVN分支和合并来完成所有这些。