SVN 与 Git 的主要区别

Git 与 SVN 都是版本控制系统，版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一，最主要的功能就是追踪文件的变更。

描述

  • SVN 是集中式管理的版本控制器，而 Git 是分布式管理的版本控制器，这是两者之间最核心的区别。
  • SVN 只有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
  • Git 每一个终端都是一个仓库，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来，每一次的提取操作，实际上都是一次对代码仓库的完整备份。
  • 相对来说分布式管理系统功能更强大一些，但同样的上手难度也就高一些，当然分布式代码版本管理系统并不一定适合所有团队，比如中小团队可能更关心的只是成本更低，简单易用，那么SVN等这类集中式版本管理工具还是更为适合，但是不管团队最终选用什么代码版本管理工具，只要适合自己的团队的开发流程和工作方式，并且代码管理顺畅就可以了。

详细对比

差异SVNGit
系统特点1. 集中式版本控制系统，文档管理很方便。 2. 企业内部并行集中开发 3. windows系统上开发推荐使用 4. 克隆一个拥有将近一万个提交commit，五个分支，每个分支有大约1500个文件，用时将近一个小时1. 分布式系统，代码管理很方便。 2. 开源项目开发。 3. Mac、Linux系统上开发推荐使用。 4. 克隆一个拥有将近一万个提交commit、五个分支、每个分支有大约1500个文件，用时1分钟。
灵活性1. 搭载SVN的服务器如果出现故障，就无法与之交互。 2. 所有的SVN操作都需要中央仓库交互，例如拉分支，看日志等。1. 可以单机操作，Git服务器故障也可以在本地Git仓库工作。 2. 除了push和pull或fetch操作，其他都可以在本地操作。 3. 根据自己开发任务任意在本地创建分支。 4. 日志都是在本地查看，效率较高。
安全性较差，定期备份，并且是整个SVN都得备份。较高，每个开发者的本地就是一套完整版本库，记录着版本库的所有信息。
分支方面1. 拉分支更像是copy一个路径。 2. 可针对任何子目录进行branch。 3. 拉分支的时间较慢，因为拉分支相当于copy。 4.创建完分支后，影响全部成员，每个人都会拥有这个分支。 5.多分支并行开发较重，工作较多而且繁琐。1. 我可以在Git的任意一个提交点commit point开启分支。 2. 拉分支时间较快，因为拉分支只是创建文件的指针和HEAD。 3. 自己本地创建的分支不会影响其他人。 4. 比较适合多分支并行开发。 5. Git checkout hash切回之前的版本，无需版本回退。 6. 强大的cherry-pick。
工作流程1. 每次更改文件之前都得update操作，有的时候修改过程中这个文件有更新，commit不会成功。 2. 有冲突，会打断提交动作，冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。1. 开始工作前进行fetch操作，完成开发工作后push操作，有冲突解决冲突。 2. Git的提交过程不会被打断，有冲突会标记冲突文件。 3. Gitflow经典流程。
内容管理SVN对中文支持好，操作简单。对程序的源代码管理方便，代码库占用的空间少，易于分支化管理。
学习成本使用起来更方便，SVN对中文支持好，操作简单。更在乎效率而不是易用性，成本较高，有很多独有的命令如rebase、远程仓库交互的命令等等。
权限管理SVN的权限管理相当严格，可以按组、个人针对某个子目录的权限控制，每个目录下都会有个.SVN的隐藏文件。Git没有严格的权限管理控制，只有账号角色划分。
管理平台有功能非常完善的插件。除功能插件外，还有Gitlab、Gerrit、Github等。

工具

SourceTree: Windows / Mac

GitFlow 工作流常用操作

主要分支

  1. master
    主分支，产品的功能全部实现后，最终在 master 分支对外发布
  2. develop
    开发分支，基于 master 分支克隆，产品的编码工作在此分支进行
  3. release
    测试分支，基于 delevop 分支克隆，产品编码工作完成后，发布到本分支测试，测试过程中发现的小 bug 直接在本分支进行修复，修复完成后合并到 develop 分支。本分支属于临时分支，目的实现后可删除分支
  4. hotfix
    Bug 修复分支，基于 master 分支或发布的里程碑 Tag 克隆，主要用于修复对外发布的分支，收到客户的 Bug 反馈后，在此分支进行修复，修复完毕后分别合并到 develop 分支和 master 分支。本分支属于临时分支，目的实现后可删除分支
  5. feature
    功能特征分支，基于 develop 分支克隆，主要用于多人协助开发场景或探索性功能验证场景，功能开发完毕后合并到 develop 分支。feature 分支可创建多个，属于临时分支，目的实现后可删除分支

新功能开发工作流程

  1. 切换到本地仓库工作区
cd /home/timerhunter/workspace
  1. 拉取远端仓库更新到本地仓库
git clone https://xxxx@localhost:8443/r/valve/V5‐Lora.git
  1. 从 master 创建 develop 分支
