我的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>　　

　　接下来很长一段时间都是搞不清楚，到底是哪个分支是产品部署的分支。
　　直到某一天，团队决定以后再也不能随便把无关分支合并到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分支进行测试。