所以，我对git相当新，我在过去几周阅读了一些内容之后，我读了一些人说主分支不应该改变而是分支和然后合并到。
我很高兴能够与分支机构合作，但是对于不在主分支机构工作的原因感到疑惑？
答案 0 :(得分：54)
其他人在master中没有直接进行更改的情况非常好，我同意这些观点。然而，总是提倡像这样的工作流程有时会让人们觉得git认为它是不必要的复杂，所以我想提供一个对应点。
如果你有一个人或一个非常小的团队并且你的开发是高度线性的，即你很少一次处理多个东西并且每个功能通常在开始下一个之前完成，那么实际上几乎没有不能直接从master开始工作。如果需要，可以在任何时候返回并添加分支。我强烈建议您了解功能分支工作流程，但如果您觉得在您的情况下只是添加额外的步骤而不向您购买任何东西，我保证我不会告诉git警察。
答案 1 :(得分：27)
我想通常的推理是，主分支应代表代码的“稳定”历史记录。使用分支来试验新功能，实现它们，当它们已经足够成熟时，你可以将它们合并回主机。
这样，master中的代码几乎总是可以毫无问题地构建，并且主要可以直接用于发布。
让我们以git.git（官方git存储库）为例。有几个分支，最值得注意的是：
所以，master包含很可能在下一个git版本中结束的代码。 next包含经过测试的代码，可能会合并到master分支中。 pu（建议的更新，iirc）包含相当新的（可能是）未经测试的代码。
pu被认为是不稳定的，将被重置并重新设定为junio的喜好。 next可能会在发布后或发布周期中重置，但这种情况不太常见。 master是一成不变的，在被推送并公之于众之后永远不会改变。
您知道，如果这些更改被视为有价值并且不会破坏内容，那么这些更改将从pu合并到next以及从next合并到master。
分支maint用于制作错误修正，这也适用于旧版本的git。 maint通常合并为next和/或master。
答案 2 :(得分：8)
使用像Git或Mercurial这样的DVCS（分布式版本控制系统）需要考虑的一件事就是“发布”工作流程（orthogonal to the branching workflow）。
当你只有分支机构时，你会问自己它们所代表的开发工作量
如果master表示稳定代码，例如knittl中的his answer详细信息，那么是，您需要从/ merge转移到master。
但是当你可以克隆/推/拉（即发布到不同的repos，它们本身可能有不同的用途）时，'master'可以扮演从repo到repo的不同角色。
master通常代表最稳定的代码。master，还有一些修补程序维护分支可用于紧急修复。master分支，从push to push重写，以便通过一个钩子运行一些静态分析代码，该钩子只监视该测试仓库的所述master分支。 答案 3 :(得分：2)
在双方进行提交时 - 这意味着在本地存储库和上游，例如来自其他团队成员 - 可能会发生冲突。这意味着文件和特定行都由两者编辑。在这种情况下，需要一些手动合并处理。
master分支用于在您无法访问上游（移动使用或网络故障）时具有代表上游的本地分支。当有一个代表上游变化的本地分支时，更容易进行合并解析和其他工作。
答案 4 :(得分：0)
不确定我的理解是否正确，我是git新手。
当您拥有多个功能时，我认为这会使生活变得更轻松。假设您有一个项目，并致力于功能A，然后再实现功能B。
现在可能会发生，您确定整个功能A都是错误的，并且您想要拥有仅具有功能B而没有A的项目版本。 如果一切都掌握了，那么这个任务就很棘手。
如果每个功能都在其自己的分支上，则此任务很容易： 您使用旧的主版本（没有A和没有B）。 您合并分支B。 完成。