2

我们是一个从 SVN 切换到 Git 的开发人员团队，他们认为它会更简单、更标准。不幸的是，直到现在我们只遇到了失败和问题。

我们不需要功能分支。我们有一个名为“develop”的分支，所有开发人员都在共享它。

我们习惯了 TortoiseSVN，所以我们决定使用 TortoiseGit 来开发 UI。

提交和推送效果很好。拉动操作出现问题。SVN 很棒，即使有本地更改，它也会下载新版本，自动合并可能的内容并要求解决冲突文件。在 Git 下，如果您对相同的文件进行了本地更改，它就会停在那里（即使它可以自动合并）。你有两个选择，要么提交你的本地更改（即使你完成了一半的工作），这会污染“显示日志”窗口，其中包含大量无用的提交，或者 stash、pull、pop stash，它们的作用类似于 SVN 正在做的事情一些无用的步骤。有更好的办法吗？

stash pop 操作尝试自动合并（很好），但是在真正的冲突中事情变糟了。在 SVN 下很容易，您在差异视图的一侧拥有新文件，在另一侧拥有本地文件，只需修复您的本地侧并将其保存并标记为解析。在 Git 下，您有四个文件，“普通”文件、基本文件、远程文件和本地文件。一件完全混淆的事情是“远程”文件（他们的）实际上是包含您的更改的隐藏文件，因此它无助于清晰。

因此，您选择打开合并工具的“编辑冲突”菜单选项。TortoiseGitMerge 界面不是很友好，而 KDiff3 在网上被广泛使用，所以我们决定使用它。因此，您按下创建“合并”选项卡的合并按钮，在有冲突的行上，您可以按下 A、B、C 按钮。到现在为止，还好。问题是，当您保存此生成的文件时，它保存在 file.cs.LOCAL.cs 下（而不是 file.cs？）。然后，在 TortoiseGit 下，无论您选择“已解决”、“使用我的解决”还是“使用他们的解决”，它都会删除您的合并文件并为您提供最终文件的错误版本（没有完成合并工作）。我们设法得到它的唯一方法是对合并文件进行临时备份，标记为已解决并重新复制备份。我勒个去？在我们的工作流程中，我们做错了什么？

4

1 回答 1

2

我将尝试提供一些指示和提示。首先我会说这个。如果您只需要 svn 功能，那么使用 git 没有什么意义。svn 在这些情况下很好。git 可以做很多更强大的事情，但你必须以 git 的方式来做，任何其他方式充其量都会很麻烦。

那就是说。如果您的长期目标是完全采用 git 思维，那么像 svn 一样“只是做”一段时间并逐渐改变您的思维可能会有所帮助。

当你做 agit pull它实际上做两件事之一

git fetch
git merge

或者

git fetch
git rebase

这取决于配置设置或选项--rebase。在本地分支（甚至本地 master）上，我更喜欢做 rebase，但是当涉及到冲突时，“他们的”和“我的”非常令人困惑，但这就是发生的事情。

  1. git 将首先将您的工作副本和 HEAD 倒回到您的本地分支和起源分支分歧的地方
  2. 然后应用来自源的所有提交。
  3. 然后 git 将尝试一一重新应用您的提交。如果现在发生冲突，它将调用您的更改，然后重新应用“他们的”，这是正确的，但非常令人困惑。将“我的”视为工作副本中已经存在的内容，将“他们的”视为将要添加的内容，这更有意义。

当您进行合并而不是变基时，情况正好相反。您的更改已经在工作副本“我的”中，正在合并的更改是“他们的”。不幸的是非常混乱。

我从未使用过 kdiff3 或 TortoiseGIT，所以我无能为力，但我会这么说，如果您使用命令行工具遇到冲突，则具有原始名称的文件将充满冲突标记，就像它一样会用svn。使用您喜欢的任何工具来解决冲突，然后

git add <conflict file>
git rebase --continue

或者

git add <conflict file>
git commit

取决于您是否进行变基或合并以解决冲突并继续前进。

于 2014-03-13T19:39:26.030 回答