深圳北站设计方案/软件开发需要学什么

我发现合并工具很少能帮助我理解冲突或解决方案。我通常更成功地在文本编辑器中查看冲突标记并使用git log作为补充。

以下是一些提示：

提示一

我发现的最好的事情是使用“diff3”合并冲突样式：

git config merge.conflictstyle diff3

这会产生如下冲突标记：<<<<<<

|||||||The common ancestor version.=======Changes made on the branch that is being merged in. This is often a feature/topic branch.>>>>>>>

中间部分是共同祖先的样子。这很有用，因为您可以将其与顶部和底部版本进行比较，以更好地了解每个分支上的更改内容，从而更好地了解每个更改的目的。

如果冲突只有几行，这通常会使冲突非常明显。(知道如何解决冲突是非常不同的;你需要知道其他人正在做什么。如果你感到困惑，最好是把那个人叫到你的房间，这样他们就能看到你在看什么在。)

如果冲突时间较长，那么我会将这三个部分中的每一部分剪切并粘贴到三个单独的文件中，例如“我的”，“普通”和“他们的”。

然后我可以运行以下命令来查看导致冲突的两个差异：diff common minediff common theirs

这与使用合并工具不同，因为合并工具也将包括所有非冲突的差异。我觉得这会分散注意力。

提示二

有人已经提到了这一点，但了解每个差异背后的意图通常非常有助于了解冲突的来源以及如何处理冲突。git log --merge -p 

这显示了在共同祖先和您要合并的两个头之间触及该文件的所有提交。(因此它不包括在合并之前已存在于两个分支中的提交。)这有助于您忽略明显不是当前冲突因素的差异。

提示三

使用自动化工具验证您的更改。

如果您有自动化测试，请运行它们。如果你有一个棉绒，那就跑吧。如果它是一个可构建的项目，那么在你提交之前构建它等等。在所有情况下，你需要做一些测试，以确保你的更改没有破坏任何东西。(哎呀，即使没有冲突的合并也会破坏工作代码。)

提示四

未雨绸缪; 与同事沟通。

提前规划并了解其他人正在进行的工作可以帮助防止合并冲突和/或帮助他们更早地解决这些问题 - 而细节仍然是新鲜的。

例如，如果您知道您和另一个人都在进行不同的重构，这两个重构都会影响同一组文件，那么您应该提前相互交谈并更好地了解每个人的变化类型。制造。如果您按顺序而不是并行地执行计划的更改，则可能会节省大量时间和精力。

对于跨越大量代码的主要重构，您应该强烈考虑连续工作：当一个人执行完整的重构时，每个人都停止在代码的该区域工作。

如果你不能连续工作(可能由于时间压力)，那么沟通预期的合并冲突至少可以帮助你更快地解决问题，同时细节仍然是新鲜的。例如，如果同事在一周的时间内进行了一系列破坏性的提交，您可以选择在该周期间每天一次或两次合并/重组该同事分支。这样，如果你确实发现了合并/ rebase冲突，你可以比等待几周将所有内容合并成一个大块的更快地解决它们。

提示五

如果您不确定合并，请不要强行合并。

合并可能会让人感到压力，特别是当存在大量冲突文件且冲突标记覆盖数百行时。通常，在估算软件项目时，我们没有足够的时间来处理开销项目，例如处理粗糙的合并，因此花费几个小时来解决每个冲突感觉真的很麻烦。

从长远来看，提前规划并了解其他人正在进行的工作是预测合并冲突并准备好在更短的时间内正确解决冲突的最佳工具。