我的GIT工作流程
Friendbuy是一家互联网创业公司。产品的源代码是托管在GITHUB上的。在EC2上有三套环境：生产环境，测试环境和持续集成环境。基本上每天都有大量的代码被提交，测试和部署。一年多的磨合下来，逐渐理顺了GIT的使用流程。但是，最开始并不是这样的，所有的开发人员都没有使用过GIT，基本上都是SVN的背景。最开始的使用方式
只有一个GIT分支，就是MASTER。开发团队直接向MASTER提交新的改动，部署其实就是在生产环境下执行
git pull开发人员的日常工作也很简单
git pull --rebase<br>git commit -a -m "xxxx"<br>git push基本上是把Git当作SVN来使用。
生产环境不稳定
很快就出现了问题。在一次给客户的演示的过程中，掉链子了。
老板很不高兴，对于生产环境部署的质量产生了怀疑。
于是为了使得生产环境稳定，团队决定牺牲时效性，建立更加正规的流程，添加了测试环境和自动集成环境
每次提交的代码都会被自动集成环境自动进行测试
不定期的会人工部署到测试环境中测试
当测试环境测得差不多的时候才会决定部署到生产环境
另外每次部署到测试环境和产品环境的时候都会打一个标签
git tag -a xxx -m xxx
速度就是生命
众所周知，互联网创业公司玩的就是速度。加上了这么一套流程之后，一个feature要发布变得非常冗长。
最要命的是，网站为了尝试不同的风格，还经常全面改版。每次完整的改版都要协调各方面的资源，特别是有一个很长的UI调整过程。
问题是在网站局部改版的情况下，客户的其他特性仍然要响应，产品的线上BUG仍然要FIX。
于是就有了分支。
git branch new-retailer-site master<br>git checkout new-retailer-site<br>#change some thing<br>git commit -a -m "xxx"<br>git push origin new-retailer-site分支用完了之后，要合并到master中
git checkout master<br>git merge new-retailer-site<br>#fix conflit<br>git commit -a -m "xxx"<br>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
页:
[1]