git:Pull Request工作流

Pull Request 介绍

• Pull Requests是Bitbucket上方便开发者之间协作的功能。 提供了一个用户友好的Web界面，在集成提交的变更到正式项目前可以对变更进行讨论。
• 当要发起一个Pull Request，你所要做的就是请求（Request）另一个开发者（比如项目的维护者） 来pull你仓库中一个分支到他的仓库中。这意味着你要提供4个信息以发起Pull Request： 源仓库、源分支、目的仓库、目的分支。
• Pull Request可以和功能分支工作流、Gitflow工作流或Forking工作流一起使用。 但一个Pull Request要求要么分支不同要么仓库不同，所以不能用于集中式工作流。 在不同的工作流中使用Pull Request会有一些不同；基本流程如下

1. 开发者在本地仓库中新建一个专门的分支开发功能。
2. 开发者push分支修改到公开的Bitbucket仓库中。
3. 开发者通过Bitbucket发起一个Pull Request。
4. 团队的其它成员review code，讨论并修改。
5. 项目维护者合并功能到官方仓库中并关闭Pull Request。

功能分支工作流：

• 功能分支工作流用一个共享的Bitbucket仓库来管理协作，开发者在专门的分支上开发功能。 但不是立即合并到master分支上，而是在合并到主代码库之前开发者应该开一个Pull Request发起功能的讨论。
• 功能分支工作流只有一个公开的仓库，所以Pull Request的目的仓库和源仓库总是同一个。 通常开发者会指定他的功能分支作为源分支，master分支作为目的分支。
• 收到Pull Request后，项目维护者要决定如何做。如果功能没问题，就简单地合并到master分支，关闭Pull Request。 但如果提交的变更有问题，他可以在Pull Request中反馈。之后新加的提交也会评论之后接着显示出来。
• 在功能还没有完全开发完的时候，也可能发起一个Pull Request。 比如开发者在实现某个需求时碰到了麻烦，他可以发一个包含正在进行中工作的Pull Request。 其它的开发者可以在Pull Request提供建议，或者甚至直接添加提交来解决问题。

在Gitflow工作流中使用Pull Request

• Gitflow工作流和功能分支工作流类似，但围绕项目发布定义一个严格的分支模型。 在Gitflow工作流中使用Pull Request让开发者在发布分支或是维护分支上工作时， 可以有个方便的地方对关于发布分支或是维护分支的问题进行交流；
• Gitflow工作流中Pull Request的使用过程和功能分支工作流中完全一致： 当一个功能、发布或是热修复分支需要Review时，开发者简单发起一个Pull Request， 团队的其它成员会通过Bitbucket收到通知。新功能一般合并到develop分支，而发布和热修复则要同时合并到develop分支和master分支上。 Pull Request可能用做所有合并的正式管理。

在Forking工作流中使用Pull Request

• 在Forking工作流中，开发者push完成的功能到他自己的仓库中，而不是共享仓库。 然后，他发起一个Pull Request，让项目维护者知道他的功能已经可以Review了；（在这个工作流，Pull Request的通知功能非常有用， 因为项目维护者不可能知道其它开发者在他们自己的仓库添加了提交。）-
• 由于各个开发有自己的公开仓库，Pull Request的源仓库和目标仓库不是同一个。 源仓库是开发者的公开仓库，源分支是包含了修改的分支。 如果开发者要合并修改到正式代码库中，那么目标仓库是正式仓库，目标分支是master分支。
• Pull Request也可以用于正式项目之外的其它开发者之间的协作。 比如，如果一个开发者和一个团队成员一起开发一个功能，他们可以发起一个Pull Request， 用团队成员的Bitbucket仓库作为目标，而不是正式项目的仓库。 然后使用相同的功能分支作为源和目标分支。
• 2个开发者之间可以在Pull Request中讨论和开发功能。 完成开发后，他们可以发起另一个Pull Request，请求合并功能到正式的master分支。 在Forking工作流中，这样的灵活性让Pull Request成为一个强有力的协作工具。