我有一个大型的Web应用程序项目，基本上只有一个分支--Master。但是，我将为错误修复创建一个新分支，然后将该分支合并到主分支中。十分简单。
我想进行大型用户界面大修，这需要一段时间才能完成 - 几周，如果不是几个月。但是，在此期间我仍然需要修复错误。
我试图从逻辑上理解如何做到这一点。我是否只是创建一个“UIUpdate”分支，在那里进行所有UI更新，同时创建和合并错误修复分支？完成UI检修后，我可以简单地将该分支合并到主分支中并假设它不会覆盖我的所有错误修复代码吗？
我的大脑很难理解这是怎么可能的。
谢谢
答案 0 :(得分：2)
我认为你真正的问题有点不同。当您创建小错误修正分支时，您可能只在错误修复分支上进行提交，然后当您将其合并到主数据库时，您可能正在获得快进合并和完全线性历史记录。现在您有一个主分支和一个新的功能分支，并且您正在两个分支上进行提交：主分支上的bugfix提交，功能分支上的功能提交。现在你意识到当你想要合并它们时，历史将不再是线性的，你不确定会发生什么。
如果上面描述了您的问题，那么通过阅读Git分支模型的介绍（例如this one）可能会得到最好的服务。好消息是，这种情况正是git的分支和合并模型的设计目标。
简短的回答是，只要您的错误修复并且您的新功能更改不会修改相同的代码行，git就会将它们合并在一起，就像您已经一个接一个地进行更改一样。如果他们确实触摸了相同的代码行，则需要解决合并冲突（您可以在上面的链接中阅读）。最后，您的错误修复和功能代码可能不会触及相同的行，但仍然存在逻辑冲突。例如，如果您的错误修复添加了对变量的引用，并且您的要素代码重命名了相同的变量，那么在合并的代码中您将引用您需要修复的旧变量名称，并且git将无法告诉你它。
答案 1 :(得分：1)
是的，你可以做到这一点。 Git旨在允许多个分支很容易共存。您将按照以下方式创建新分支：
# running this operation while on master
git checkout -b this_cool_feature_Im_working_on
现在重要的一点是让this_cool_feature_Im_working_on与主人保持同步，但不一定相反。我建议每次你创建一个bug修复，然后再将其合并到master中，然后你也可以将该bug修复合并到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合并到this_cool_feature_Im_working_on，那么当您最终将this_cool_feature_Im_working_on合并回master时，这应该只会产生一些小且容易解决的合并冲突，可能没有。此工作模式允许单独的功能分支，就像您所说的那样存在。它还假设团队已准备好手动解决可能发生的小合并冲突，但我再次强调，解决合并冲突在git和部分预期工作流程中比在像snv这样的CSV中更容易解决。
答案 2 :(得分：0)
合并后，您的错误修复不会被覆盖，但这并不能保证合并顺利进行。例如，如果您需要更改函数的签名作为错误修复的一部分，并且新的UI代码使用该函数 - 显然这会使您的项目崩溃。这是一个简单的案例 - 合并新UI后，更难以修复更细微的修复。
更好的方法是在每次错误修复后将修复程序从master（或直接从bug修复分支）合并到新的UI分支中。这样，bug修复程序在你的内存中仍然是新鲜的，所以如果它打破了新的UI，你可以更容易地修复它，而不是几个月后，当你合并UI时。
另一个重要的好处是，如果事实证明冲突不能从新的UI代码解决，你必须修复错误修复本身，以使其适用于新的UI ，你可以马上做（在bug修复分支中，当然 - 而不是在新的UI分支中！）在任何新代码依赖于bug修复之前。