Git-直接在master上工作会出现什么问题？

我已经看到了很多有关git分支模型的建议，最普遍的观点似乎是直接在master分支上进行更改是一个坏主意。

我们的一位同事很高兴直接在主分支上进行更改，尽管进行了几次交谈，但他们似乎不太可能更改此更改。

在这一点上，我无法说服一个不擅长直接在师傅上工作的同事，但我想了解会与他的工作方式相抵触的事物，知道何时需要重新访问这个问题。

将提交直接推送到主目录时会遇到一些问题

• 如果将进行中的状态推送到远程，则主服务器可能会损坏
• 如果另一个开发人员从master开始为新功能工作，那么她将处于潜在的故障状态。这减慢了发展
• 不同的功能/错误修正不是隔离的，因此所有正在进行的开发任务的复杂性都集中在一个分支中。这增加了所有开发人员之间必要的通信量
• 您不能执行拉取请求，这是代码检查的良好机制
• 通常，您不能压榨提交/更改git历史记录，因为与此同时其他开发人员可能已经拉了master分支

向他解释，新功能需要他们自己的开发分支，该分支可以在投入生产之前先部署到测试环境。

否则，您将永远处于功能未完成的状态。您无法将半完成的功能部署到生产中，因此，如果您直接在master分支上工作，则其他任何人都必须等待您完成功能，然后其他人的更改才能投入生产（包括错误修复）。

对功能使用独立的分支意味着可以独立于其他每个功能来测试和部署每个新功能。

主人应该是潜在的释放者。期。主机中不应有任何完成的工作（除非已通过功能标记禁用）

如此说来，我已经看到一些团队使他们的流程复杂化。

集成到母版时不使用PR是一个错误，因为开发人员将无法选择何时进行集成。

一个开发分支带来的价值很小。通常，它只会使事情复杂化。许多功能分支带来了很多价值。

为每个环境（开发，测试，生产）建立分支是一个错误。这超出了git的范围，应由发布管道处理。应该将完全相同的构建部署到所有环境，如果每个环境都有分支，则不可能。

如果某个功能太大，那么一两天之内无法完成，那么功能分支的所有工作都应该放在单独的分支中并与PR集成。

• 母版应反映出生产分支，即最终版本。
• 直接在master环境中工作意味着，如果您创建错误，则除了“撤消/删除/重置”提交外，别无选择“返回”，这不是一种干净的工作方式，并且可能导致您丢失新代码的一部分，还可以
• 当然，在开发的最初阶段，也许您可​​以直接在master上开始工作，但是在交付一些东西之后，您应该使用开发，测试或实验分支而不接触已发布的完整工作版本。

首先，我想指出的是，在git中，每个pull实际上都是分支操作，而每个push都是合并。该master开发人员的机器上是从一个完全独立的分支master上您共享中心回购，从技术角度讲平等的地位。我偶尔会将本地版本重命名为upstream如果我更适合我的目的，或其他名称。

我指出这一点是因为许多组织认为他们比您的同事更有效地使用分支机构，而实际上他们所做的只是为分支机构创建其他名称而已，而这些都不会保存在历史记录中。如果您的同事正在一次原子提交中提交要素，那么撤消就像要素分支的合并提交一样容易。绝大多数功能分支应该是短暂的，并且无论如何都应经常合并。

话虽如此，他的工作方式的主要弊端是双重的。首先，这使得在未完成的功能上进行协作非常困难。但是，在需要协作的那些时间创建分支并不困难。

其次，这使得合并前的审核非常困难。在这一点上，您实际上不需要说服他。您可以采用github，gerrit或gitlab之类的工具，并要求拉取请求代码进行审查，并通过所有合并的自动化测试。如果您没有做这样的事情，坦率地说，您没有充分利用git的潜力，也难怪您的同事没有看到这种潜力。

其他答案已经提到了不直接在master上工作的各种优点（隔离功能，始终在master上可交付的代码等）。

对我来说，您似乎有一个不同的问题。显然，您没有所有开发人员都同意或使用的开发流程（或者您的开发人员完全忽略了该流程）。

您是否具有功能分支，这些分支已合并到master中，或者您也具有不同的发行版分支，或者您使用的是完全不同的过程？

“不使用master分支”是不够的。

我们的一位同事很高兴直接在主分支上进行更改，尽管进行了几次交谈，但他们似乎不太可能更改此更改。

这使我相信还有更多问题。是否进行母版工作是关于如何，什么以及何时发布产品的更大哲学的一部分。

因此，与“您永远都不应该在主版本上工作”串联在一起，您是否进行了功能测试，是否测试了彼此的工作，是否审查了彼此的代码。验收和整合测试。

如果您没有以上所有内容，而只是为了“做git”而已，那么您不妨使用master。

直接在分支机构上工作没有“坏习惯”。但是，您必须决定哪种方法最能支持您的流程：

问题1：您的母版是否可以代表软件的当前发行状态？然后，您应该引入一个全球开发分支，并在发布开发结束时合并开发。

问题2：您是否要进行代码审查流程？然后，您应该具有“功能分支”，这些特征分支将通过拉取请求合并到主节点（或开发，如果有的话）。

问题3：是否需要与其他开发人员共享中间代码状态，而这些中间状态不应发布到生产（或测试）中？就是这种情况，不止一个开发人员开发了一项功能。然后，您应该引入“功能分支”。