【Git教程】（二十一）与其他版本控制系统并行使用 — 概述及使用要求，执行过程及其实现，替代解决方案 ~

Git教程 · 与其他版本控制系统并行使用

1️⃣ 概述
2️⃣ 使用要求
3️⃣ 执行过程及其实现
- - 3.1 初始部署版本库
  - 3.2 得到中央版本控制管理中的更新修改
  - 3.3 将修改提交传输到中央本版控制系统

在这里插入图片描述

在许多企业和组织中，会统一管理版本控制工具和相关的流程。其中的个人和小团队无法选择使用一个与众不同的版本控制工具，比如Git 。企业级别的迁移到Git 会需要可行性研究、战略决策、迁移细化等。需要很多时间。

无论如何，都可以在本地开发环境使用Git 技术，再同步开发结果到中央版本库。本地使用Git 有这些优势如下所示。

即使技术无法通信到中央版本库，也可以本地提交。
可以细粒度地划分版本，即使开发中的中间产品。版本管理成为开发过程中的安全保障。
可以专为产品原型和新功能开发工作一一分配对应的本地分支。
Git 更好的支持合并和变基操作。

本章的工作流演示了一个本地 Git 版本库如何和远程中央版本控制服务器一起工作。以实现：

中央版本中的新变化可以被导入本地 Git版本库；
本地提交的修改可以被传输到中央版本库中。

如果目的是互通互联 Subversion 管理的中央版本库，那么 git-svn 命令就可，不需要本章所述的操作过程。

1️⃣ 概述

为了描述 Git 如何和一个中央版本控制一起工作，以CVS 版本控制系统为例。同样的操作步骤可以适用于解决与其他版本控制系统合作。

下图显示了一个CVS 服务器和一个开发者本地版本库。

在这里插入图片描述
开发者有两个本地 Git 版本库。一个是用来同步中央版本，称为同步版本库。另一个称为工作版本库，用来真正执行开发工作。

同步版本库链接到中央版本库 (CVS 目录), 并包含Git 对象(在 .git 目录)。中央版本同步配置在.cvsignore 文件中，可以配置忽略 Git 光管对象。Git 配置通过 gitignore 文件，可以忽略 CVS 元数据信息。

首先，在中央版本中的修改会被记录到同步版本库 (cvs update 命令), 然后在 cvs 分支创建一次提交，再在从工作版本库取得同步版本库中的修改 (fetch 命令), 最后合并 (merge 命令)。

将本地主分支上的修改同步到中央版本的方法是。将开发版本库上的新提交转移到同步版本库 (push 命令)。在同步版本库，将主分支上与 cvs 分支合并，最后将修改保存至中央版本控制服务器 (cvs commit 命令)。

2️⃣ 使用要求

支持乐观锁：中央版本管理系统必须支持乐观锁，例如，文件可以被在不取得锁的情况下修改。
支持忽略文件和文件目录：中央版本管理比较可以排除部分文件和文件目录到管理范围之外。
项目目录的灵活性：开发工具(例如，创建编译工具)必须要不要求项目储存在文件系统固定的一个位置。

3️⃣ 执行过程及其实现

企业和组织可以使用中央版本控制系统，以此同时个人开发者可以在本地使用Git, 并将修改与中央版本控制之间同步。

需要先回答关于该中央本版控制服务的这些问题。

如何从版本控制器中获得初始代码? -cvs checkout 命令
版本控制系统中元数据是如何在何处存储的? -CVS 文件目录
如何在版本管理中忽略某些文件? -.cvsignore 文件
如何在中央版本管理中得到最新的修改? -cvs update 命令
如何在中央版本管理中增加新文件? -cvs add 命令
如何将修改提交到中央版本中? -cvs commit

3.1 初始部署版本库

接下来这些步骤演示了如何初始化创建同步版本库和工作版本库。开始时已有通过 cvs checkout.命令来创建的本地 CVS项目(cvsproject)。

