我的GIT工作流程

我的GIT工作流程

Friendbuy是一家互联网创业公司。产品的源代码是托管在GITHUB上的。在EC2上有三套环境：生产环境，测试环境和持续集成环境。基本上每天都有大量的代码被提交，测试和部署。一年多的磨合下来，逐渐理顺了GIT的使用流程。但是，最开始并不是这样的，所有的开发人员都没有使用过GIT，基本上都是SVN的背景。

最开始的使用方式

只有一个GIT分支，就是MASTER。开发团队直接向MASTER提交新的改动，部署其实就是在生产环境下执行

git pull

开发人员的日常工作也很简单

git pull --rebase
git commit -a -m "xxxx"
git push

基本上是把Git当作SVN来使用。

生产环境不稳定

很快就出现了问题。在一次给客户的演示的过程中，掉链子了。

老板很不高兴，对于生产环境部署的质量产生了怀疑。

于是为了使得生产环境稳定，团队决定牺牲时效性，建立更加正规的流程，添加了测试环境和自动集成环境

每次提交的代码都会被自动集成环境自动进行测试

不定期的会人工部署到测试环境中测试

当测试环境测得差不多的时候才会决定部署到生产环境

另外每次部署到测试环境和产品环境的时候都会打一个标签

git tag -a xxx -m xxx

 

速度就是生命

众所周知，互联网创业公司玩的就是速度。加上了这么一套流程之后，一个feature要发布变得非常冗长。

最要命的是，网站为了尝试不同的风格，还经常全面改版。每次完整的改版都要协调各方面的资源，特别是有一个很长的UI调整过程。

问题是在网站局部改版的情况下，客户的其他特性仍然要响应，产品的线上BUG仍然要FIX。

于是就有了分支。

git branch new-retailer-site master
git checkout new-retailer-site
#change some thing
git commit -a -m "xxx"
git push origin new-retailer-site

分支用完了之后，要合并到master中

git checkout master
git merge new-retailer-site
#fix conflit
git commit -a -m "xxx"
git push

最后就可以把分支删除了

git push origin :new-retailer-site

 

千万不能搞乱master

分支在很短的时间就冲到了两位数。对于分支的管理一开始也并不在意。

直到出了这么一个事情：

开发团队一致决定new-retailer-site已经差不多了，可以“准备”发布了。然后new-retailer-site被合并到了master中。

然后在master上有开发了一些其他特性。

但是new-retailer-site的UI迟迟不能够让人满意。直到有一天开发团队被要求先把master中的“有用”的feature发布，样式改版工作延后发布。

这可难办了，所有的改动已经混杂在同一个分支中了。

最后的解决办法是用

git log

把一条条的改动给找出来，由于比对实在太麻烦了，还写了点代码来干这事

def list_commits(branch):
　　commits = local('git log ' + branch + ' ^master --no-merges --format=format:%s,%H', capture=True)
　　commits = commits.split('\n')
　　for commit in commits:
　　　　print('==> %s <==' % commit.split(',')[0])
　　　　print('https://github.com/friendbuy/apps/commit/%s' % commit.split(',')[1])

然后把找出来的commit，一条条cherry pick出来

git cherry-pick <commit id>

接下来很长一段时间都是搞不清楚，到底是哪个分支是产品部署的分支。

直到某一天，团队决定以后再也不能随便把无关分支合并到master了。

正常的工作流程应该是，选定要候选发布的branch，比如说new-retailer-site

git checkout new-retailer-site
git merge master
# fix conflict
git commit -a -m "merge"
git push

然后在测试环境下

git checkout new-retailer-site
git pull

测试通过了之后，确定可以发布到产品环境了

git checkout master
git merge new-retailer-site
git push

然后把剩余的分支，逐个更新

git checkout feature-branch-1
git merge master
# ...
git checkout feature-branch-2
git merge master
# ...

总结

使用feature branch的方式，可以同时进行很多项特性的开发，并有产品的需要决定什么时候发布哪些特性。比如在圣诞节期间，基本上就没有feature branch被发布，但是开发并不会因此停滞。而且业务的优先级经常调整，经常开发到一半的分支也会被扔掉。

在使用多分支开发的时候要保持一个master分支始终对应“一定会被发布到产品环境的代码”，以master为中心保持一致的合并方向，不然分支之间乱合并就很难管理了。

目前有一个缺陷是持续集成环境只对master进行测试，理想的情况下应该建立一个staging的分支，持续集成环境也要对staging分支进行测试。