Git 流与 Github 流

在 GIT 中管理软件项目的方式基本上有两种，分别是Git 流和GitHub 流。这两个流程可以帮助您管理项目并优化团队中的整个工作流程。

GitHub 流

GitHub 流程非常容易适应，因为该流程没有发布，因为您每天都在部署到生产环境。此流程涉及两种类型的分支，主分支和功能分支。

• 当你在一个项目上工作时，你需要从你的 master 分支中创建一个 Feature 分支并进行处理。
• 一旦您开发了一项功能并完全测试了更改，您就可以向主分支创建一个拉取请求 (PR)。
• 一旦根据 PR 请求审查和批准功能分支中的更改，然后将分支合并到主分支。
• 分支让您可以处理新功能并修复错误。

如何使用结帐从主分支创建新的功能分支？

$ git checkout -b 

例如，您想从“master”分支创建一个新的分支“Feature”。为此，您必须使用“-b”选项调用“git checkout”命令并将分支名称添加为“Feature”

通过使用 'git checkout' 命令，您正在创建一个新分支并自动切换到新分支。

要简单的步骤解释 GitHub 流程，请参考以下几点：

• 当您想要开发新功能或修复错误时，您需要在 master 分支之外创建一个新分支。
• 将您的更改提交到本地功能分支，并继续在同一功能分支上推送您的工作。
• 当您需要帮助或反馈并且您认为您已经完全开发了该功能并且您的分支已准备好合并时，请打开拉取请求（PR）
• 当有人审查并批准了特性分支的更改时，您可以将其合并到主分支。
• 一旦它被合并并推送到 master，您可以立即部署它。

Git 流程

Git Flow 通常比 GitHub Flow 更复杂。当您的软件具有“发布”概念时使用它。当您在一个或多个开发人员组成的团队中工作并且他们在同一功能上进行协作时，此流程非常有效。

Git Flow 中的主要分支

• Master：代表代码的生产就绪状态
• Develop：代表最新的开发变化

功能分支

每当必须处理一项新功能时，他们都会从开发分支分支出来，处理功能分支中的更改。一旦功能分支中的更改完成，向开发分支请求拉取请求。一旦功能被审查和批准，这些更改可以合并回开发分支。

发布分支

• HotFix 分支从 Develop 分支出来，并合并回 develop 和 master。
• 您需要在此分支中进行错误修复，错误修复可能会不断合并回开发分支。
• 所有要发布的功能都应该合并回开发分支
• 您可以使用反映新版本号的名称创建新的发布分支。
• 如果要在生产服务器上发布发布分支，则将发布分支合并到master，创建标签以供将来参考，然后将更改合并回开发分支，然后删除发布分支。

修补程序分支

• HotFix 分支从 Master 分支出来，然后合并回 development 和 master。
• 修复 hotfix 分支中的 bug，完成 bug 修复后，将 hotfix 分支与 master 合并，然后创建 Tag 以供将来参考，并将更改合并回 development 分支。最后，删除修补程序分支

从 CI/CD 的角度来看，我们只想分别部署开发和主分支。开发分支应发送到开发或测试环境。主分支最终进入生产环境。