SCM版本控制梳理——以git为例

0.什么是SCM

首先我们平时用的什么git，svn啥的都属于SCM。SCM（Software Configuration Management，软件配置管理）是一种标识、组织和控制修改的技术。它应用于整个软件生存期。 最原始古老的方法是采用手工管理版本的方式，例如当一个新版本产生时用当时的日期来命名文件夹，然后再复制一下以后的修改在复制的文件夹内进行，这样上一个版本就被保存下来了，周而复始不同的版本不会被覆盖。虽然这种方式可以从某种程度上解决版本的回溯问题，但他存在的缺点是显而易见的：第一点如果保留结果过于频繁，将会导致产生大量的有着重复内容的文件夹和庞大的物理空间占用，管理起来很麻烦；如果保留旧版本的时间间隔太长，可能产生某些有用的老程序无法回溯。第二容易产生版本的混乱，如果是团队开发软件，这种简单的方法更难解决问题的本质了。

几乎所有的SCM都离不开三大基本步骤1.Get Latest Version 2.Check Out 3.修改完后Check In。
以git为例，分别是

1. 从git取数据（git clone）
2. 改动代码
3. 将改动传回git（git push）

1, 3两个步骤涉及到remote server/remote repository/remote branch，2涉及到local repository/local branch。git clone 会根据你指定的remote server/repository/branch，拷贝一个副本到你本地，再git push之前，你对所有文件的改动都是在你自己本地的local repository来做的，你的改动(local branch)和remote branch是独立（并行）的。Gitk显示的就是local repository。

1.建立和github远程仓库之间的可靠连接

一切在本地做好的改动，最终都是需要上传到远程仓库的，所以首先要建立和github远程仓库的可靠连接。有多种方式可以选择，常见的有https协议和ssh协议两种方式。ssh的方式，直接在本地管理密钥，安全也更为方便。打开git终端输入ssh-keygen -t rsa -C “youremail@example.com”。后面的 your_email@youremail.com 改为你在 Github 上注册的邮箱，之后会要求确认路径和输入密码，我们这使用默认的一路回车就行。成功的话会在 ~/ 下生成 .ssh 文件夹，进去，打开 id_rsa.pub，复制里面的 key。
回到 github 上，进入 Account => Settings（账户配置）。

左边选择 SSH and GPG keys，然后点击 New SSH key 按钮,title 设置标题，可以随便填，粘贴在你电脑上生成的 key。

为了验证是否成功，输入以下命令：

$ ssh -T git@github.com
Hi tianqixin! You've successfully authenticated, but GitHub does not provide shell access.

说明我们已成功连上 Github。

2.建立github远程仓库

通过github建立远程仓库的好处不言而喻。但是对于我们独立的开发者，如何从无到有建立一个远程仓库，建完仓库之后如何去添加代码呢？首先在github的网页上，点击(New repository)新建仓库，输入该仓库的名称，选择私有还是公开和其他信息即可。

创建完这个空壳后，需要把项目文件放上去。 这个时候git的远程仓库中一开始没有代码，就需要从本地上传代码到git的远程仓库。 一般github会提示你对新建的仓库进行一下三种操作来充实这个刚刚创建的仓库。

1. 快速设置。这个是系统默认的方式，会给项目自动添加README,LICNESE和gitignore三个文件
2. 通过命令行手动创建。
3. 通过命令行手动导入一个现有的本地仓库到这个远程仓库。

一般而言，用户第一次使用git，连本地的git仓库都没有，所以需要按照github提示的语句建仓并提交远程仓。具体如下：

echo “# mediago” >> README.md
git init
git add README.md
git commit -m “first commit”
git remote add origin git@github.com:yourusername/repositoryname.git
git push -u origin master

每个步骤的详细解释如下：首先是初始化本地仓库，用init命令新建一个git。在本地的git的bash下，切换到需要执行git的目录，然后git init初始化git，就在当前目录下生成了.git文件夹（通常来说是隐藏文件夹），这里面有git管理的一切信息。然后输入

git add .

注意add和.之间有一个空格。这句话的意思是把当前目录下的所有文件添加到git的本地暂存区中。 然后再出入

git commit -m “first commit”

这句话表示确认暂存区的内容，并正式提交本地暂存区的内容到本地仓库。

（这里插上一段，如果输入git commit，不输入-m “”直接回车，会进入vim或者nano界面让你编辑commit文件。当然，有解决方式，具体见如此链接。
为了避免麻烦，还是输入-m吧。另外commit -m和-am是有区别的。-am是直接不需要add就能提交，对于-m,如果改动了文件而没有add，直接commit -m是没用的。参见）

至此，本地仓库建立完成。

git push origin xxx 表示推送到远程仓库
PS:xxx表示远程仓库的分支名，如果在第一次连接远程仓库时将本地与远程仓库的分支关联，后续提交时候可以直接输入 git push origin master 。具体方法如下：先执行

git remote add origin git@github.com:user/yourRepository.git。

