Git 功能分支工作流
功能分支工作流背后的核心理念是，所有功能开发都应在专用分支而不是 main 分支中进行。这种封装使多个开发人员可以轻松开发特定功能，而不会干扰主代码库。这也意味着 main 分支永远不会包含损坏的代码，这对于持续集成环境来说是一个巨大的优势。
封装功能开发还使得利用拉取请求成为可能，拉取请求是围绕分支发起讨论的一种方式。它们为其他开发人员提供了在某项功能集成到官方项目之前对其进行签字的机会。或者，如果您在某项功能中陷入困境，您可以打开拉取请求，征求同事的建议。关键是，拉取请求可以让您的团队非常轻松地对彼此的工作发表评论。
Git 功能分支工作流是一个可组合的工作流程，可以由其他高级 Git 工作流程利用。我们在 Git 工作流程概述页面上讨论了其他 Git 工作流程。Git 功能分支工作流以分支模型为重点，这意味着它是管理和创建分支的指导框架。其他工作流程更侧重代码存储库。Git 功能分支工作流可以合并到其他工作流程中。传统上来说，Gitflow 和 Git 拷贝工作流在分支模型方面使用 Git 功能分支工作流。
工作原理
功能分支工作流假设有一个中央存储库，main 存储库代表官方项目历史记录。开发人员每次开始开发新功能时都会创建一个新分支，而不是直接在本地 main 分支上提交。功能分支应具有描述性名称，例如 animated-menu-items 或 issue-#1061。这个想法是为每个分支设定一个明确、高度集中的目标。Git 对 main 分支和功能分支没有技术上的区别，因此开发人员可以编辑、暂存和提交对功能分支的变更。
此外，功能分支可以（也应该）推送到中央存储库。这使得无需接触任何官方代码即可与其他开发人员共享功能。由于 main 是唯一的“特殊”分支，因此在中央存储库中存储多个功能分支不会造成任何问题。当然，这也是备份每个人本地提交的一种便捷方式。以下是功能分支生命周期的演练。
从主分支开始
所有功能分支都是根据项目的最新代码状态创建的。本指南假设它是在 main 分支中维护和更新的。
相关资料
高级 Git 日志
查看解决方案
了解 Bitbucket Cloud 的 Git
git checkout main
git fetch origin
git reset --hard origin/main创建代码库
这会将代码存储库切换到 main 分支，提取最新的提交，并重置代码存储库的 main 本地副本以匹配最新版本。
创建新分支
为您正在处理的每个功能或事务使用单独的分支。创建分支后，在本地将其签出，这样您所做的任何变更都将在该分支上生效。
git checkout -b new-feature这会根据 main 签出一个名为 new-feature 的分支，如果分支尚不存在，-b 标记会告诉 Git 创建该分支。
更新、添加、提交和推送变更
在这个分支上，以常见方式编辑、暂存和提交变更，根据需要使用尽可能多的提交来构建该功能。开发该功能并像每次使用 Git 一样进行提交。准备就绪后，推送提交，更新 Bitbucket 上的功能分支。
git status
git add <some-file>
git commit将功能分支推送到远程存储库
将功能分支推送到中央存储库是个好主意。这可以作为一种方便的备份，当与其他开发人员合作时，这将使他们能够查看对新分支的提交。
git push -u origin new-feature此命令将新功能推送到中央存储库（原点），-u 标记将其添加为远程跟踪分支。设置跟踪分支后，无需任何参数即可调用 git push，自动将新功能分支推送到中央存储库。要获得有关新功能分支的反馈，请在 Bitbucket Cloud 或 Bitbucket Data Center 等存储库管理解决方案中创建拉取请求。从那里，您可以添加审阅者并确保在合并之前一切顺利。
解决反馈
现在，队友评论并批准推送的提交。在本地解决他们的评论，提交建议的更改，然后将其推送到 Bitbucket。您的更新显示在拉取请求中。
合并您的拉取请求
在合并之前，如果其他人对代码存储库进行了更改，则可能需要解决合并冲突。当您的拉取请求获得批准且没有冲突时，您可以将代码添加到 main 分支。从 Bitbucket 中的拉取请求合并。
拉取请求
除了隔离功能开发外，分支还允许通过拉取请求讨论更改。一旦有人完成了一个功能，他们不会立即将该功能合并到 main 功能中。相反，他们将功能分支推送到中央服务器并提交拉取请求，要求将新增功能合并到 main 功能中。这使其他开发人员有机会在变更成为主代码库的一部分之前对其进行审查。
代码审查是拉取请求的主要优势，但实际上它们被设计为一种讨论代码的常用方式。您可以将拉取请求看作是专门针对特定分支的讨论。这意味着它们也可以在开发流程的早期使用。例如，如果开发人员在特定功能方面需要帮助，他们要做的就是提交拉取请求。感兴趣的各方将自动收到通知，他们将能够在相关提交旁边看到问题。
拉取请求被接受后，发布功能的实际行为与集中式工作流程中的发布行为大致相同。首先，您需要确保您的本地 main 与上游 main 同步。然后，您将功能分支合并到 main 中，并将更新的 main 推送回中央存储库。
Bitbucket Cloud 等源代码管理解决方案可为拉取请求提供便利。
示例
以下是使用功能分支工作流的场景类型示例。场景是团队对新功能拉取请求进行代码审查。这是该模型可用于多种用途的一个示例。
Mary 开始了一个新功能
在开始开发功能之前，Mary 需要一个独立的分支来开发。她可以使用以下命令请求新分支：
git checkout -b marys-feature main这会根据 main 签出一个名为 marys-feature 的分支，如果分支尚不存在，-b 标记会告诉 Git 创建该分支。在这个分支上，Mary 以常见方式编辑、暂存和提交变更，根据需要使用尽可能多的提交来构建她的功能。
git status
git add <some-file>
git commitMary 去吃午饭
.svg?cdnVersion=2394)
Mary 在上午为自己的功能添加了一些提交。在她去吃午饭之前，最好将她的功能分支推送到中央存储库。这可以作为一种方便的备份，但如果 Mary 与其他开发人员合作，这也将使他们能够访问她的初始提交。
git push -u origin marys-feature此命令将 marys-feature 推送到中央存储库（原点），-u 标记将其添加为远程跟踪分支。设置跟踪分支后，Mary 可以在不使用任何参数的情况下调用 git push 来推送她的功能。
Mary 完成了她的功能
Mary 吃完午饭回来后，她的功能就完成了。在将其合并到 main 之前，她需要提交拉取请求，让团队的其他成员知道她已经完成了。但首先，她应该确保中央存储库有她最近的提交：
git push然后，她在自己的 Git GUI 中提交拉取请求，要求将 marys-feature 合并到 main 中，团队成员将自动收到通知。拉取请求的好处在于，它们在相关的提交旁边显示注释，因此可以很容易地询问有关特定变更集的问题。
Bill 收到了拉取请求
.svg?cdnVersion=2394)
Bill 收到了拉取请求并看了一下 marys-feature。他决定在将其整合到官方项目之前进行一些变更，然后他和 Mary 通过拉取请求来回进行了一些变更。
Mary 做了变更
.svg?cdnVersion=2394)
为了进行变更，Mary 使用了与创建功能第一次迭代时完全相同的流程。她编辑、暂存、提交更新，并将更新推送到中央存储库。她所有的活动都显示在拉取请求中，Bill 在此过程中仍然可以发表评论。
如果他愿意，Bill 可以将 marys-feature 拉取到自己的本地存储库中，然后自己操作。他添加的任何提交也会显示在拉取请求中。
Mary 发布了功能
Bill 准备好接受拉取请求后，需要有人将该功能合并到稳定项目中（这可以由 Bill 或 Mary 完成）：
git checkout main
git pull
git pull origin marys-feature
git push此流程通常会导致合并提交。一些开发人员就喜欢这样，因为它就像是将该功能与其他代码库的象征性结合。但是，如果您偏爱线性历史记录，则可以在执行合并之前将该功能重新定位到 main 顶端，从而实现快进合并。
有些 GUI 只需单击“接受”按钮即可运行所有这些命令，从而自动执行拉取请求接受流程。如果您没有，它至少应该能够在功能分支合并到 main 分支时自动关闭拉取请求。
同时，John 也在做同样的事情。
当 Mary 和 Bill 正在开发 marys-feature 并在她的拉取请求中讨论这个功能时，John 正在用自己的功能分支做同样的事情。通过将功能隔离到不同的分支中，每个人都可以独立工作，但是在需要与其他开发人员共享变更时仍然很简单。
摘要
在本文档中，我们讨论了 Git 功能分支工作流。此工作流有助于组织和跟踪以业务领域功能集为重点的分支。其他 Git 工作流，例如 Git 克隆工作流和 Gitflow 工作流，都以代码存储库为重点，可以利用 Git 功能分支工作流来管理其分支模型。本文档演示了实现 Git 功能分支工作流的高级代码示例和虚构示例。要与功能分支工作流建立的一些关键关联包括：
- 专注于分支模式
- 可以被其他面向代码存储库的工作流程利用
- 通过拉取请求和合并评论促进与团队成员的协作
在功能分支的审查和合并阶段使用 git rebase 将创建一个连贯的 Git 功能合并历史记录。功能分支模型是促进团队环境中协作的好工具。
阅读我们的 Gitflow 工作流综合教程，一键深入了解 Gitflow 工作流。
分享此文章
下一主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
Bitbucket 博客
DevOps 学习路径
