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