在我的公司里，我们有一个Subversion服务器，每个人都在他们的机器上使用Subversion。但是我想使用 git，在本地提交更改，然后在我准备好时"推送"它们。
但是，我不明白在以下情况下会发生什么。假设我在本地进行了 3 次 git 提交，现在我准备在 Subversion 服务器上"推送"所有内容。如果我理解正确，git svn dcommit基本上应该在服务器上按顺序进行 3 次提交，对吧？但是，如果在此期间（假设在第二次和第三次提交之间）我的另一位同事发出提交，会发生什么？我能想到的场景是：
1）git类型的"锁"（甚至可能吗？）在提交期间的Subversion服务器，以便我的提交以原子方式进行，而我同事的提交在我的提交之后完成
2）服务器上的提交历史记录变为mine1-mine2-other-mine3（即使"other"应该失败，因为我的同事当时没有更新的工作副本）。
我认为它是#2，但也许提交速度如此之高，以至于这很少成为问题。那么哪一个是#1还是#2？
Git 不支持任何锁，它不是 Git 方式（Git 方式是分支和合并）。使用 git-svn，您将获得 mine1-mine2-other-mine3 历史记录。如果你需要原子性，可以看看SubGit项目（它被安装到SVN服务器中，并为SVN仓库创建一个纯的Git接口）。
最近有一个类似的问题，你可能很有趣。
如果你很幸运，那么排名第二，但大多数时候你没有那么幸运。根据我的经验，当我提交很多提交而其他人在这样做时提交时，通常会发生 2 件事：
- 它停止提交您的其他更改。
- 您将丢失尚未提交的提交。
数字 2 真的很烦人。主要问题是你需要完全更新才能使用 git svn dcommit。这是因为 git-svn 不允许服务器即时合并修订。（因为它要求两个提交者都有一个包含两个更改的工作树）。
解决此问题的唯一方法是我在此处找到的以下步骤
- 打开 .git/logs/HEAD
- 查找您最近的提交（请注意，这些提交已排序通过"Unix 时间"，尽管您也可以通过阅读找到最新的那里的短日志
- 确认您找到的提交是正确的：git show
- git reset --日志中的硬哈希
- git svn rebase
- git svn dcommit
按照此过程，您可以从失败的地方起飞。我希望他们尽快解决这个问题，但他们说这还不是他们的优先事项。
当然，如果您提交小组并与服务器建立快速连接，则不应经常发生。（在 2 个月内每天积极工作和承诺时，我只得到了 3-6 次）。