git - merge 两个具有共同祖先但(几乎)不是同一个项目的 git 分支

Question

相关但不完全是我正在寻找的merge-two-branches-what-direction.

情况:

我继承了一个有趣的问题。所以我们有一个 Rails 应用程序，其中包含许多网站的代码。在我来这里工作之前，他们分支了 master 分支来开发一个新网站。这很好，但它从未 merge 回 master，而且 master 的更改也没有 merge 到分支以保持最新。

现在 master 有 2 个新网站，几乎完成了三分之一，而这个分支有一个它被分支的网站和一个与它足够相似的新网站，通过在该分支中进行开发变得更简单(比如最小节省100 小时)。

他们还使用相同的数据库结构和身份验证系统，这对于跟踪我们的客户非常重要。这就是为什么我想 merge 它们，这样当我们更改数据库等中的某些内容时，我不必对每个代码库进行相同的更改...

问题:

我的问题是现在我不知道如何处理这个分支。我希望工作在 master 分支之外完成，偶尔会因为回滚的新功能而中断，但事实并非如此。它几乎就像我们现在有 2 个主分支，因为代码库已经相距甚远。

我曾尝试将 master merge 到另一个分支，但这导致了困惑，我们无法承受，因为两个分支都在进行开发。所以后来我创建了一个本地分支并试图将两者 merge 到其中。但是在与它斗争了几天之后，似乎所有的冲突都被 merge 了，只是让它在我的单元测试和正常测试中失败了。

请求帮助:(问题)

我开始认为将两者 merge 是不可能的，因为此时它们几乎是独立的项目( merge 它们涉及添加或更改诸如 430 个文件之类的东西)

简而言之，我想我的问题是:我现在如何处理 Twig ？

(作为开发者，我是第一次负责源码控制和整体项目管理，所以真的很茫然。)

附注对不起，文字墙，

Answer 1

首先， fork 是可以的!如果您有两个分歧的分支，也许值得分别考虑它们。我只会真正尝试将它们 merge 回去，如果每个核心代码都有很大的改进，那么彼此分享会很好。否则， fork 通常很有用。

话虽如此，我们假设您将努力 merge 它们。

首先，我会决定哪个分支实际上是你的主分支。当然，一个叫做 master，但是为了这个 merge 的目的，你应该决定哪个分支更共享，如果历史发生变化，哪个分支会影响更多的人。通常这确实是 master 分支，但如果没有其他人有 master 的副本，您可以选择看起来更容易的那个。

好的，现在您有了一个“master”分支，您应该努力不去打扰那个 master 分支的历史。我们将调用另一个分支 tf(对于 totally_forked)。无论是来自添加到分支顶部的大型 merge 提交，还是来自将保留来自 tf 的大部分提交的 rebase。这是我首先要做的:

• 创建存储库的完整备份! <-- 有疑问时始终执行此操作。

试 merge

git checkout tf;
git branch tf_merging;
git checkout tf_merging;

git merge master; 检查冲突的程度。查看这些冲突是重复修复(在这种情况下可以消除提交)还是并行修复//如果你认为你不能使用 merge ，就放弃这个分支:

git checkout tf;

交互式 rebase

git checkout tf;
git branch tf_rebase;

git rebase -i master;//交互式 rebase 。使用 merge 尝试中的列表，尝试消除重复提交以防止。另请查看重新排列 tf 的提交是否会提供更好的 merge 候选对象。
//如果发生太多冲突:

git rebase --abort

//只尝试在 rebase 开始后执行几个 git rebase --continue 循环，最多 7-10 次，否则你可能会过度处理冲突并最终导致一团糟.

最终解决方案

如果你不能通过 git 实现你想要的解决方案，还有一个选择，就是从非主分支 tf 中挑选你特别想要保留的功能，并且丢弃非必需品。例如，如果在 tf 中添加了一个在 master 中不存在的库，请将它和其他有用的功能放在一边，以添加一个明确的 master 提交，以创建一个类似于 tf，并具有相同的功能，但实际上是对最有用/核心功能更改的重新实现，跳过了许多非必要的提交。本质上，您杀死 tf 并在您的核心母版的一个分支之上重新实现它最好的部分，以允许共享开发重新开始。