相关但不完全正在寻找merge-two-branches-what-direction.
我继承了一个有趣的问题。因此，我们有一个rails应用程序，其中包含许多网站的代码。在我来这里工作之前，他们分支了主分公司来开发一个新的网站。这很好，但它从未合并回主人，并且来自master的更改未合并到分支中以使其保持最新。
现在master拥有2个新网站，差不多有三分之一已完成，而这个分支有一个分支的网站和一个类似于它的新网站，通过在该分支中进行开发变得更简单（如最小节省100小时）。
他们也使用相同的数据库结构和身份验证系统，这对于跟踪我们的客户非常重要。这就是为什么我想合并它们，所以当我们在数据库中更改某些内容时，我不必对每个代码库进行相同的更改...
我的问题是，现在我不知道如何处理这个分支。我希望工作在主分支之外完成，偶尔会中断一个新功能，但这并不是什么事情发生的。它几乎就像我们现在拥有2个主分支，因为代码库已经相距甚远。
我已经尝试将主人合并到另一个分支，但这导致了混乱，这是我们无法负担的，因为两个分支都在进行开发。然后我创建了一个本地分支并尝试将两者合并到其中。但是在与它挣扎了几天之后，似乎让所有冲突合并，只是让它失败了我的单元测试和正常测试。
我开始认为将两者合并是不可能的，因为它们在这一点上几乎是单独的项目（合并它们涉及添加或更改类似430文件的内容）
简而言之，我想我的问题是：我现在怎么处理分支？
（这是第一次作为开发人员，我一直负责源代码控制和整体项目管理。所以在这里真的不知所措。）
P.S。抱歉文字墙，
答案 0 :(得分：3)
首先，叉子还可以！如果你有两个分支分支，也许值得单独考虑它们。如果每个核心代码都有很好的改进，那么我只会尝试将它们合并回来，以便与其他人共享。否则，叉子通常很有用。
话虽如此，我们假设您将努力合并它们。
首先，我会决定哪个分支实际上是您的主分支。当然，有一个被称为master，但是为了这个合并的目的，你应该决定哪个分支更加共享，如果历史发生变化，会影响更多的人。通常这确实是主分支，但如果没有其他人拥有主副本，你可以选择看起来更容易的。
好的，现在你有一个“主”分支，你应该努力不要打扰那个主分支的历史。我们将调用另一个分支tf（对于totally_forked）。是否来自大型合并提交被添加到分支的顶部，或者是一个将保留tf的大部分提交的rebase。
这是我先做的事情：
git checkout tf;
git branch tf_merging;
git checkout tf_merging;
git merge master;检查冲突的程度。查看这些是否是重复修复（在这种情况下可以删除提交）或并行修复的冲突
//如果您认为不能使用合并，请放弃此分支：
git checkout tf;
git checkout tf;
git branch tf_rebase;
git rebase -i master; //交互式rebase。使用合并尝试中的列表，尝试消除重复提交以防止。另外，看看重新排列tf的提交是否给出了更好的合并候选者
//如果发生太多冲突：
git rebase --abort
//只尝试经历几个循环的git rebase - 在rebase开始之后继续，最多可能是7-10，否则你可能会过度处理冲突并最终以最终破碎的混乱为止
如果你无法通过git实现所需的解决方案，那么可以选择一种方法，即从非主分支tf中挑选并特别想要保留的功能，并丢弃非要领。例如，如果在tf中添加了一个在master中不存在的库，则将该实用程序和其他有用的功能设置为在master之外添加一个明确的提交，以创建类似{{1}的分支并且具有相同的功能，但实际上是最有用的/核心功能更改的重新实现，并且跳过了许多非必要的提交。从本质上讲，你会杀死tf并在核心主服务器的分支之上重新实现它的最佳部分，以允许重新开始共享开发。
答案 1 :(得分：1)