银行项目从 SVN 迁移到 Git

一、迁移流程

本人目前做某银行互联网支付平台项目。 自入职加入这个项目开始就一直使用svn进行代码版本控制，开发，测试，生产共用一个仓库，仅一个分支。 一开始有需求就在base版本进行改动，修改完成直接提交，或者在测试环境替换class文件。 修改生产问题，也是相当的小心，担心出现问题，由于新旧代码可能不一样，总是被逼反编译后使用compare进行比较后才能确认有无问题。

当然svn也有版本管理的概念，我也曾尝试；trunk、tags、branches分文件夹管理。 如下图：

其原理是copy一份（虽然服务端也是增量改动），但是客户端一个项目10M, 10个项目10个版本则10 10 10，这是我不能忍的。而且使用繁琐，一个工程会有好多的workspaces。

一个偶然的机会，公司总部的某个项目在gitlab下，正好需要落地到项目地，于是我向公司申请，把我们项目组所有项目迁移到了gitlab 某个group中, 如图：

同时每个项目我又参考了gitflow初始化为master分支，又切出了develop分支，testing分支。贴参考的图：

对于各个分支 我的理解为：

• 【master】：与生产版本对应并基于【master】打tag.

• 【hotfix/fix_telno】：热修复版本，基于【master】切出来的， 解决生产小问题，紧急上线后。并合并到【master,develop】.

• 【develop】 ：开发分支，永远是不稳定的版本，所有开发周期完成待上线测试的特性分支都在该版本中。 【feature/netsunion】：基于【develop】分支切出来的特性分支。

• 【release/1.2.1】：测试完成后的beta版本，用作回归测试，待发布上线。

• 【testing】：用于特性分支开发中的测试。所有特性分支需测试都merge到该分支。

• 比如一个新需求的开发是对接网联接口，我会按照如下进行操作：

1. 基于【develop】checkout -b feature/netsunion，并推送到远端;

2. 基于【feature/netsunion】这个分支进行开发，如果需要在测试机器测试的话就合并到【testing】分支，进行打版测试，当完成开发并确定为下次上线内容后将合并到【develop】，并删除【feature/netsunion】分支。否则一直保持【feature/netsunion】存在，直到确定了上线日期。

3. 等所有feature完成开发并合并到【develop】分支后，基于【develop】切出【release/1.2.1】版本，基于【release/1.2.1 】进行回归测试。

4. 回归完成就进行上线工作准备，完成上线后合并到【master】并打标签【V1.2.1】；删除【release/1.2.1】；

5. 结束

其实我是不主张用testing分支的，我理想中的是特性分支开发完成后就在测试环境进行验证，但事与愿违，无奈行方无法提供更多台测试机，再者多个特性分支需要整合一起统一测试等等原因，无奈新建该分支。 如果过分依赖该分支很容易出现生产问题测试环境不复现的情况，比如出现冲突解决不一致的情况等。所以每个版本必须通过release进行验证后在进行上线操作。

通过切换到git解决了我们开发的痛点：

1. 生产版本的源代码管理。

   由原始的本地备份改为分支管理，避免过分依赖于某个备份人，当他机器挂掉或者不在场再或者备份的与生产不一致的尴尬；

2. 解决多个需求的并行开发，使代码没有那么多判断逻辑。

   以前properties中各种开关，当上线这个功能就打开等等，通过feature分支需要哪个功能合并就好了，代码简洁了许多；

3. 使IDE的 一个workspace支持多个分支的开发。

   checkout 命令后，IDE 刷新即可。

4. 通过部署 工具 或自写脚本实现自动化部署，以前测试环境中都是本地编译好class后直接放到测试环境中，多个服务器需要重复上传，费事费力。

   现在只需提交到对应的分支或者合并到testing分支，通过工具选择分支进行打版部署即可。

二、常用工具：

我们是通过命令行 + 图形工具结合使用：

• 一般新建分支什么的使用【Git Bash】像合并解决冲突；

• 查看历史记录等使用【Git Extensions】 + 【Beyond Compare 4 】 ；

对于git命令 相信各位大神比我更熟悉。 基础语法命令链接

Q&A

Q:svn和git有这么大区别？git的好处是分布式，可以先本地提交；

A:但是svn 对于分支管理确实不方便。多个版本并行开发，本地会存在多个副本。还是那句话；没有最好的工具，只有合适的工具。好处就是本地可以有个版本库；

Q:clearcase 我还以为CC只在主机平台用呢，还在用VSS做文档服务器？

A:经典 + 元老级

Q:怎么找到丢失的 commit？

A:丢掉的commit ，是还没有提交本地？，文件被还原了吗？ 

Q1:提交到本地 没有远端push。

A2:那就没有丢掉嘛 记录都还在。

Q:你们功能特性分支是怎么切的呢？

A:上线后合并到主分支，开发新功能切个分支出来，恩恩，明白了。你们是基于master切出特性分支。我是严格参照gitflow，基于的是dev分支。那样的话如果有ABC三个特性分支，而且全部需要进行测试，下一个版本仅仅上线AB功能。

补充

• 个人感觉，git和svn适用于不同的场景，git可能更适用于运营项目；

• release统一是master，发布测试版本合并到dev，测试通过合并到master，其他开发分支从master拉。实际接触的几个项目，用git基本是因为放弃了配置管理，感觉从配管的角度上看，svn有利于保持基线完整。

• CC是个不错的管理工具。

• 敏捷的目标不是图快，也不是裁剪，对设计和编码要求很高，对配管要求更高，国内就是这样，老板大腿一拍搞敏捷就开完，没真正领略敏捷内涵，敏捷还是老外玩得溜，敏捷说白了是牺牲资源，加快速度，适应市场。

• git flow 中 release是基于的dev，如下：