为什么在 git 上创建分支是错误的

许多人经常使用 git 上的功能分支进行编码，以避免在拉取时发生冲突的麻烦和/或避免推送不完整的功能，因为这可能会破坏整个团队的系统。

我觉得这些理由毫无根据，有些甚至对开发周期有害。想在自己的小圈子里开发而不被团队其他成员分心，那可是个坏主意，想象一下：

一个五人团队要画一幅大型风景画。他们把画布分成五块，然后每个人都画自己的部分，甚至不看其他同事在做什么。两周后，他们把所有五块画布拼凑在一起，完成了这幅作品。你预计会发生什么？当然，这幅画会乱成一团，上面有很多地方没有对齐，需要在最后一刻重新绘制，最糟糕的情况是，他们得熬夜加班。听起来很熟悉吧？

我们怎样才能在不破坏现有内容且不产生持续冲突的情况下在单个分支上工作？

首先是冲突部分：沟通是关键，每天的会议都是有原因的，应该用来促进同一班级的开发人员之间的顺利合作。

现在，最棘手的部分来了：如何在不破坏现有功能的情况下提交未完成的功能？或者更糟糕的是，如何提交一个我们不确定是否正常工作的新功能？好吧，大家在同一个分支上工作的好处之一就是，如果出现问题，可以快速发现并在早期阶段修复，从而减少麻烦。

对于在不破坏系统的情况下提交代码，有一个非常好的技巧叫做“功能切换”。基本上，你需要像这样设置一个 if 语句：

if (useNewLogic) {
    awesomeNewFeatureEntryPoint();
} else {
    legacyEntryPoint();
}

这样您就可以在需要的时间和地点运行新代码，而不会危及所有环境等。

这种工作方式还有一个好处，因为每个人都在同一个地方工作，如果你的新功能与某些类合同的变化相冲突，你可以快速修复它，这意味着你正在进行持续集成。

就我个人经验而言，我发现一个更适合习惯使用分支工作的人的方法是，设置两个分支，例如：develop 和 master。而将代码迁移到 master 分支的唯一方式是通过拉取请求。

我很想在评论中读到您对此事的看法。