git拉取请求_为您的开发项目找到正确的拉取请求工作流程

git拉取请求

所有大型软件开发项目的核心是使每个人都在同一页面上所需的通信模式。 Git作为分布式版本控制系统的兴起使企业可以重新考虑有关大型应用程序代码库的状态和更新的通信方式。 拉取请求充当神经系统，以交流有关这些项目中的更改的信息 。

随着时间的流逝，企业开发人员已对拉取请求工作流采用了多种方法，以促进有关代码状态更新的更好的通信，而不会使开发人员不知所措。 每种方法都有其优点和缺点，并且开发人员可能会对哪种方法最有效有强烈的意见。

如果您的拉取请求工作流有漏洞，请考虑一些替代方法，以查看对于组织内的不同项目或子项目是否更有希望。

集中式工作流程

当组织转移到分布式存储库时，旧版本控制系统共有的集中式工作流需要重新设计，因为拉取请求只能与两个独立的存储库或代码分支一起使用。

但是，集中式工作流程仍可以将Git或其他版本控制系统用作所有项目更改的集中式存储库。 在此工作流程中，每个人都将更改提交给主数据库。 Git的吸引力之一是，它使团队可以继续使用集中式工作流程，而他们又决定何时以及何时值得尝试其他请求请求工作流程。

与诸如Apache Subversion之类的集中版本控制系统相比，Git的一大优势在于，Git允许每个开发人员独立于其他更改而修改自己的代码库副本，然后在适当时合并他们想要的内容。 Git还支持分支和合并模型，该模型减少了多人问题并同时更改了代码库。

拉取请求工作流程

一些流行的请求请求工作流包括功能分支工作流，分叉工作流，Gitflow，GitHub流和Gitlab工作流。

所有拉取请求过程的基本过程包括几个步骤：

1. 开发人员从共享存储库中提取代码。
2. 开发人员将新代码添加到其本地存储库中，该存储库现在称为代码分支。
3. 开发人员将代码分支推送到共享库（如GitHub）。
4. 开发人员提出拉取请求，该请求将发送给对此更改感兴趣的其他开发人员。
5. 其他开发人员检查代码并进行更改。
6. 有人将新代码合并到官方存储库中，并关闭拉取请求。

功能分支工作流程

在功能分支工作流程中，开发人员处理其本地代码更改 ，然后提交拉取请求，以从其本地存储库或由存储库服务管理的单独的分支存储库中提取代码更改。 如果开发人员遇到其他开发人员的指导问题，也可以提出拉取请求。

分叉工作流程

在分叉工作流中，将更改推送到单独的存储库。 拉取请求被发送到项目维护者，他们可以决定是否将其合并回主存储库。 此工作流还可用于通知协作者将更新的代码分支拉入他们自己的存储库中。

Gitflow工作流程

2010年，文森特·德里森（Vincent Driessen）开发了Gitflow，它成为功能分支和分支工作流的流行替代方案。 Gitflow工作流与功能分支工作流相似，不同之处在于它使用暂存的Develop仓库使开发人员在将更改合并到Master仓库之前更容易讨论代码更新。

Gitflow比功能分支和派生工作流更加灵活。 尽管Driessen认为Gitflow易于理解，并允许共享的分支和发布过程，但其他开发人员则认为，它比大多数开发团队所要求的更为复杂，并创建了自己的简化变体。

GitHub流

GitHub开发了GitHub Flow，它是GitHub的简化替代品，更适合于持续集成和持续部署。 Git联合创始人Scott Chacon认为，Gitflow的主要问题之一是它围绕大发布的想法进行组织。 当开发人员每天推送一个或多个代码更新时，该组织会使事情复杂化。 这是一个示例GitHub Flow流程：

1. 在GitHub Flow中，开发人员创建了一个名为master的分支。
2. 开发人员在本地提交该分支，然后将更新推送到服务器上的同一命名分支。
3. 当分支准备合并或开发人员需要帮助时，开发人员会发送拉取请求。
4. 在其他人签署代码之后，可以将其合并到master分支中并推送到部署中。

Chacon说Git很复杂，开发人员应该避免任何会使工作流程更加复杂的事情。 他指出，Gitflow对于在较长的时间间隔内进行更正式的发布以及偶尔进行热修复是有意义的。 但是，他认为，对于每天推送更新的公司而言，GitHub Flow是更好的选择。

GitLab工作流程

同时，GitLab定义了Gitflow的另一个变体，称为Gitlab Workflows，它扩展了对Gitflow的讨论，以包括针对明确情况的特定分支，例如生产分支，环境分支和发行分支。

在此模型中，生产分支从母版创建一个单独的分支，代表当前“在生产中”。 如果您在每次合并功能分支时都无法部署到生产环境，则可能需要该分支。 “环境分支”方法创建的分支与特定的非生产环境（例如“登台”或“质量保证”）保持一致。 而且，“发行分支”有助于清晰地管理和跟踪针对特定发行版本进行的所有更改。

工作流讨论的另一个重要部分是如何促进和鼓励扩展团队内部的协作。 GitLab将协作和鼓励贡献作为头等大事，因此他们创建了GitLab合并请求，以在将给定分支合并到母版中更改代码之前管理代码讨论和代码审查。

其他方法

当然，每个开发团队都希望找到最适合他们的提取请求工作流程。 除了上面列出的选项之外，您还可以考虑拉取请求工作流程的以下选项：

• Gitworkflow：在git.git项目上使用的dogfood工作流程， 该流程具有识别哪些主题可能与正在进行的其他作品发生冲突的流程；
• OneFlow：一个反gitflow工作流，解决了有关Gitflow在大型代码库的更改历史中查找内容的困难的担忧； 要么
• Scroll.com首席技术官Kushal Dave开发的未命名工作流程

翻译自: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Find-the-right-pull-request-workflow-for-your-dev-projects

git拉取请求