前面介绍了一种最基本的团队工作模型所有人都工作在master上写完了的commit可以通过push来发送到中央仓库并且可以使用pull来获取到别人的最新commits。这种工作模型解决了团队合作最基本的问题多人并行开发和版本管理。事实上这也是早期的 VCS——中央式 VCS 的工作模型。但这种工作模型也有它的限制使用这种工作模型时每个人的代码在被大家看到的时候就是它进入正式的生产库的时候。所有人的工作都会被直接push到master这导致每个人的代码在正式启用前无法被别人看到严格来讲是有办法的别人可以直接从你的电脑上pullGit 的「分布式」不是说说的。但——这种做法超级不方便这样就让代码在正式启用前的讨论和 review审阅非常不方便。现在的商业团队开发项目多是采用「边开发边发布、边开发边更新、边开发边修复」的持续开发策略所以代码分享的不便会极大地影响团队的开发效率。接下来要介绍的是目前最流行的团队开发的工作流Feature Branching。简介这种工作流的核心内容可以总结为两点任何新的功能feature或 bug 修复全都新建一个branch来写branch写完后合并到master然后删掉这个branch。这就是工作流最基本的模型。从上面的动图来看这种工作流似乎没什么特别之处。但实质上Feature Branching 这种工作流为团队开发时两个关键的问题——代码分享和一人多任务——提供了解决方案。1. 代码分享假设你在一个叫做「掘金」的团队工作现在你要开发一个叫做「掘金小册」的功能呵呵于是你创建了一个新的branch叫做books然后开始在books上进行开发工作。git checkout -b books在十几个commits 过后「掘金小册」的基本功能开发完毕你就把代码push到中央仓库例如 GitHub去然后告诉同事「嘿小册的基本功能写完了分支名是books谁有空的话帮我 review 一下吧。」git push origin books然后你的同事明明正好有空他就从中央仓库拉下来了你的代码开始读# 明明的电脑 git pull git chekcout books读完以后明明对你说说嗯我看完了我觉得不错可以合并到master于是你就把books合并到了master上去git checkout master git pull # merge 之前 pull 一下让 master 更新到和远程仓库同步 git merge books紧接着你把合并后的结果push到了中央仓库并删掉了books这个branchgit push git branch -d books git push origin -d books # 用 -d 参数把远程仓库的 branch 也删了如果同事有意见上面讲的是明明对你的代码没有意见而假如他在你的代码里看到了问题例如他跑来对你说「嘿你的代码缩进为什么用的是 TAB快改成空格不然砍死你哦。」这时你就可以把你的缩进改成空格然后做一个新的提交再push上去然后通知他「我改完啦」明明pull下来你的新提交看了看「嗯这下可以合并了。」于是你依照上面的那一套操作把代码合并进master并push了上去然后删掉了books。瞧代码在同事竖大拇指之前都不会正式发布到master挺方便的吧Pull Request事实上上面讲的这个流程还可以利用 Pull Request 来进一步简化。Pull Request 并不是 Git 的内容而是一些 Git 仓库服务提供方例如 GitHub所提供的一种便捷功能它可以让团队的成员方便地讨论一个branch并在讨论结束后一键合并这个branch到master。同样是把写好的branch给同事看使用 Pull Request 的话你可以这样做把branchpush到中央仓库在中央仓库处创建一个 Pull Request。以 GitHub 为例然后你的同事就可以在 GitHub 上看到你创建的 Pull Request 了。他们可以在 GitHub 的这个页面查看你的commits也可以给你评论表示赞同或提意见你接下来也可以根据他们的意见把新的commitspush上来这也页面会随着你新的push而展示出最新的commits。在讨论结束以后你们一致认为这个branch可以合并了你只需要点一下页面中那个绿色的 Merge pull request 按钮GitHub 就会自动地在中央仓库帮你把branch合并到master了然后你只要在本地pull一下把最新的内容拉到你的电脑上这件事情就算完成了。另外GitHub 还设计了一个贴心的 Delete branch 按钮方便你在合并之后一键删除branch。2. 一人多任务除了代码分享的便捷基于 Feature Branch 的工作流对于一人多任务的工作需求也提供了很好的支持。安安心心做事不被打扰做完一件再做下一件自然是很美好的事但现实往往不能这样。对于程序员来说一种很常见的情况是你正在认真写着代码忽然同事过来跟你说「内个……你这个功能先放一放吧我们最新讨论出要做另一个更重要的功能你来做一下吧。」其实虽然这种情况确实有点烦但如果你是在独立的branch上做事切换任务是很简单的。你只要稍微把目前未提交的代码简单收尾一下然后做一个带有「未完成」标记的提交例如在提交信息里标上「TODO」然后回到master去创建一个新的branch就好了。git checkout master git checkout -b new_feature上面这两行代码有更简单的操作方式不过为了小册内容的简洁性我就不引入更多的内容了有兴趣的话可以自己搜索一下。如果有一天需要回来继续做这个branch你只要用checkout切回来就可以继续了。小结这一节介绍了 Feature Branching 这种工作流。它的概念很简单每个新功能都新建一个branch来写写完以后把代码分享给同事看写的过程中也可以分享给同事讨论。另外借助 GitHub 等服务提供方的 Pull Request 功能可以让代码分享变得更加方便分支确定可以合并后把分支合并到master并删除分支。这种工作流由于功能强大而且概念和使用方式都很简单所以很受欢迎。再加上 GitHub 等平台提供了 Pull Request 的支持目前这种工作流是商业项目开发中最为流行的工作流。
前面介绍了一种最基本的团队工作模型所有人都工作在master上写完了的commit可以通过push来发送到中央仓库并且可以使用pull来获取到别人的最新commits。这种工作模型解决了团队合作最基本的问题多人并行开发和版本管理。事实上这也是早期的 VCS——中央式 VCS 的工作模型。但这种工作模型也有它的限制使用这种工作模型时每个人的代码在被大家看到的时候就是它进入正式的生产库的时候。所有人的工作都会被直接push到master这导致每个人的代码在正式启用前无法被别人看到严格来讲是有办法的别人可以直接从你的电脑上pullGit 的「分布式」不是说说的。但——这种做法超级不方便这样就让代码在正式启用前的讨论和 review审阅非常不方便。现在的商业团队开发项目多是采用「边开发边发布、边开发边更新、边开发边修复」的持续开发策略所以代码分享的不便会极大地影响团队的开发效率。接下来要介绍的是目前最流行的团队开发的工作流Feature Branching。简介这种工作流的核心内容可以总结为两点任何新的功能feature或 bug 修复全都新建一个branch来写branch写完后合并到master然后删掉这个branch。这就是工作流最基本的模型。从上面的动图来看这种工作流似乎没什么特别之处。但实质上Feature Branching 这种工作流为团队开发时两个关键的问题——代码分享和一人多任务——提供了解决方案。1. 代码分享假设你在一个叫做「掘金」的团队工作现在你要开发一个叫做「掘金小册」的功能呵呵于是你创建了一个新的branch叫做books然后开始在books上进行开发工作。git checkout -b books在十几个commits 过后「掘金小册」的基本功能开发完毕你就把代码push到中央仓库例如 GitHub去然后告诉同事「嘿小册的基本功能写完了分支名是books谁有空的话帮我 review 一下吧。」git push origin books然后你的同事明明正好有空他就从中央仓库拉下来了你的代码开始读# 明明的电脑 git pull git chekcout books读完以后明明对你说说嗯我看完了我觉得不错可以合并到master于是你就把books合并到了master上去git checkout master git pull # merge 之前 pull 一下让 master 更新到和远程仓库同步 git merge books紧接着你把合并后的结果push到了中央仓库并删掉了books这个branchgit push git branch -d books git push origin -d books # 用 -d 参数把远程仓库的 branch 也删了如果同事有意见上面讲的是明明对你的代码没有意见而假如他在你的代码里看到了问题例如他跑来对你说「嘿你的代码缩进为什么用的是 TAB快改成空格不然砍死你哦。」这时你就可以把你的缩进改成空格然后做一个新的提交再push上去然后通知他「我改完啦」明明pull下来你的新提交看了看「嗯这下可以合并了。」于是你依照上面的那一套操作把代码合并进master并push了上去然后删掉了books。瞧代码在同事竖大拇指之前都不会正式发布到master挺方便的吧Pull Request事实上上面讲的这个流程还可以利用 Pull Request 来进一步简化。Pull Request 并不是 Git 的内容而是一些 Git 仓库服务提供方例如 GitHub所提供的一种便捷功能它可以让团队的成员方便地讨论一个branch并在讨论结束后一键合并这个branch到master。同样是把写好的branch给同事看使用 Pull Request 的话你可以这样做把branchpush到中央仓库在中央仓库处创建一个 Pull Request。以 GitHub 为例然后你的同事就可以在 GitHub 上看到你创建的 Pull Request 了。他们可以在 GitHub 的这个页面查看你的commits也可以给你评论表示赞同或提意见你接下来也可以根据他们的意见把新的commitspush上来这也页面会随着你新的push而展示出最新的commits。在讨论结束以后你们一致认为这个branch可以合并了你只需要点一下页面中那个绿色的 Merge pull request 按钮GitHub 就会自动地在中央仓库帮你把branch合并到master了然后你只要在本地pull一下把最新的内容拉到你的电脑上这件事情就算完成了。另外GitHub 还设计了一个贴心的 Delete branch 按钮方便你在合并之后一键删除branch。2. 一人多任务除了代码分享的便捷基于 Feature Branch 的工作流对于一人多任务的工作需求也提供了很好的支持。安安心心做事不被打扰做完一件再做下一件自然是很美好的事但现实往往不能这样。对于程序员来说一种很常见的情况是你正在认真写着代码忽然同事过来跟你说「内个……你这个功能先放一放吧我们最新讨论出要做另一个更重要的功能你来做一下吧。」其实虽然这种情况确实有点烦但如果你是在独立的branch上做事切换任务是很简单的。你只要稍微把目前未提交的代码简单收尾一下然后做一个带有「未完成」标记的提交例如在提交信息里标上「TODO」然后回到master去创建一个新的branch就好了。git checkout master git checkout -b new_feature上面这两行代码有更简单的操作方式不过为了小册内容的简洁性我就不引入更多的内容了有兴趣的话可以自己搜索一下。如果有一天需要回来继续做这个branch你只要用checkout切回来就可以继续了。小结这一节介绍了 Feature Branching 这种工作流。它的概念很简单每个新功能都新建一个branch来写写完以后把代码分享给同事看写的过程中也可以分享给同事讨论。另外借助 GitHub 等服务提供方的 Pull Request 功能可以让代码分享变得更加方便分支确定可以合并后把分支合并到master并删除分支。这种工作流由于功能强大而且概念和使用方式都很简单所以很受欢迎。再加上 GitHub 等平台提供了 Pull Request 的支持目前这种工作流是商业项目开发中最为流行的工作流。
