git工作流01

• 高效的分布式工作流。配合使用便利的pull request功能，体系的讲解各种工作流的应用。

• 工作流不是一个初级主题。背后的本质问题其实是，有效的项目流程管理和高效的开发协同约定。而不是工具的使用。

• gitFlow工作流是经典模型。处于核心位置，体现了工作流的经验和精髓。随着项目过程的复杂化，你会感受到这个工作流的深思熟虑和威力。

• Forking工作流是分布式协作的。给一个GitHub项目贡献你的提交。Fork就是服务端的克隆。

• 工作流有各式各样的用法。请记住，工作流是作为方案指导而不是条例规范。在展示了各种工作流可能的用法之后，可以从不同的工作流中挑选或糅合出一个满足自己需求的工作流。

• 集中式工作流

• 在熟悉了SVN的基础上，可以快速的迁移到git上来。git在这种模式下有几个优势：每个开发者有自己独立的整个工程的本地拷贝。可以自由提交到本地仓库，先忽略上游的开发，合适的时候再把修改反馈上去。

• 工作方式，以中央仓库作为所有项目修改的单点实体。所以修改都提交到master分支上。先克隆到本地，在自己的本地编辑提交修改。修改是保存到本地的。在一个方便的时间点，push到中央仓库。

• 中央仓库代表了正式的项目。所以提交历史应该被尊重并且是稳定不变的。

• pull --rebase. 解决冲突。继续rebase push。这样，git上的分支就是一条直线。

• 功能分支工作流

• 在开发过程中简单的加上功能分支，用来鼓励开发者之间的协作和简单交流。

• 功能分支背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在master分支上。可以方便多个开发者在各自的功能上开发，而不会弄乱主干代码。保证了master分支上的代码不会出问题。极大有利于集成环境

• 功能开发隔离也让pull request工作流成为可能。pull request工作流能为每个分支发起一个讨论。在分支合并入正式项目之前，给其他开发者有表示赞同的机会。如果在功能开发中有问题卡住了，可以开一个pull request来征求意见。让团队成员之间互相评论工作变得非常方便。

• 功能分支工作流，仍然使用中央仓库。master代表了正式项目的历史。在开始新功能前，先开一个功能分支。分支名有描述性名字。

• master分支和功能分支之间，技术上没有区别。功能分支也可以push到中央仓库上去。可以方便备份本地的提交。

• 一旦某个功能开发完成。不是立即合并到master上，而是push到远程的功能分支，并发起一个pull request请求合并到master上。这让其他开发者有机会去先review代码。

• 除了code review之外，还常常用于讨论代码的常用手段。可以把pull request作为专门某个分支的讨论，这样，在开发过程中就可以进行code review。一个开发者开发功能需要帮助时，要做的就是pull request。相关的人就能看到需要帮助解决的问题。一旦pull request被接受了，接下的流程就和集中式工作流很像了。保持