这句话相当于为远程仓库创建了一个在本地的别名。这里的origin可能比较难理解，其实把它理解为 git@github.com:user/yourRepository.git 就可以了。
origin就是一个名字，或者一个标签。为什么我这里选择origin，因为如果通过clone区克隆一个托管在Github上代码库时，git为你默认创建的指向这个远程代码库的标签就是origin。

我的版本输入git branch只能查看本地仓库的分支。输入git branch -a或者 git branch -r可以查看当前git下的所有分支。如下图所示：

最后，git push -u origin master。-u这个参数表示，如果你下次需要在这个目录下push，就不需要打origin master，直接git push 就可以了。把commit之后的本地仓库全部push更新到远程仓库中去。当然，也可以不通过命令行的方式。在github网站的页面上，进入自己的仓库，点击uploadfiles按钮也可以上传本地文件。

3.用github开发和维护项目

前面说到， 用git进行开发有三大步骤。

1. 从git取数据（git clone）
2. 改动代码
3. 将改动传回git（git push）

第一步1是本地不存在代码的情况。所以才需要去clone。clone适用的场景是已经在远程仓库存在一个比较成熟的项目了，然后开发者本地没有代码的情况下，才需要clone。clone完成后再本地远程仓库的别名就是origin，这个是默认的。如果远程仓库的代码就是从本地上传的，或者作者很清楚本地仓库的代码就是之前已经从远程仓库clone过来的，那就不要进行第一步git clone，直接进入本地git的目录操作即可。

重点还是在改动代码这一块。通常的操作是改完之后执行git add “文件名”，git commit -m “commit标记”，git pull(通常是git pull origin master)三连操作。add比较好理解，改了哪些文件就add哪些。其实就是把代码放到临时区。commit 是为了告诉 git 我这次提交改了哪些东西，不然你只是改了但是 git 不知道你改了,也就无从判断比较;

重点是pull它是git fetch再git merge的意思。
执行了pull之后，如果本地的这几个 commit 和远程的 commit 有冲突的部分就merge,然后根据提交时间排序再新建一个merge 的 commit 记录 。对于本地 commit 和远程commit 的对比记录,git 是按照文件的行数操作进行对比的,一般情况自动merge就能结局问题。但是如果同时操作了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就需要先把和你冲突的项目成员拉过来问问保留谁的代码,然后在 git add && git commit && git pull 这三连,再次 pull 一次是为了防止再你们协商的时候另一个人给又提交了一版东西,如果真发生了那流程重复一遍,通常没有冲突的时候就直接给你合并了,不会把你的代码给覆盖掉。

不commit，就会出现代码覆盖或者丢失的情况:比如A B两人的代码pull 时候的版本都是1,A在本地提交了2,3并且推送到远程了,B 进行修改的时候没有commit 操作,他先自己写了东西,然后 git pull 这个时候 B 本地版本已经到3了,B 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push 那么在远程版本中就是4,而且 A 的代码被覆盖了,所以说所有人都要一定要先 commit 再 pull！

4.补充

上面提到的git pull只是为了树立整个git的流程，实际上，需要尽量少用git pull。

git pull的问题是它把过程的细节都隐藏了起来，以至于你不用去了解git中各种类型分支的区别和使用方法。当然，多数时候这是没问题的，但一旦代码有问题，你很难找到出错的地方。git的使用文档有如下说明：

将下载（fetch）和合并（merge）放到一个命令里的另外一个弊端是，你的本地工作目录在未经确认的情况下就会被远程分支更新。当然，除非你关闭所有的安全选项，否则git pull在你本地工作目录还不至于造成不可挽回的损失，但很多时候我们宁愿做的慢一些，也不愿意返工重来。

5.常见问题

在执行git pull的时候，报错:There is no tracking information for the current branch。这常常是因为偷懒直接写了git pull而没有加上其他信息。本地分支和远程分支没有建立联系 (使用git branch -vv 可以查看本地分支和远程分支的关联关系) .根据命令行提示只需要执行以下命令即可

git branch –set-upstream-to=origin/远程分支的名字 本地分支的名字

或者勤快一点，每次都加上远程分支的名字git pull origin master

但是问题又来了，输入git pull origin master提示refusing to merge unrelated histories。原因是 git 会发现这两个仓库可能不是同一个，为了防止开发者上传错误，于是就给了这个的提示。如果确认两个仓库都是自己的没问题，我们需要这样写git pull origin master &＃8211;allow-unrelated-histories。

这个方法只解决因为两个仓库有不同的开始点，也就是两个仓库没有共同的 commit 出现的无法提交。如果使用本文的方法还无法提交，需要看一下是不是发生了冲突，解决冲突再提交。解决冲突的方法具体见这篇博文或者廖雪峰的文章。

6.其他指令熟悉

git status –查看当前代码状态，改动，所在分支，是否有代码冲突等
git ls-files –查看当前分支下暂存区文件
git branch -a –查看当前主干下有哪些分支
git checkout –切换分支
git diff –查看分支代码改动
git rm –删除文件