0

我使用 git-svn 在两台机器（Mac 和 Windows）上工作。我的远程仓库是一个 svn。我将 Mac 用作主存储库，将 Windows 用作从属。所以所有的 git-svn 操作都是在 Mac 上完成的，而 Windows 机器只有在 Mac 上“git pull”或“git push”。

我的工作流程如下所示，经常让我陷入需要解决数百个冲突的境地：

  1. 我主要在 Mac 上工作，然后让 Windows “git pull”并进行测试。
  2. 有时我需要在 Windows 上工作一点并提交到功能分支。
  3. 然后我“git push origin”将分支推回Mac。
  4. 然后在 Mac 上我“git merge windows_branch”到我的主分支。
  5. 最后我“git svn rebase”和“git svn dcommit”。

在第 5 步，冲突来了！！我曾经使用“git mergetool”、“git rebase --continue”、“git rebase --skip”和“git rebase --abort”工作流程花费 3 个小时来处理每一个冲突。如果幸运的话，我可以把它们全部弄清楚；但有时，它们太多了，更糟糕的是，变基在遍历历史时反复经历同一组冲突（git只知道更改，不知道文件）；最终我感到困惑，错误地解决了其中一些问题，并引发了更大的噩梦。我学到的一些脚本可以帮助我执行“git accept-ours”或“git accept-theirs”之类的操作，但这对于涉及已删除文件的历史记录效果不佳，我仍然需要反复接受。

这是一场噩梦，以至于我真的开始犹豫是否要使用分支和合并工作流程。问题仍然是我不知道为什么会有这么多冲突。但是，如果有推荐的工作流程或实践可以帮助我防止此类冲突或轻松批量解决，那就太好了。

谢谢你的帮助！

4

1 回答 1

1

我终于找到了问题，并将尝试在这里回答我自己的问题：

在我的全局 .gitconfig 中，我禁用了自动合并

mergeoptions = --no-commit

但是在每次“git pull”之后，我实际上并没有在我的 Windows 从属服务器上提交合并，而是后来将事情向上游推送到我的 Mac 主服务器。这就是所有冲突的来源。

我认为我从 Web 获得的关于 rebase/merge 工作流程的一般建议是：

  1. 尽可能使用“git fetch”而不是“git pull”，以便做出进一步的决定。
  2. 使用“rerere”自动解决重复的已知冲突。
  3. 更喜欢在“git svn dcommit”或分支合并之前使用“git rebase -i”或“git merge --squash”将小提交压缩成一个胖提交。这将在一定程度上减少重复冲突的次数。
  4. 在合并或变基之前创建重复分支或跟踪分支以保留未压缩的分支历史记录。
  5. 使用“git list-files -u”在合并前显示冲突文件。
  6. 每次合并操作前，请在合并前使用“git diff branch1 branch2”，避免盲目合并。
  7. 使用“git show branch..file”查看分支下的特定文件以进行验证。
于 2013-03-16T16:50:30.333 回答