git版本管理

categories: [计算机通识,git版本管理工具]
thumbnail: /images/fe/gitfx.jpg
toc: true

git版本管理工具复习
资料来源：Learn Git Branching

git仓库初始化

git init

我们初始化完成仓库之后就可以往对应的目录添加文件

假设现在我们编写一个了readme.txt文件，那么我们要使用git管理控制这个文件，还需要将这个文件添加到仓库，而不是仅仅将它放在仓库所在的文件夹

git add readme.txt

注意：git add不仅可以添加单个文件，还可以添加文件夹，这样文件夹中任意文件的变化都可以由git进行监控与管理

踏上征途——git本地仓库操作

循序渐进，了解git主要命令

git commit

在初始化阶段我们创建了本地仓库，当文件发生改动，我们就可以将这个改动提交到本地仓库进行保存

实际上可以这么理解，git仓库保存的是你添加到仓库的所有文件的一个快照，每次进行提交git都会将新快照和旧快照进行对比，找出所有差异并保存为一个提交记录。

多次提交之后，git依然会为我们保存之前所有的提交记录

指令语句：

git commit -m

m：每次提交的额外信息，这个信息是可选的，但是强烈建议写上，因为这标识了每次提交的改动信息，为我们之后的版本管理提供了重要的依据

假设我们现有仓库：

执行命令：

git commit 

git branch

git的分支简单来说就是基于同一个提交历史进行不同的工作，当这些工作完成之后再将他们合并起来。这是团队合作开发的核心理念。

git的分支是非常轻量的，即使一个仓库建立了诸多分支，也不会对内存资源带来大的消耗。

假设现有仓库：

执行：

git branch newImage

这时我们执行：

git commit 

master分支前进，但newImage分支原地不动，因为我们当前实在master分支上进行工作（图中的星号）

当然我们也可以切换到另一个分支进行工作,使用checkout

git checkout newImage
git commit

git merge

当我们的开发者们在不同的分支上完成工作之后，就需要将这些工作进行整合了，这就是分支的合并

当我们使用git merge时会产生一个特殊的提交记录，这个提交记录有两个父节点

假设现有如下仓库：

当前工作在master分支，执行：

git merge bugFix

可以很清楚的看到，使用merge合并分支之后，master分支就拥有了c2上的所有改动。

而对于bugFix分支，同样也可以通过merge，获得c3上的所有改动

git checkout bugFix
git merge master

git rebase

这个指令也是用来合并分支的，听上去和merge功能相同，但是它却和merge有着一定的区别。

之前的merge指令就像将两个分支的河流最终汇合成为一条河流，汇合之后，两条河流汇合之前的部分依然存在。

但是rebase更像是将其中一条河流的水全部取出，倒入另一条河流，之后直接将其填平。显然这样合并之后，被取水的那条河流不复存在。

假设现有仓库：

git rebase master

可以看到bugFix上的修改记录c3被直接复制粘贴到了master分支顶端成为c3(副本)，同时原先的修改记录（图中暗掉的c3）将不复存在，无法再访问到。

git超棒特性——版本移动

分离HEAD

HEAD可以理解为一个指针，它默认总是指向当前分支上的最近一次提交记录，大多数修改提交树的命令都是从分离HEAD开始的

假设现有仓库：

git commit 
git checkout c2

相对引用

我们之前的例子当中“c1”、“c2”等等这些，其实就是我们每次提交的唯一标识符。它在实际的git仓库中是一串哈希值，共40位。

显然我们之前用到哈希值的操作，需要我们每次都要去通过git log获取每一次提交的哈希值。

类似于这样的哈希值：fed2da64c0efc5293610bdd892f82a58e8cbc5d8

不过好消息是，我们不一定要输完整的哈希值，我们可以仅仅输入fed2，这样就可以了

然而即使是这样，如果每一次我们进行版本移动都要哈希值很明显是不方便的，于是就有了相对引用的方法

使用^向上移动一个提交记录，使用~[num]向上移动num个提交记录

假设现有如下仓库：