优化或报错有奖什么是Git工作流？你可以理解为代码管理的分支策略，它不仅仅是版本管理范畴，更服务于项目流程管理和团队协同开发。所以，有必要制定适合自己研发场景的工作流。
下面介绍四种工作流的工作方式、优缺点，以及使用中的一些注意事项。
集中式工作流
功能分支工作流
Git flow工作流（推荐）
Forking工作流
研发团队可以根据实际研发场景制定合理的工作流，能有效提高项目管理水平和团队协同开发能力， 并通过CodeArts Repo平台，高效、安全的管理代码资产，将更多的精力集中在业务开发上，实现持续集成、持续交付和快速迭代的目标。
一、集中式工作流
集中式工作流适合5人左右小开发团队，或是刚从SVN工具转型为Git的团队，它只有一个默认的maste分支（相当于svn的trunk主分支），所有人的修改都是在master分支上进行的。但是，这种工作流无法充分发挥git优势和多人协同，不推荐使用。
工作方式
开发人员将master分支从中央仓库克隆到本地，修改完成后再推送回中央仓库master分支。
优点
不涉及分支交互操作。
缺点
不适合人员较多的团队，当人员10+时，解决开发人员之间的代码冲突会耗费很多时间。
master分支因提交频繁会导致分支不稳定，不利于集成测试。
Tips：如何尽量避免产生冲突和不合理的提交历史？
开发人员在开发一个新功能之前，一定要在本地同步中央仓库最新代码，使自己的工作基于最新的代码之上；开发完成后，在提交新功能到中央仓库前，需要先fetch中央库的新增提交，并rebase自己的提交。这样做的目的是，把自己的修改加到中央仓别人已经提交的修改之上，使最终的提交记录是一个完整的线性历史，而不是环形，工作流举例如下图所示。
开发人员A和开发人员B同时在某个时间拉取了中央仓库的代码。
开发人员A先完成了自己的工作，并提交到中央仓库。
开发人员B需要在本地执行git pull –rebase中央仓库的新提交，这时开发人员B的本地仓库就包含了开发人员A修改的内容，并在A的基础上增加了自己的修改。
开发人员B将代码推送到中央仓库。
二、分支开发工作流
通过新建几个功能分支，增加开发者的交流和协作，它的理念是所有的功能开发都应该在master分支外的一个独立分支进行，这种方式隔离了开发者的工作空间不被互相干扰，保证了master分支的稳定性。
工作方式
开发人员每次在开始新功能开发前，需要在master分支上拉取一个新分支，并起个有描述性的名字，比如video-output或issue-#1061，这样可以让分支用途明确。功能分支不但存在开发人员本地仓库，也应该推送到中央仓库，这样就可以在代码不合入master分支的情况下与其他开发人员分享代码。
优点
分支合并前可以使用pull request进行code review。
降低了master分支的提交频率。
缺点
只有一个master分支作为集成，仍然不是很稳定，不适合大型开发。
三、Git Flow工作流
本节说的是分支管理中的Git-Flow。要注意，分支管理在软件开发领域存在很大的意见分歧，有的人认为必要的版本分支可以更好的进行团队协作，而有的人则认为，坚持一个统一的版本是最好的。我们姑且不论哪种思想更加正确，本节只讨论分支的一种规范策略，即Git-Flow。
Git-Flow是什么？它是一组Git管理规范策略。通过严格执行这些策略，帮助中小型研发团队，能够更好的规范自己的开发工作。它的好处有：
并行开发：各个特性与修复bug，可以并行。
团队协作：多人开发过程中，大家都能够理解其他人的当前工作。
灵活调整：通过Hotfix分支，支持各种紧急修复的情况。
Git Flow策略建议，一个完整的项目库应包含下面五个分支：
master分支：最为稳定，功能比较完整，随时可发布的代码。
develop分支：用于平时开发的主分支，并一直存在，永远是功能最新最全的分支，包含所有要发布到下一个release的代码，主要用于合并其他分支。
feature分支：用于开发新的功能的分支，一旦开发完成，通过测试，合并回develop分支进入下一个release。
release分支：用于发布准备的专门分支。
hotfix分支：用于修复线上代码的bug 。
所有开发分支从develop分支拉取。
所有hotfix分支从master分支拉取。
所有在master分支上的提交都必须要有tag ，方便回滚。
只要有合并到master分支的操作，都需要和develop分支合并下，保证同步。
master分支和develop分支是主要分支，主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。
下表给出了Git-Flow工作模式中分支的使用建议：
分支名 | Master | Develop | Feature_1\2... | Release | HotFix_1\2... |
|---|---|---|---|---|---|
说明 | 核心分支，配合标签，用于归档历史版本，要保证其中的版本都是可用的。 | 开发主分支，用于平时开发的主分支，应永远是功能最新最全的分支。 | 新特性开发分支，用于开发某个新特性，可以几条并行存在，每条对应一个或一组新特性。 | 发布分支，用于检出某个要发布的版本。 | 快速修复分支，用于当现网版本发现bug时，拉出来单独用于修复这些bug的分支。 |
有效性 | 长期存在 | 长期存在 | 临时 | 长期存在 | 临时 |
何时被创建 | 项目仓库建立之初 | 在master分支被创建之后 | 收到新特性任务时，基于develop分支创建 当正在开发的新特性任务被拆分成出子任务时，基于对应的父feature分支创建 | 项目首次发布前，基于develop分支创建 | 当master、bug版本中发现问题时，基于对应版本（一般是master分支）创建 |
何时直接在此分支上开发 | 从不 | 一般不建议 | 当被创建出来，开始开发新特性时 | 从不 | 当被建立出来时 |
何时被其它分支合入 | 项目版本封版时，被develop或release分支合入 已发布版本中发现的bug被修复后，被对应的hotfix分支合入 | 新特性开发完成后，feature分支合入到此分支 当项目启动开发一个新版本时，被上一次历史发布版本（release、或master）合入 | 子feature分支开发、测试完成后，会合入到父feature分支 | 当需要发布一个版本时，被develop分支合入 | - |
何时合入到其它分支 | - | 当要发布版本时，合入到release分支 当需要归档版本时合入到master分支 | 当该分支上的新特性开发、测试完成时，合入到develop分支 | 当完成一次版本发布，将该版本归档时，合入到master分支 当要基于某一个发布版本，开始开发一个新版本时，合入到develop分支，起到初始化版本的作用 | 当其对应的bug修复任务完成时，会将其作为修复补丁合入master、develop分支 |
何时结束生命周期 | - | - | 其对应的特性已经验收(发布、稳定)后 | - | 其对应的bug修复，已经验收(发布、稳定)后 |
关于分支的常用Git命令
新建分支
git branch <分支名称> #在本地仓库基于目前的工作区，创建一条分支
示例如下：
git branch branch001 #在本地仓库基于目前的工作区，创建一条名为 branch001 的分支
切换分支
切换分支可以理解为将该分支的文件内容检出到当前的工作目录。
git checkout <分支名称> #切换到指定分支
示例如下：
git checkout branch002 #切换到名为 branch002 的分支
新建并直接切换到新建的分支
有一种快速的操作办法，可以直接新建并切换到新建出来的分支，其用法如下：
git checkout -b <分支名称> #在本地仓库基于目前的工作区，创建一条分支，并直接切换到该分支
示例如下：
git checkout -b branch002 #在本地仓库基于目前的工作区，创建一条名为 branch002 的分支，并直接切换到该分支
查看分支
您可以使用对应的命令查看本地仓库的分支、远程仓库的分支，亦或是全部，这组命令只是将分支名称罗列，如果想查看分支内的具体文件，请使用上述的切换分支。
git branch #查看本地仓库分支
git branch -r #查看远程仓库分支
git branch -a #同时查看本地仓库与远程仓库的分支
合并分支
当一条分支上的开发任务完成了，有时需要将其合并到另一条分支，以做功能归档，合并分支可以理解为将另一条分支最新的修改同步到当前所处分支，其用法如下：
git merge <要合并过来的分支的名称> #将一条分支合并到当前的分支中
分支合并前一般要先切换到被合入的分支，下面以将branch002 合入到master分支为例进行演示：
git checkout master #切换到master分支 git merge branch002 #将名为 branch002 的分支合入到master分支
删除本地分支
git branch -d <分支名>
示例如下：
git branch -d branch002 #删除本地仓库中，名为 branch002 的分支
删除远程仓库分支
git push <远程仓库地址或别名> -d <分支名>
示例如下：
git push HTTPSOrigin -d branch002 #从别名为HTTPSOrigin 的远程仓库中删除名为branch002 的分支
将本地新建的分支推送到远程仓库
git push <远程仓库地址或别名> <分支名>
示例如下：
git push HTTPSOrigin branch002 #将本地名为 branch002 的分支，推送到别名为HTTPSOrigin的远程仓库
说明：
如果推送失败请检查连通性：
确保您的网络可以访问代码托管服务。
ssh -vT git@********.com |
如果返回内容含有“connect to host **********.com port 22: Connection timed out”，则您的网络被限制，无法访问代码托管服务，请求助您本地所属网络管理员。
四、Forking工作流
Forking工作流区别于前三种工作流的最大特点是每个开发人员都有一个从公共仓库fork出来的属于自己的公共仓。Forking工作流适合外包、众包以及众创和开源场景。接包方的开发人员从项目公共仓fork自己的公共仓库进行操作，并不需要被项目公共仓直接授权，Forking工作流如下图所示。
工作方式
将“项目公共仓”fork出一个“个人公共仓”。
将“个人公共仓”clone到“本地仓库”。
操作“本地仓库”，修改完成后提交到“个人公共仓”。
为“个人公共仓”提交一个pull request给项目维护者，申请代码合入“项目公共仓”。
项目维护者在本地review、验证本地提交，审核通过后push进入“项目公共仓”。
说明：
如果开发人员A的代码未被审核通过合入“公共仓库”，而此代码对开发人员B有借鉴作用，开发人员B可以直接从开发人员A的“个人公共仓”拉取代码。
优点
开发人员之间如果需要代码协作，可以直接从其他人的“个人公共仓”拉取，无需等到代码提交到项目公共仓。
“项目公共仓”无需为每个代码贡献者授权。
项目维护者通过审核pull request成为代码安全的重要防线。
仓库分支的选择可以根据项目实际情况综合使用前三种工作流。
缺点
提交开发人员代码到最终版本库的周期较长，步骤繁琐。
转载本站内容时，请务必注明来自W3xue，违者必究。