我在使用 git-svn dcommits 时遇到问题,这使得 git 存储库无法跟踪哪些提交是哪些提交。
我尝试确保 git 中的 master 分支始终跟在 SVN 存储库中的 trunk 之后。所以每当我工作时,我都在一个主题分支上。这是我的场景:
在一个主题分支工作了一段时间
git checkout -b my-topic
git commit -m "blah blah blah"
然后我决定将我的分支 merge 回 master
git checkout master
git svn rebase #get any changes in svn
git rebase master my-topic
git merge my-topic --ff-only
到目前为止,一切都很顺利。现在我的 master 和 my-topic 都加快了速度并指向同一个提交,整个历史看起来像这样:
A -- B -- C - master + my-topic
但是,当我这样做的时候
git svn dcommit
我最终得到一棵看起来像这样的树(B 和 C 是我最初对该主题所做的提交):
-- B -- C - my-topic
/
A -- B -- C - master + remotes/trunk
似乎在 dcommit 过程中,git 将提交推送到 SVN,然后在 master 之上重播它们。我认为的问题是他们获得了不同的提交者信息。我正在使用 tortoise plink 和 SSH key 登录 svn。
git 存储库中尚未推送到 SVN 的提交的提交者信息为:
Collin Hockey <chockey@xyz.com>
已推送到 svn 存储库的提交具有以下内容:
chockey <chockey@6206317d-b652-48a9-a948-4036602fc523>
有什么办法可以防止这些分支 split ?我可以通过说来修复它
git rebase master my-topic
再次,但我觉得应该没有必要。这样做的主要问题是,一旦一个分支的更改被推送到 SVN,git 不再认为该分支已经被 merge 到任何地方。删除不再需要的旧分支会让您感到困惑。
最佳答案
git svn dcommit
命令的工作方式如下:
- 找到来自 SVN 的最后一次提交;我们称它为
last-svn
- 将
last-svn..HEAD
范围内的提交发送到 Subversion(顺便丢弃电子邮件) - 将
HEAD
重置为last-svn
- 从 SVN 更新并创建相应的提交
换句话说,您发送到 SVN 的提交将被销毁并从 SVN 的更新中重新创建。这一定会发生,因为来自 SVN 的提交与使用 Git 创建的提交不同:
- 他们的描述包含对 SVN 修订版的引用
- 他们的作者电子邮件是根据 SVN 用户名计算的
这就是为什么您的分支 my-topic
与 master
不同。
您可以自定义 git svn dcommit
使用 --authors-file
和 --authors- 从 SVN 用户名计算作者电子邮件的方式prog
选项。
关于svn - Git-Svn dcommit 导致分支 split ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5595870/