在每个关于Git的手册和文档中，你可以找到以下建议:不要提交到master，如果你需要对master做一些改变，你需要先创建一个新的分支，然后 merge 它。所以，我很想知道为什么？这种方法有什么好处？ 因为据我所知，如果你想恢复更改，你不需要单独的分支 - 你可以简单地通过使用以前提交的哈希来做到这一点。
在这里我找到了一个原因——如果你有很多提交，将分支与主分支 merge 然后一个接一个地推送提交会更容易 http://waterstreetgm.org/git-why-you-should-never-commit-directly-to-master/
但是，如果您的工作流程被分成许多小任务，并且这些任务中的每一个都适合一次提交，该怎么办？因此，每个分支包含一个提交。在这种情况下不提交 master 的原因是什么？
最佳答案
那些说“从不”或“总是”(就像在公认的答案中一样!？!)的人通常(总是!？!？)错了......
⚠ 一旦你了解了 git，你就会发现，通常有多种方法可以做同样的事情，你的选择主要是团队选择。
绝对没有规则阻止在 master 上提交。两种方式各有利弊。
例如，您链接的帖子更多的是作者没有充分掌握 git 的问题，而不是其他问题......
在不到 5 分钟的时间里，他本可以创建它的新分支并将其本地 master 重置为远程 ref，并在 master 分支上推送一个提交。
这是一个并不详尽的 list ......
使用功能分支(也称为GitHub 流程):
👍优点:
- 您可以清楚地看到软件中引入了哪些功能( merge 分支时)
- 这使代码审查更容易(如果您尽早提出 pull 请求，则在 merge 之前或在整个开发过程中，这是一个很好的做法)
- 如果需要可以轻松还原(只需还原 merge 提交)
- 轻松进行概念验证(但很难在 master 中重新引入)
- 仅在进行需要代码审查或 merge 提交前的 CI 结果的远程或开源开发时才有效(但不一定在公司中使用，因为它在开源世界中很成功)
👎 缺点:
- git 历史可能难以阅读(为此，在
merge之前的rebase可以使历史更易于阅读) - 开发人员可以在不与主服务器同步的情况下轻松进入隧道效应(最好使用 rebase 而不是同步 merge )，并最终以 merge hell 告终
使用“基于主干的开发”(和功能切换。真正好的开发实践，您应该看看):
👍优点:
- 真正的持续集成(具有所有好处，例如更快发现错误)
- 防止 merge hell
- git 更简单、更容易掌握
- 当你是唯一的开发者时完全没问题
- 当你想要进行持续部署/交付时的先决条件(每次提交都是一个小步骤，可以最大限度地降低引入大错误的风险，很难在更改的大量代码行中找到原因)
- 一篇很好的 Infoq 文章告诉我们需要持续交付(DevOps 实践):Trunk Based Development as a Cornerstone for Continuous Delivery
- 有人就此主题制作了一个非常详尽的网站:https://trunkbaseddevelopment.com/
👎 缺点:
- 引入功能的时间不明确(应该查看已启用的功能切换)
- 需要有良好的开发实践，例如编写单元测试(但也可以被视为专家)
- 需要(有时)通过抽象掌握分支(a good explanation by Martin Fowler)。这降低了风险，但需要更多时间。
选择适合您团队的一个并在大部分时间坚持使用，当您认为它更有意义时应用另一个并解决您遇到的新问题...
Martin Fowler 关于该主题的一篇非常好的、长而完整的文章:https://martinfowler.com/articles/branching-patterns.html (§ 比较功能分支和持续集成。但是您必须阅读几乎所有内容才能掌握它...)
关于git - 不 promise 掌握的原因，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45783200/