第1步：创建同步版本库
首先，在CVS 文件目录创建一个新的 Git 版本库。
```
> cd cvsproject
> git init
```
第2步：配置.gitignore 文件
所有的文件，除了CVS 的元数据文件，都应该导入同步版本库中。因此 CVC 文件目录应该被列入 git 配置文件.gitignore 中。
```
> echo CVS/ > .gitignore
```
echo 操作创建了一个新的.gitignore 文件，包括 CVS 目录中的内容。
第3步：配置.cvsignore 文件
Git 版本库的管理元数据也不应该被中央版本控制管理，所以应该配置.git 目录和.gitignore 文件在cvs 管理的范围之外。在 CVS 中，将它们加到.cvsignore 文件就可以实现这一目的。
```
> echo .git >>.cvsignore
> echo .gitignore >>.cvsignore
```
如果.cvsignore 文件不存在，将会自动创建一个，新创建的文件必须通过cvs add 命令添加到中央版本管理中。
```
> cvs add .cvsignore
```
之后，可以通过cvs commit 命令将修改提交到CVS 服务器中。
```
> cvs commit
```
第4步：在同步版本库中增加文件
现在所有的准备工作完成，可以将项目文件加入Git 同步版本库中。
```
> git add.
```
注意! 版本控制系统(包括 Git) 都有改编文本文件行末尾(LF 或 CRLF)的习惯。如果合作的其他版本控制系统和 Git有不一样的处理行末尾方式，那可以在 git 中停止对文件末尾的处理，命令是 git config core.autocrlf false。

某些中央版本控制系统，包括 Subversion, 会使用一个全局的校对版本号。在这种情况下，将这个校对版本号加入到 Git 提交的注释中将有所帮助。这个校对版本号可以用来较为容易地记录跟踪，可以由此推断哪些步骤已被导入。不幸CVS 系统没有这样的校对版本号。
```
>git commit -m "Initial import of CVS"
```
第5步：在同步版本库中创建一个cvs 分支
同步版本库的工作将在一个独立的分支cvs上展开。至此，这个分支还没有创建和激活。

> git checkout -b cvs

第6步：创建工作版本库
工作版本库将以同步版本库的克隆形式被创建。当创建克隆时，主分支会被自动设置为活动分支。
```
> cd ..
> git clone cvsproject gitproject
```
至此，准备工作完成。

3.2 得到中央版本控制管理中的更新修改

这一章节将描述如何将中央版本控制中的新修改传输到同步版本库，再传输到工作版本库。

第1步：将修改过的文件传输到同步版本库。
同步版本库的工作区包括与中央版本对比的必要元数据信息。因此必须通过这个工作区来向CVS 服务器获取更新。
```
> cd cvsproject
> cvs update
```
在此 cvs update 命令永不会造成 CVS 冲突。同步版本库的 CVS 分支始终是一个“干净” 的旧版中央版本。之后，通过CVS 分支在同步版本库上做的修改可以通过add 命令添加再提交到Git 中。
```
> git add --all .
```
这里的参数--all 指明添加新的修改过的文件到提交中，同时将删除文件操作也添加到提交中。
```
> git commit -m "Changes from CVS"
```
第2步：提交修改到工作版本库
目前为止，CVS 端发生的修改只存在于同步版本库。因为工作版本库是同步版本库的克隆，其源版本库自动指向同步版本库。通过fetch 命令，工作版本库可以提取CVSs 上的修改。
```
> cd gitproject
> git fetch origin
```
第3步：将修改应用到主分支
在这个阶段，修改只在 cvs 分支上，还没有应用于主分支。这一步需要用到 merge 命令。因此可能会遇到冲突，当同一个文件在本地开发和CVS 同时被修改是。常用Git 工具可以用来清理解决冲突(见图)。
```
 > git merge origin/cvs
```
经过这一步操作。当前中央版本控制中的最新版本已经与本地修改合并，在工作版本库中生效。

3.3 将修改提交传输到中央本版控制系统

