0

基本上，当我想在同一个文件中提交由git add --patch <file>操作导致的两个单独的更改时， git svn rebase 稍后会在用于第二次更改时在提交第二次更改时引发 1-2 冲突git add。

所以我基本上是这样做的（我在 master 分支上并且已经获取了 svn 存储库）：

git checkout -b feature
... make two unrelated changes to file test.txt...
git add --patch test.txt
... add first change but ignore second one
git commit -m "change1"
git stash
git checkout master
git merge feature
git svn rebase
git svn dcommit
git checkout feature
git stash apply

现在这里有两种方法可以做到，第一种可行：

git add --patch test.txt
... select everything (which is the second change in this case)
git commit -m "change 2"
git checkout master
git merge feature
git svn rebase
git svn dcommit

这是一个不起作用的：

git add test.txt #notice there's no --patch
git commit -m "change 2"
git checkout master
git merge feature
git svn rebase #yields a conflict

那么为什么在git add --patch用于第二次更改时，我可以毫无问题地提交到svn存储库，但是当仅git add用于第二次更改时，会导致冲突？我对 git 很陌生，所以这可能是一个愚蠢的问题，但在我看来，两个命令集应该完全相同。

4

1 回答 1

1

你为什么要为你的 2 个提交创建一个分支然后合并回来？我想这可能会带来问题，因为 git 中的合并与它们在 svn 中的工作方式不同。

这应该有效（“应该”，但我很确定它确实有效）：

# on master, no need to create a branch
$ git add -p file
$ git commit -m "first set of changes"
$ git add file
$ git commit -m "the remaining changes"
# apply your commit on top of eventually new changes upstream
$ git svn rebase
# commit your 2 commits to svn
$ git svn dcommit

在 svn 中的分支只是目录的副本（通常是主干目录），合并提交与普通提交没有区别（除了svn:mergeinfo从 svn 1.6 开始的新属性）

git 中的提交是不同的，每个提交都存储一个指向其父提交的链接。svn 不需要这个，因为它可以简单地使用 REV-1。git 中的合并提交因此有多个父级（合并分支和合并分支）

我不知道如果您将 git 提交到 svn 会发生什么，但它可能只会提交合并提交本身，没有历史记录（消息类似于“将分支 'bla' 合并为 'master'）。

当您运行时，svn commit只会将您的新更改发送到服务器以节省带宽。现在，git 中的合并工作不同了，与以前版本的差异可能不会像您期望的那样，这就是git svn dcommit失败的原因。

它甚至在 git svn 文档中这样说：不要使用 git 合并分支并将它们提交到 svn，它很可能会弄乱你的历史

不建议在您计划从中进行 dcommit 的分支上运行 git merge 或 git pull 。Subversion 不代表任何合理或有用的合并；因此使用 Subversion 的用户看不到您所做的任何合并。此外，如果您从作为 SVN 分支镜像的 git 分支合并或拉取，dcommit 可能会提交到错误的分支。 git svn 文档

于 2010-09-05T11:44:22.897 回答