浅谈Git工作流
1、常见的问题：
1) 为什么不能使用SVN的工作流来使用Git?
2) Git的分支？团队多人如何协作？如何解决冲突？如何进行发布？
3) master（发布）、develop（主开发）、hotfix（修复）如何避免不经过验证代码上线？
4) 如何在Github上与他人协作？star-fork-pull request的流程是怎样的？
2、工作流的本质：
有效的项目流程管理和高效的开发协同约定。
Gitflow工作流：经典模型，处于核心位置，体现了工作流的经验和精髓。
Forking工作流：分布式协作，GitHub风格，Fork就是服务端的克隆。
3、Git工作流：
1) 集中式工作流
① Git相比SVN的优势：
a. 每个开发都有整个工程的本地拷贝，各个开发者的开发相对独立，开发者可自由提交到自己的本地仓库，待合适时候再反馈修改到中央仓库。
b. Git提供了强壮的分支与合并模型。
② Git缺省的分支是master，所有修改提交到master分支上，集中式工作流只用到master这一个分支。
③ 工作方式：
a. clone中央仓库；
b. 工作区编辑文件；
c. 暂存文件到暂存区；
d. 提交文件到本地仓库；
e. 本地修改推送到中央仓库。
④ 冲突解决：
若本地仓库与中央仓库有冲突，Git会拒绝push。因此，在push前先从中央仓库fetch最新版本，在rebase到中央仓库上。若不同的开发者对同一文件进行了修改，rebase过程也可能有冲突，此时需要手动解决冲突，Git会暂停rebase过程，解决冲突后再继续rebase过程，若解决冲突遇到问题，可以中止整个rebase操作，重来一次。
⑤ 实例：
a. Git拒绝push：
git push origin masterb. 拉取最新版本并rebase：
git pull --rebase origin masterc. 可能情况1：rebase过程中出现冲突，手动编辑文件解决冲突后暂存到暂存区后继续rebase过程，再将修改推送到中央仓库：
git add
git rebase –continue
git push origin master d. 可能情况2：解决冲突出现问题，中止整个rebase过程，回到git pull --rebase origin master之前的状态：
git rebase --abort2) 功能分支工作流
① 功能分支工作流以集中式工作流为基础，不同的是它为各个功能分配一个专门的分支来开发，可以在把新功能集成到正式项目前，用Pull Requests的方式讨论变更。
② 工作方式：
功能分支工作流仍使用中央仓库，仍使用master代表正式项目，但不是直接提交修改到本地master分支，而是在开发之前为新功能创建一个新分支，注意为新分支起一个语义化的名字。
在中央仓库上存多个功能分支不会有任何问题，功能分支可以且应该push到中央仓库中，以便和其它开发者分享新的变更。
③ Pull Request：
某个开发完成一个功能后，不是立即合并到master，而是push到中央仓库的功能分支上并发起一个Pull Request请求去合并修改到master。 这使得，合并修改到master前，其它的开发者能Review变更。
一旦Pull Request被接受了，发布功能要做的就和集中式工作流就很像了。 首先，确定本地的master分支和上游的master分支是同步的。然后合并功能分支到本地master分支并push已经更新的本地master分支到中央仓库。
Bitbucket或Stash等仓库管理产品支持Pull Requests。
④ 实例：
a. 在开发新功能前创建一个新的分支Feature-4677：
git checkout -b Feature-4677 masterb. 开发完毕后暂存并提交到本地仓库，再推送给中央仓库。
git add
git commit –m "注释"
git push -u origin FeatureF-4677 -u选项设置本地分支跟踪远程分支，设置好跟踪的分支后，就可以直接使用git push命令，不用指定本地分支和远程分支的参数。
c. 在Bitbucket或Stash等仓库管理产品中发起Pull Request请求合并修改到master，Code review的过程中可以迭代add、commit、push的流程，直到Pull Request被接受。
d. 合并修改到master：
git checkout master
git pull
git pull origin Feature-4766
git push首先切换到master分支并拉取最新的master分支，然后执行git pull origin Feature-4677合并Feature-4677分支到最新的 master分支（这一步也可以使用git merge Feature-4677命令，但git pull origin命令可以保证总是最新的新功能分支），最后将更新的master分支推送到origin。
3) GitFlow工作流
Gitflow工作流定义了一个围绕项目发布的严格分支模型，虽比功能分支工作流复杂，但通过为功能开发、发布准备和维护分配独立的分支，提供了用于一个健壮的用于管理大型项目的框架。
① 工作方式：
Gitflow工作流仍使用中央仓库。和其它工作流一样，开发者在本地开发并push到中央仓库中。
② 历史分支：
Gitflow工作流使用2个分支来记录项目的历史：master分支存储正式发布的历史，而develop分支作为功能的集成分支。
③ 功能分支：
每个新功能有一个自己的分支，但功能分支不是从master分支上拉出的，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。新功能分支不直接与master分支交互。
④ 发布分支：
临近发布，从develop分支上拉出一个发布分支，用于发布，所以新功能不能再加到这个分支上，这个分支只应该做Bug修复、文档生成和其它发布任务。发布完成后，发布分支合并到master分支并分配一个版本号打好Tag。注意，发布分支所做的修改要合并回develop分支。
发布分支使得可以在完善当前发布版本的同时，可以继续开发下一个版本的功能。
发布分支命名：release-* 或 release/*
⑤ 维护分支/热修复分支：
维护分支/热修复分支用于快速给产品发布版本（production releases）打补丁，是唯一可以直接从master分支fork出来的分支。 修复完成后，合并修改到master分支和develop分支，master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支，可以在不打断其它工作的情况下处理问题。可以把维护分支理解成一个直接在master分支上处理的临时发布。
⑥ 实例：
a. 创建develop分支，并推送到中央仓库上：
git branch develop
git push -u origin developb. clone中央仓库，从develop分支拉出一个跟踪分支：
git clone <中央仓库地址>
git checkout -b develop origin/developc. 从develop分支拉出一个新的功能分支：
git checkout -b Feature-4766 developd. 新功能开发完毕后暂存并提交到本地仓库：
git add
git commit –m "注释" e. 合并功能分支的修改到develop分支，删除功能分支：
git pull origin develop
git checkout develop
git merge Feature-4766
git push
git branch -d Feature-4766f. 从develop分支拉出一个发布分支：
git checkout -b release-0.1 developg. 合并发布分支的修改到master分支和develop分支上，删除发布分支：
git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1h. 只要有合并到master分支，就为master打好Tag以方便跟踪：
git tag -a 0.1 -m "release-0.1" master
git push --tagsi. 若发现bug，则从master分支拉出维护分支：
git checkout -b issue-#001 masterj. 修复bug后，合并维护分支的修改到master分支和develop分支上，删除维护分支：
git checkout master
git merge issue-#001
git push
git checkout develop
git merge issue-#001
git push
git branch -d issue-#0014) Forking工作流
Forking工作流是分布式工作流。
Forking工作流不是使用单个中央仓库，而是让每个开发者都有一个自己的服务端仓库，也就是说，每个开发者都有2个Git仓库而不是1个：一个是本地私有的，另一个是公开的。
Forking工作流的优势：贡献的代码可以被集成，通过Pull Request的代码可以被集成到正式仓库中。
每个开发者都能push到自己的服务端仓库，但只有项目维护者才能push到正式仓库。
① 工作方式：
Forking工作流有一个公开的正式仓库存储在服务器，但一个新的开发者想在项目上开发时，不是直接从正式仓库克隆，而是fork项目在服务器上创建一个拷贝。
在创建了拷贝之后，开发者可以克隆仓库到本地机器上，作为私有的开发环境。
要推送本地修改时，push是推送到自己的公开仓库中，而不是正式仓库中。 然后给正式仓库发起一个Pull Request，告知项目维护者已有更新，且可以集成。通过后，项目维护者pull更新到自己的本地仓库中，合并修改到自己本地的master分支，然后push到正式仓库中。
② 实例：
a. 项目维护者初始化正式仓库（应该是裸仓库）：
ssh <用户名>@<地址>
git init –bare <正式仓库地址>b. 开发者fork正式仓库：
c. 开发者克隆fork出来的仓库：
git clone <自己的服务端仓库地址>Forking工作流需要2个远程别名，一个指向正式仓库，另一个指向开发者自己的仓库。常见的约定是使用origin作为自己的仓库的别名（在git clone时自动创建），upstream作为正式仓库的别名。
需要自己用命令创建upstream别名：
git remote add upstream https://<仓库地址>注意，如果upstream仓库需要认证，需要提供用户, 这时在克隆和pull正式仓库时，需要提供用户的密码：
git remote add upstream https://<用户名>@<仓库地址>d. 开发者开发自己的功能：
新建分支，编辑文件、暂存文件并提交：
git checkout –b Feature-4766
git add <文件>
git commit –m "注释"e. 开发者发布自己的功能：
push到自己的仓库：
git push origin Feature-4766向项目维护者发起Pull Request请求
f. 项目维护者集成开发者的功能：
当项目维护者收到pull request，要做的是决定是否集成它到正式代码库中。有二种方式来做：
方式1：直接在pull request中查看代码；
注意，项目维护者的origin是指向自己的公开仓库的，即是项目的正式仓库。
方式2：pull代码到自己的本地仓库，再手动合并到master分支，最后push到正式仓库。
git fetch <待集成的仓库地址>
git checkout master
git merge Feature-4766
git push origin masterg. 开发者和正式仓库同步：
git pull upstream master