探索功能分支工作流
功能分支工作流背后的核心理念是，所有功能开发都应在专用分支而不是主分支中进行。
通过封装，多个开发人员可以轻松处理特定功能，而无需干扰主代码库。 这也意味着主分支永远不会包含损坏的代码，这是持续集成环境的巨大优势。
封装功能开发还可以使用拉取请求，这是开始围绕分支进行讨论的一种方法。 它们允许其他开发人员在将其集成到官方项目之前注销功能。 或者，如果你在功能特性开发中遇到困难，可以打开 Pull Request（拉取请求），寻求同事的建议。
拉取请求使你的团队可以轻松评论对方的工作。 此外，功能分支也可以（且应）推送到中央存储库。 它允许与其他开发人员共享功能，而无需触摸任何官方代码。
由于主分支是唯一的“特殊”分支，因此在中央存储库中存储多个功能分支不会造成任何问题。 这也是备份每个人的本地提交的一种便捷方法。
发布分支工作流
除了功能分支工作流之外，Git 分支工作流中另一种常用的策略是发布分支策略。 此策略涉及专门创建专用分支来准备发布。 发布分支通常是从稳定的功能分支创建的，确保它仅包含经过全面测试和验证的代码。 创建后，发布分支将进行额外的测试、bug 修复和稳定工作，以便为部署准备代码库。 发布分支允许将与发布相关的活动与正在进行的功能开发隔离，从而提供一个受控的环境，用于完成和完善即将发布的版本。 在发布分支上进行了所有必要的调整和验证后，它将合并到主分支或直接部署到生产中，具体取决于团队的发布过程。 发布分支策略可帮助团队管理协调发布活动的复杂性，同时保持稳定的主分支进行持续开发。
基于主干的开发工作流
基于中继的开发工作流假定中央存储库，主要表示官方项目历史记录。 开发人员不直接将代码提交到本地主分支，而是在开始处理新功能时创建新分支。 功能分支应具有描述性名称，例如 new-banner-images 或 bug-91。 其思路是为每个分支提供一个清晰、高度专注的用途。
Git 在主要分支和功能分支之间没有技术区别，因此开发人员可以编辑、暂存和提交对功能分支的更改。
创建分支
显示分支创建的图示。
在处理项目时，在任何给定时间都有许多不同的功能或想法，其中一些功能或想法已准备就绪，其他功能尚未完成。 分支的存在可帮助你管理此工作流。 在项目中创建分支时，可以创建一个可以尝试新想法的环境。
除了为新功能或修补程序创建分支之外，发布分支工作流后面的团队还会专门创建专用分支来准备发布。 这些发布分支通常派生自稳定的功能分支，以确保它们包含经过全面测试和验证的代码。 创建后，发布分支将进行额外的测试、bug 修复和稳定工作，以便为部署准备代码库。
添加提交
创建分支后，就可以开始更改。 每当您添加、编辑或删除文件时，您都要提交更改并将其添加到您的分支。
添加提交可在功能分支上工作时跟踪进度。
提交还会创建一个你工作的透明历史，其他人可以通过这些历史来了解你的行动及原因。
每个提交都有一条关联的提交消息，说明为何进行了特定的更改。
此外，每个提交被视为单独的更改单元。 如果找到 bug，或者你决定以不同的方向前进，则可以回滚更改。
提交消息至关重要，尤其是因为 Git 跟踪更改，并在推送到服务器后将其显示为提交。
通过编写明确的提交消息，可以让其他人更轻松地跟进并提供反馈。
打开拉取请求
显示打开拉取请求操作的 
拉取请求启动对您提交内容的讨论。 由于它们与基础 Git 存储库紧密集成，因此任何人都可以在接受请求时确切地看到将合并哪些更改。
可以在开发过程中的任何时间点打开拉取请求：
- 你几乎没有或没有代码，但想要共享屏幕截图或常规想法。
- 你停滞不前，需要帮助或建议。
- 你已准备好让某人查看你的工作。
在你的拉取请求消息中使用 @mention 系统，你可以请求特定人员或团队给出反馈，无论他们是在走廊的另一头，还是相隔 10 个时区。
拉取请求有助于参与项目和管理对共享存储库的更改。
如果您使用分叉 & 拉取模型，拉取请求是一种通知项目维护人员的方式，让他们考虑您希望进行的更改。
如果使用共享存储库模型，拉取请求有助于在将建议的更改合并到主分支之前启动代码评审和对话。
讨论并审查代码
显示分支的 
打开一个 Pull Request 后，审查您所做更改的人员或团队可能会有疑问或评论。
也许编码样式与项目准则不匹配，更改缺少单元测试，一切都看起来很好，并且道具是有序的。
拉取请求旨在鼓励和捕获此类对话。
还可以继续推送到分支，考虑有关提交的讨论和反馈。
假设有人评论说你忘记了做某事，或者如果代码中有 bug，你可以在你的分支中修复它并推送更改。
Git 会在统一的拉取请求视图中显示您的新提交和收到的任何反馈。
拉取请求注释是用 Markdown 编写的，因此你可以嵌入图像和表情符号、使用预先格式化的文本块和其他轻型格式。
部署
使用 Git，可以从分支进行部署，以便在合并到主服务器之前在环境中进行最终测试。
当您的拉取请求已被审核且分支通过了您的测试后，可以部署您的更改以验证这些更改。 如果分支通过部署现有主服务器导致问题，则可以回滚它。
合并
验证更改后，是时候将代码合并到主分支了。
合并后，Pull Request 将保存代码历史变更的记录。 因为他们是可搜索的，所以他们让任何人及时回去了解为什么以及如何做出决定。
通过将特定关键字合并到拉取请求文本中，可以将问题与代码相关联。 合并拉取请求后，相关问题也会自动关闭。
此工作流有助于组织和跟踪专注于业务域功能集的分支。
其他 Git 工作流（如 Git 分叉工作流和 Gitflow 工作流）都以存储库为重点，可以使用 Git 功能分支工作流管理其分支模型。