合并严重分歧的分支有什么好的策略,包括在git中重命名和移动的文件?

时间:2017-11-10 14:29:58

标签: git merge version-control

我有一个git项目,有两个不同的分支,我想组合成一个新的分支。两个分支在分裂后都包含很多变化:

虽然一个分支主要添加了许多新文件,并且修改了现有文件,但其他分支主要是< em>删除许多文件,重命名移动现有文件,并广泛重构其内容。

我对高级合并不是很熟悉,当我尝试合并时,git无法识别文件重命名/移动,而是列出已删除/创建的文件。此外,在许多相互冲突的行中,许多提交都发生了变化,因此我常常无法理解变化并找到相关部分。

此方案是否有良好的合并策略,两个分支之间有很多变化,包括重命名/移动的文件?

谢谢!

2 个答案:

答案 0 :(得分:1)

不幸的是,你长期陷入困境......

首先,澄清一下

git没有跟踪文件移动 - 它会检测到它们。

通过检查已删除的文件内容来检查文件是否已移动以确定文件是否已移动。这种检查有限制,很容易错过。帮助git了解正在发生的事情的最好方法是在没有更改的情况下在提交中移动文件,然后使更改成为单独的提交。因为听起来你没有这么做就会有一系列的变化,你可能不得不忍受它。

使用两个分支时

定期重新定义(或合并,如果必须,但我将在此处引用变基)是很重要的,这些变更将致力于您不会自行处理的分支机构,因此它会更新 - 到目前为止对另一个分支的变化。

通常,有master分支和wip分支(正在进行中,或者您称之为的任何分支)。 master上的更改会定期更改为wip,并在完成wip后将更改重新更改为`master。

通过这种方式,分支从不会相距太远。

您需要做什么

根据你的描述,分支被允许漂移太远以获得舒适。要解决这个问题,所需要的只是遍历一个分支的提交并将它们重新绑定到另一个分支。这可以手动完成,或者git rebase --interactive将引导您,一次一个提交,直到您完成。

如果您不熟悉git rebase,我建议您仔细阅读,因为它擅长处理此类问题。

我不推荐它,但可以使用git merge来处理 - 但它不会为您提交提交并尝试立即处理所有更改痛苦(如你所描述)。如果要将分支合并为多个部分,则必须单独处理每个提交,或者(如果可能)将它们组合在一起 - 但是分组可能需要对提交中的内容有深入的了解。

<强>参考

git rebase documentation

Rebasing section of the git book

答案 1 :(得分:1)

假设对两个分支进行了更改,如下所示:

  • master :添加了许多新文件,并修改了现有文件。
  • develop :删除了许多文件,重命名并移动了现有文件,并广泛重构了其内容。

为了自动解决合并冲突并保留重命名的文件,您可以通过以下命令合并这两个分支:

git checkout develop
git merge master -X theirs

然后会添加这些文件而不会发生冲突

  • master分支
  • 上添加的文件
  • masterdevelop分支
  • 上修改的文件
  • develop分支
  • 上重命名的文件
  • 文件已在develop分支上删除,但未在master分支
  • 上修改

只有一种情况需要解决合并冲突manouall y是:

  • develop分支上删除并在master分支
  • 上修改的文件

因此,如果在合并两个分支时存在合并冲突,则只需使用以下命令来保存文件(在develop分支上删除master分支时删除)作为版本master分支:

git add .
git commit

因此,合并后会保留所有文件(添加,修改和删除)。