这一节将阐述如何将本地工作版本库的修改通过同步版本库传输到中央版本控制系统中。

第1步：获得中央版本控制中最新的版本
在本地修改传输到中央版本控制系统之前，首先要先得到中央的最新版本。要做到这一点只需要依次按上一章节所述步骤操作即可。

通过升级到最近，可以尽可能减小提交修改到中央版本控制时遇到冲突的可能性。另外可以再次测试修改在最新的版本上是否功能完好。
第2步：主分支上的修改传输到同步版本库
在主分支上的本地修改必须先传输到同步版本库，因为同步版本库是克隆“源”,所以一个简单的 push 命令即可完成这一目的。
```
> cd gitproject
> git push
```
第3步：在 cvs 分支上接受修改
新的提交和修改的文件到了同步版本库的主分支。要把他们传输到中央版本控制系统中，需要把这些修改合并到cvs 分支。这不会引起冲突，因为cvs 分支上没有任何修改(见图)。
```
> cd cvsproject
> git merge --no-commit --no-ff master
```
merge 命令中用到的参数有如下两种。
- --no-commit: 因为存在可能与cvs 上的后续修改冲突，这里尝试合并命令不包含最终提交。
- --no-ff: 这一参数指定 Git 不采取快速合并。
第4步：将修改传输到中央版本控制系统
现在本地修改可以开始向中央版本控制系统传输了。根据是否有新增、删除、修改文件，
采取不同的提交命令。例如 cvs commit 命令用于仅包含修改文件时：
```
> cvs commit
```
如果在cvs 提交时遇到冲突，意味着自从上次本地获取 cvs 最新更新后中央版本又有新的修改，这个时候需要重置当前合并尝试。
```
> git reset --hard HEAD
```
然后再次从第一步做起获取中央版本控制系统中最新的更新，与主分支上的修改合并。
直到不再遇到冲突，完成了将本地修改传输到中央版本中，再进行下一步操作。
第5步：从中央版本中获得更新
有些版本控制系统会在提交的过程中或提交之后的第一个更新对文件有所修改。例如，可以通过CVS 系统得到当前版本号或者在文件头(替换关键字)得到文件修改历史。因此，再次证明成功提交之后，有必要再从中央版本取得一次更新。
```
> cvs update
```
第6步：在cvs 分支执行提交操作
这时候应该将CVS 上的更新提交并合并到Git 系统中。在此之前，先将CVS 行的更新用 add 命令添加到提交中。
```
> git add
> git commit -m "Changes from Git recorded"
```
第7步：更新工作版本库的主分支
通过上述步骤，现在同步版本库 cvs 分支有了一个新的提交。为了后续工作，需要将更新传输到工作版本库，再将cvs分支合并到主分支。
```
> cd  gitproject
> git fetch origin
```
接下来做一个合并，这应该是一个快速合并，因为主分支上不应该再有临时更新(上述步骤已将主分支全部更新同步到了cvs 分支)。
```
> git merge origin/cvs
```

经过这些步骤，已经将本地的修改更新到了中央版本控制系统中，并且本地工作版本库版本包含了中央版本当前最新版。如图所示，所有的提交和分支操作流程。

在这里插入图片描述

为什么不选择一个 Git 版本库
这样一套流程在只有一个 Git 版本库时也可以实现。例如开发工作可以在同步版本库中完成。那么只需根据正在只需同步工作还是开发工作在 cvs 分支和主分支之间切换即可。但是，这样会显得很难跟踪记录在何时何地采取如何操作。

会经常发生命令执行错分支的情况，尤其是执行同步操作时候。
另外一个问题就是容易使中央版本库的元数据在开发过程中被不慎删除，例如在重构项目时不慎删除 CVS 文件目录。

⏪ 温习回顾上一篇（点击跳转）：
《【Git教程】（二十）外包长历史记录 — 概述及使用要求，执行过程及其实现，替代解决方案 ~》

⏩ 继续阅读下一篇（点击跳转）：
《》