从svn迁移到git的迷惑行为大赏

915 阅读4分钟

一、首先,我们需要明确,从svn迁移到git是必须的吗?

这样说也许会违反政治正确,但是就我的工作经历而言,在大多数场景下,这个答案是非必须的

git该有的版本控制功能,svn同样具备。问一个小白用户,他甚至会告诉你svn比git更容易上手,况且 tortoise svn 也远比 tortoise git好用。 git独有的分布式仓库的概念,在实际工作中,又很鸡肋。原因如下:

  1. 在实际的产品发版或发测试的过程中,拉取的始终是远程中央仓库的代码,而不会拉取个人本地仓库的代码。无论你在本地编写了多少行代码,都是要始终push到远程中央仓库的才会生效的。
  2. 实际工作中,经常会在公司电脑和住所电脑直接来回切换,这也就意味着你必须把未完成的代码来回在云端同步。如果有工作没完成,想带回家做,而下班前你的代码仅仅commit到了本地仓库却忘记了push到远程仓库。 相信我,在到家打开电脑的一刹那,你会恨不得来一发地爆天星轰在自己脑门上。

二、既然如此,为什么主流的互联网公司都在用git,而不是svn,难道他们全是跟风狗或仅仅觉得分布式仓库这个名词听起来很有逼格?

我认为有以下几个原因 :

  1. 虽然git的分布式仓库的概念带来了一些使用门槛,但是不得不承认,面临极端情况,比如中央仓库被恶意删除,git分布式仓库的这一特性可以瞬间变身成为拯救这场灾难的英雄。因为所有的代码变更记录在每个开发人员电脑上的本地仓库都有一个镜像备份
  2. 就目前而言, git的生态远比svn强大。就像很多编程语言,只论语言特性和性能,已经和java相差无几甚至赶超。但是为啥 Java能在编程语言的江湖里面称霸至今,而看不到能掀翻他的挑战者?就是因为java的生态圈是在太强大了——只有你想不到而没她做不到的类库,让你跪拜的spring 全家桶,最流行的大数据框架Hadoop等等等等。。 同样的,目前流程的代码仓库,基本是都是托管在git上的。很多devops工具,原生支持Git。基于git+gitlab+jenkins,我可以分分钟搭建一个好用到跳脚的代码管理+自动化运维部署平台
  3. git的分支合并和比对功能很强大

三、git 标准的开发流程

  1. 创建一个工程项目。把这个项目的初始版本commit and push 到远程仓库。而这个远程仓库一般基于gitlab搭建,嫌麻烦的话可以直接购买gitlab或gitee企业版
  2. 远程仓库默认把你第一次提交的代码作为master分支。接下来,你还需要创建一个develop分支,代表此分支是开发环境的分支
  3. 团队人员从这个把这个远程仓库的代码clone到本地
  4. 团队成员创建每个人自己分支。命名为tom-dev,jimmiy-dev,lucy-dev。
  5. 每个人只在自己的分支进行代码改动和提交。千万记着:commit只是提交到了本地仓库,push才是将将你commit到本地仓库的改动同步到了远程仓库。一定要记得先commit再push。图省事就用idea里面的commit and push
  6. 进行前后端接口联调时,需要把自己的分支merge到develop分支,然后推送到远程仓库
  7. 开发人员的接口联调成功无误后,将develop分支的代码合并到master分支
  8. 测试通过Jenkins或自建脚本,自动拉取master分支的代码,部署到测试环境进行测试
  9. 测试无误后,即可对外发版

以上操作可通过idea或者vs code 内嵌的git插件来完成。

(顺便推荐一个非常好用的idea插件——ignore。可自动创建.gitingore文件,把你不想要提交的文件给忽略掉)