/* 切换到 master 分支 */
git checkout master
/* 基于 master 分支克隆 develop 分支，并在克隆完毕后直接跳转到 develop 分支 */
git checkout ‐b develop
/* 推送 develop 分支到远程仓库 */
git push origin develop
  1. 开发过程中提交代码
/* 提交修改到缓冲区 */
git add .
/* 提交修改到本地仓库 */
/* 如果是修复的 BUG，应该在修改说明的最开始添加 Bug#ID，多个 Bug 用逗号分隔，例如 Bug#002,003 */
/* 如果是完成了一个指派的任务，应该在修改说明的最开始添加 Task#TaskID,例如 Task#165 */
git commit ‐m "Bug#123 修改说明"
/* 每完成一个功能点可以对代码进行打包 */
git tag ‐m "简要说明增加/修复/删除了什么功能" v0.0.0.170718
  1. 推送到远端仓库
/* 执行代码拉取操作，防止代码冲突 */
git pull
/* 解决代码冲突后，推送代码到远程仓库 */
git push origin develop
  1. 发布到测试分支
git checkout develop
git checkout ‐b release
git push origin release
  1. 提交 Bug 并修复
    • 从远端拉取代码
/* 克隆仓库 */
git clone https://admin@192.168.1.88:8443/r/admin/test.git
/* 查看远程仓库分支情况：克隆仓库时只能克隆 master 分支，因此需要拉取指定分支，我们使用 git branch ‐r 查看远程分支情况 */
git branch ‐r
  origin/HEAD‐>origin/master
  origin/dev
  origin/master
  origin/release
/* 拉取测试分支 */
git checkout ‐b release origin/release

- 修复流程同开发过程
- 在 git commit 时的修复说明中添加 Bug#BugId 关键字
- 推送到远端分支

8. 测试完成后合并代码到 develop 分支

/* 切换到 develop 分支 */
git checkout develop
/* 执行合并操作,将 release 分支代码合并到 develop 分支 */
git merge release
/* 如果合并报错，则解决冲突，冲突解决后继续再次执行合并 */
  1. 开发与测试结束后，将 develop 合并到 master 分支
git checkout master
git merge develop
  1. 阶段开发完毕，打里程碑 Tag 包
/* 创建里程碑 Tag */
git tag ‐m "Task#003 v1.0.0 首版发布" v1.0.0.170718
/* 推送里程碑 Tag 到远程仓库 */
git push origin v1.0.0.170718

发布后产品的 Bug 修复工作流

  1. 获取 Bug 产品的版本号
  2. 查找里程碑 Tag
  3. 从里程碑 Tag 创建 hotfix 分支
/* git checkout ‐b [创建的分支名称] [里程碑 Tag 名称] */
git checkout ‐b hotfix -v1.0.0.170718 v1.0.0.170718
  1. 修复后检查修改过的地方
git diff
  1. 修复后将 hotfix 合并到 develop 与 master 分支
/* 合并到 develop */
git checkout develop
git merge hotfix ‐v1.0.0.170718
/* 提交到远程仓库 develop 分支 */
git push origin develop
/* 合并到 master：如果随下一个版本再发布，可不用合并至 master 分支*/
git checkout master
git merge develop
/* 提交到远程仓库 master 分支 */
git push origin master
  1. 创建新的里程碑 Tag
git tag ‐m "Bug#002 修复某某 Bug" v1.0.1.170719
/* 推送到远程仓库 */
git push origin v1.0.1.170719
  1. 删除 hotfix 分支
/* 删除本地分支‐git branch ‐d [本地分支名] */
git branch ‐d hotfix ‐v1.0.0.170718
/* 删除远程分支‐git push origin :[远程分支名] */
git push origin :hotfix ‐v1.0.0.170718

日常开发中的常用操作

  1. 撤销
    • 提交后发现有未一起提交的文件
/* 正常提交 */
git commit ‐m "发布 v1.0"
/* 发现丢了修改记录，重新添加 */
git add CHANGELOG.md
/* 重新提交,仍以 "发布 v1.0 的名义提交"，最终只有一个提交 */
git commit ‐‐amend

- 撤销上一次提交，但保留暂存区与当前修改

/* 正常提交 */
git commit ‐m "发布 v1.0"
/* 将会撤销 “发布 v1.0” 的提交，但是保留暂存区和当前目录中文件的修改 */
git reset ‐‐soft HEAD~

- 撤销上一次提交与暂存区修改，但保留当前修改

/* 正常提交 */
git commit ‐m "发布 v1.0"
/* 将会撤销 “发布 v1.0” 的提交与暂存区修改，但保留当前修改 */
git reset ‐‐mixed HEAD~

- 撤销上一次提交并丢弃所有修改

/* 正常提交 */
git commit ‐m "发布 v1.0"
/* 将会撤销 “发布 v1.0” 的提交并丢弃所有修改 */
git reset ‐‐hard HEAD~