Git 功能分支工作流程是如何支持社交化编程

Git 功能分支工作流程是如何支持社交化编程的。
我们来谈谈存储库和工作流程的准则。
为每个组件创建一个存储库，无论它是一个微服务还是你正在构建的其他东西。不要把多个微服务放在一个存储库中。那些被称为单体存储库，是不被提倡的。人们经常创建我们所说的 “单体存储库”，即在一个存储库中包含多个微服务，这样做是为了演示更方便，但生产代码不应如此。你不会希望有人为了获取自己关心的代码，而不得不检出大量他们并不关心的代码。每个存储库最好只有一个组件或微服务，这一点非常重要。不要害怕创建多个存储库。
为你正在处理的每个问题创建一个新分支。不要使用长期存在的分支。我不赞成设置一个 “开发” 分支，把所有工作都合并到这个分支来完成，这是老一套的想法了。在 Git 中，分支非常轻量。有主分支，还有功能分支，仅此而已。当你完成了功能分支的工作，就删除它。不要对它太留恋，因为你删除它之后，在处理下一个问题时再创建一个新的分支。
使用拉取请求将代码合并回主分支。代码进入主分支的唯一方式应该是通过拉取请求。拉取请求为其他人提供了查看和审查你代码的机会。绝对不要自行合并自己的拉取请求，千万别这么做！你应该总是让团队中的其他人来合并你的拉取请求，因为每个拉取请求都是一次代码审查的机会。让他们查看代码，确保代码对他们来说是合理的，然后让他们进行合并。这样，进入存储库的所有代码都能经过两个人的审查。
我们把这种方式称为 Git 功能分支工作流程，下面来看看它是如何运作的。从 GitHub 存储库开始，你为自己的组件创建一个新存储库；如果你是在为其他人的组件做贡献，那就复刻一个现有的存储库。接下来，将其克隆到你的工作站，它就成了你的本地存储库，你所有的更改都将在这个存储库中进行。然后，创建一个分支来开发你的功能。处理漏洞或其他修复工作时也可以采用这种方式。它被称为功能分支，其意义在于，这个分支中的代码与你正在处理的 GitHub 问题相关联。当你准备好将代码提交回主项目时，或者如果你只是希望有人审查你的更改以获取反馈，就把代码推送到一个远程分支。最后，创建一个拉取请求，请求审查你的更改。拉取请求会被审查，如果代码完整且符合团队设定的标准，它将被合并回主分支，成为原始 GitHub 存储库的一部分。
在本文中，你了解到：为每个组件创建存储库、遵循 Git 功能分支工作流程、创建分支以及使用拉取请求是很好的实践方法。