Question

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

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

我们已经习惯了TortoiseSVN所以我们决定使用TortoiseGit作为用户界面。

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

存储弹出操作尝试自动合并（很好），但在真正的冲突中，事情变得糟糕。在SVN下很容易，你有一个新文件和一个差异视图另一边的本地文件，只修复你的本地并保存并标记为解决。在Git下，你有四个文件，“普通”文件，一个BASE文件，一个REMOTE文件和一个LOCAL文件。一个完全混淆的事情是“远程”文件（他们的）实际上是包含您的更改的存储文件，所以它没有帮助清晰。

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

Answer 1

我会尝试给出一些指示和提示。首先我会说这个。如果你只需要svn-features，那么去git就没什么意义了。在那些情况下，svn很好。 git可以做很多更强大的事情，但是你必须用git-way来做，任何其他方式都会很麻烦，充其量。

那就是说。如果你的长期目标是完全采用git思考它可能有助于“做到这一点”就像svn一段时间并逐渐改变你的想法。

当你执行git pull时，它实际上会做两件事之一

git fetch
git merge

或

git fetch
git rebase

取决于配置设置或选项--rebase。在一个本地分支机构（甚至是本地主机），我更喜欢做rebase，但是当涉及到冲突时，“他们的”和“我的”非常混乱，但这就是发生的事情。

git将首先将您的工作副本和HEAD倒回到您的本地分支和起源分支分支的位置
然后应用来自origin的所有提交。
git将尝试逐个重新提交您的提交。如果现在发生冲突，它会调用你的更改，然后重新应用“他们的”，这是正确但非常令人困惑的。可以认为“我的”已经在工作副本中了，而“他们的”就像将要添加的内容更有意义。

当你进行合并而不是rebase时，那就是另一种方式。您的更改已经在工作副本“我的”中，并且正在合并的更改是“他们的”。不幸的是很困惑。

我从未使用过kdiff3或TortoiseGIT，所以我无法帮助，但我会说，如果你使用命令行工具发生冲突，原始名称的文件将充满冲突标记，和svn一样。使用您喜欢的任何工具来解决冲突然后

git add <conflict file>
git rebase --continue

或

git add <conflict file>
git commit

取决于您是否进行rebase或merge以解决冲突并继续前进。

Git合并不便

1 个答案: