我有一个大型 Web 应用程序项目，基本上只有一个分支 - Master。但是，我将为错误修复创建一个新分支，然后将该分支合并到主分支中。十分简单。
我想做一个大型的用户界面大修，这需要一段时间才能完成——如果不是几个月的话，也是几周。但是，在此期间，我仍然需要在此过程中进行错误修复。
我试图从逻辑上理解如何做到这一点。我是否只是创建一个“UIUpdate”分支，在那里进行所有 UI 更新，同时创建和合并错误修复分支？一旦 UI 大修完成，我可以简单地将该分支合并到主分支并假设它不会覆盖我所有的错误修复代码吗？
我的大脑很难理解这怎么可能。
谢谢
我认为你真正的问题有点不同。当你创建小的 bugfix 分支时，你可能只在 bugfix 分支上提交，然后当你将它合并到 master 时，你可能会得到一个快进的合并和一个完全线性的历史。现在您有一个主分支和一个新功能分支，并且您正在两个分支上进行提交：主分支上的错误修复提交，功能分支上的功能提交。现在你意识到当你想合并它们时，历史将不再是线性的，你不确定会发生什么。
如果上面描述了您的问题，那么您最好阅读 Git 分支模型的介绍，例如这个. 好消息是这种情况正是 git 的分支和合并模型的设计目的。
简短的回答是，只要您的错误修复和新功能更改不修改相同的代码行，git 就会将它们合并在一起，就像您一个接一个地进行更改一样。如果它们确实涉及相同的代码行，您将需要解决合并冲突（您可以在上面的链接中阅读）。最后，您的错误修复和功能代码可能不在同一行，但仍然存在逻辑冲突。例如，如果您的错误修复添加了对变量的引用，并且您的功能代码重命名了相同的变量，那么在合并的代码中，您将引用需要修复的旧变量名称，而 git 将无法告诉你。
是的，你完全可以这样做。Git 旨在允许多个分支轻松共存。您将按如下方式创建新分支：
# running this operation while on master
git checkout -b this_cool_feature_Im_working_on
现在重要的部分是this_cool_feature_Im_working_on与 master 保持同步，但不一定相反。我建议您每次创建错误修复，然后将其合并到master该修复中，然后再将错误修复合并到该修复this_cool_feature_Im_working_on中。这将确保this_cool_feature_Im_working_on知道仍在发生的变化master。这很重要，因为这可以最大程度地减少发生合并冲突时处理的难度。this_cool_feature_Im_working_on将相对接近，master因为所做的更改master发送到this_cool_feature_Im_working_on. 这使您的工作井井有条。您将无法阻止合并冲突的发生，但不要害怕它们，解决它们是 git 工作流程的一部分。
当你准备好后，你可以合并this_cool_feature_Im_working_on回master。如果您一直在定期合并master，this_cool_feature_Im_working_on那么当您最终重新合并时，this_cool_feature_Im_working_on应该master只会产生一些小的且易于解决的合并冲突，可能不会。这种工作模式允许像您正在谈论的那样存在单独的功能分支。它还假设团队将准备好手动解决可能发生的小合并冲突，但我再次强调，在 git 中解决合并冲突很容易，并且是预期工作流程的一部分，比在 CSV 等 CSV 中更大。
合并后，您的错误修复将不会被覆盖，但这并不能保证合并会顺利进行。例如，如果您需要更改函数的签名作为错误修复的一部分，并且新的 UI 代码使用该函数 - 显然这会使您的项目崩溃。这是一个简单的案例——一旦你合并了新的 UI，更微妙的修复将更难修复。
更好的方法是在每个 bug 修复后将来自 master（或直接来自 bug-fix 分支）的修复合并到新的 UI 分支中。这样，错误修复在您的记忆中仍然是新鲜的，因此如果它破坏了新的 UI，您将比几个月后合并 UI 时更容易修复它。
另一个重要的好处是，如果事实证明无法从新 UI 代码中解决冲突，并且您必须自行修复错误修复以使其与新 UI 一起使用，您可以在任何新代码依赖于该错误修复之前立即执行（当然是在错误修复分支中 - 而不是在新的 UI 分支中！）。