当前位置 : 主页 > 编程语言 > 其它开发 >

我的GIT工作流程

来源:互联网 收集:自由互联 发布时间:2022-05-25
我的GIT工作流程 Friendbuy是一家互联网创业公司。产品的源代码是托管在GITHUB上的。在EC2上有三套环境:生产环境,测试环境和持续集成环境。基本上每天都有大量的代码被提交,测试和
我的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分支进行测试。

 





网友评论