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