05 November 2015
  • 作者: 王德水
  • 出处:http://deshui.wang
  • 版权:转载需经作者同意,请保留此内容且附上原文链接

上一篇 敏捷实践系列(四):代码管理流程 给大家详细的讲解了一下Git flow, 本周我们就把一个客户的所有项目实施了Git flow, 如果说你详细看了那篇文章,那么你就能了解为何要进行Git flow 以及如何对一个新项目按Git flow的流程操作, 但是当我们整理已有的项目时,我们发现了以下几个问题需要一些方法处理。

错乱的分支名如何解决

问题

我们遇到的一个项目,一开始生产环境用的是master分支,突然客户提出他们有一个客户有特殊需求,让打一个分支出来,团队成员就打出了一个master-quickfix 分支,但是后来这个分支上功能越来越多,慢慢的团队成员就把这个分支当做master分支用了,此时develop和 master-quickfix 分支也早已分道扬镳。然后所有的客户又需要相同的功能,这样如果想合并会master将是非常难的,因为冲突太大。 经过沟通和核实,我们发现现在的master-quickfix其实承担了master的角色,所以我们要让master-quickfix当做master.

方案

方案一 用master-quickfix 代码覆盖master

git checkout master-quickfix

merge master - ignoring master's changes
git merge -s ours master

git checkout master

# finally merge all our stuff to new master - actually it replaces the master with master-quickfix
git merge master-quickfix

# now master-quickfix can be deleted
git push origin: master-quickfix

然后我们就看到master上代码已经和原来master-quickfix上一样了,但是这个方法有一个问题就是 master-quickfix上的提交日志没有了,如果你不在乎提交日志那么就可以使用这个方法。

方案二 改分支名

git branch -m master new_master         # Rename branch locally    
git push origin :master                 # Delete the old branch    
git push --set-upstream origin new_master   # Push the new branch, set local branch to track the new remote


git branch -m master-quickfix master         # Rename branch locally    
git push origin : master-quickfix                 # Delete the old branch    
git push --set-upstream origin master   # Push the new branch, set local branch to track the new remote

使用这个方法,就可以看到master-quickfix上的分支的提交记录,过程当中会删除旧的远程master分支,以及master-quickfix分支 ,所以需要你确认要删除的分支有备份及没有问题,危险系数5星, 我在做这个操作的时候向别人确认了多次。我操作的时候手都抖呀!

不同的客户不同的分支问题

问题

原来有一个项目,项目有不同的客户,导致不同的客户的代码在不同的分支上,这导致代码难以管理,功能散乱在各个分支,时间久了,开发人员都不知道每个分支上有哪些功能。

解决方案

针对这个问题,我们的想法是不同客户使用同一套代码库,还是使用Git flow, 因为不同的客户需要不同的功能,这其实就是一个SaaS系统,所以我们把系统改为SaaS系统,代码用同一套,不同的客户使用什么功能使用SaaS管理端来配置。 这样做有很多好处,比如:给A客户做的功能很容易再卖给B客户,同时很容易给不同的客户做个性化的配置,例如界面样式等等。 当然,这个需要你的强大的沟通能力,因为改为SaaS需要时间哪,时间就是金钱嘛!

如果你的客户不同意,或者你需要项目遵守一些”特殊规则或者某个国家特殊政策”,导致整套系统非常不同, 那么我的建议是你重新建一个代码库给这个特殊客户,而不要用分支来区分。

总结

由于我们团队的敏捷程度还可以,所以推行Git flow的流程除了以上几个技术上的问题以外,其它的都很顺利。 如果你想实行Git flow,那么再次提醒务必完全理解这个流程再开始。请阅读:敏捷实践系列(四):代码管理流程



blog comments powered by Disqus

关于作者

姓名: 王德水

Shinetech 1st Branch Founder & Manager

微博: 敏捷的水

邮箱: wangdeshui@outlook.com

熟悉: C#, ASP.NET, Restful, WCF, WPF, Azure, Xamarin, DDD, JavaScript, Angular,Node.js, Mongodb, React, Ruby, Objective-C, Swift, HTML, CSS

  • 10年以上软件行业从业经历
  • 10年欧美软件服务
  • 2年制造业ERP
  • 2年旅游景区信息化系统

擅长敏捷开发、团队建设和管理、分公司管理和经营

熟悉敏捷、.Net开发、软件测试、TDD等

热爱爬山、跑步、 足球、乒乓球

喜欢与有梦想、有激情的人交朋友

招聘职位