Question

基本上，当我想在git add --patch <file>操作产生的同一文件中提交两个单独的更改时，git svn rebase稍后会在使用git add进行第二次更改时抛出1-2冲突第二次改变。

所以我基本上这样做（我在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很新，所以这可能是一个愚蠢的问题，但正如我所看到的，两个命令集应该完全一样。

Answer 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分支中只是目录的副本（通常是trunk目录），并且合并提交与正常提交没有区别（除了以svn 1.6开头的新svn:mergeinfo属性）

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

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

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

它甚至在git svn文档中都这样说：不要使用git合并分支并将它们dcommit给svn，它很可能会破坏你的历史

运行git merge或git pull不是在您计划的分支机构上推荐来自。 Subversion没有代表任何合理的合并或有用的时尚;所以用户使用 Subversion无法看到任何合并你做了。此外，如果你合并或从一个git分支拉出来 SVN分支的镜像，dcommit可以承诺错误的分支。 git svn docs

Git-svn问题与git add --patch导致冲突

1 个答案: