git命令背后原理学习

最近做银联项目，多人开发，需求比较杂，有的需求先开发的却后上，有的相反，之前是用svn管理的，对于分支管理这块不太好用，故而转向git，使用git分支管理来做，下面记录git的学习，

一：概念

• 工作区：就是你在电脑里能看到的目录。随着分支的切换，里面的文件会发生相应的改变。
• 暂存区：一般存放在 ".git目录下" 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
• 版本库：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。和svn不同，svn的版本库在服务器，git的在本地，所以git在没有网络的情况下也可以commit。

二：安装

到https://gitforwindows.org/下载exe文件直接一路下去就可以了

安装完之后，可以通过，右键菜单“Git Bash Here”打开命令窗口，来执行git的命令，例如git commit等；

三：配置

如果用 --global 选项，所有的项目都会默认使用这里配置的用户信息。

若使用 --system 选项，所有的用户都会默认使用这里配置的用户信息。

1.配置用户名和电子邮件，标识个人信息

$ git config --global user.name "guoyang"
$ git config --global user.email gouyang83@163.com@163.com

2.列出所有的配置

$ git config -l
...
user.email=gouyang83@163.com
user.name=guoyang
...

其他的配置不太常用，遇到时可以自行百度

四：本地操作

可以这样理解，基本所有的命令的作用都是操作提交记录树

1.git init

把当前执行命令的目录，创建为git仓库，完全是本地化，.git隐藏目录保存所有元数据

$ mkdir gy
$ cd gy
$ git init
Initialized empty Git repository in C:/Users/Service01/Desktop/test/gy/.git/
$ ls -alrt
total 4
drwxr-xr-x 1 Service01 197121 0 Mar 30 15:00 ../
drwxr-xr-x 1 Service01 197121 0 Mar 30 15:00 ./
drwxr-xr-x 1 Service01 197121 0 Mar 30 15:00 .git/

2.git add 

把工作区的内容提交到暂存区

3.git commit

把暂存区的内容提交到版本库，并记录提交记录。

Git 仓库中的提交记录保存的是你的目录下所有文件的快照，就像是把整个目录复制，然后再粘贴一样，但比复制粘贴优雅许多！

Git 希望提交记录尽可能地轻量，因此在你每次进行提交时，它并不会盲目地复制整个目录。条件允许的情况下，它会将当前版本与仓库中的上一个版本进行对比，并把所有的差异打包到一起作为一个提交记录。

Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有父节点的原因 —— 我们会在图示中用箭头来表示这种关系。对于项目组的成员来说，维护提交历史对大家都有好处。

关于提交记录太深入的东西咱们就不再继续探讨了，现在你可以把提交记录看作是项目的快照。提交记录非常轻量，可以快速地在这些提交记录之间切换！C0,C1,C2是提交记录，master是默认分支名称，*代表HEAD位置（后面细说）

git commit

4.git branch

Git 的分支非常轻量。它们只是简单地指向某个提交纪录 —— 仅此而已。所以许多 Git 爱好者传颂：

早建分支！多用分支！

这是因为即使创建再多分的支也不会造成储存或内存上的开销，并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。

在将分支和提交记录结合起来后，我们会看到两者如何协作。现在只要记住使用分支其实就相当于在说：“我想基于这个提交以及它所有的父提交进行新的工作。

新建分支git branch newImage

再来个提交git commit

切换到newImage分支，并提交

git checkout newImage;git commit

5.git merge

在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。”

git merge bugFix

咱们再把 master 分支合并到 bugFix

git checkout bugFix;git merge master

因为 master 继承自 bugFix，Git 什么都不用做，只是简单地把 bugFix 移动到 master 所指向的那个提交记录。

6.git rebase

第二种合并分支的方法是 git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

git rebase master

现在我们切换到了 master 上。把它 rebase 到 bugFix分支上

git rebase bugFix

由于 bugFix 继承自 master，所以 Git 只是简单的把 master 分支的引用向前移动了一下而已。

7.在提交树上移动

HEAD:当前操作位置，一个仓库只有一个

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见。

分离的HEAD：HEAD不再指向分支名

8.相对引用

通过指定提交记录哈希值的方式在 Git 中移动不太方便。在实际应用时，并没有像本程序中这么漂亮的可视化提交树供你参考，所以你就不得不用 git log 来查查看提交记录的哈希值。

并且哈希值在真实的 Git 世界中也会更长（译者注：基于 SHA-1，共 40 位）。例如前一关的介绍中的提交记录的哈希值可能是 fed2da64c0efc5293610bdd892f82a58e8cbc5d8。舌头都快打结了吧...

比较令人欣慰的是，Git 对哈希的处理很智能。你只需要提供能够唯一标识提交记录的前几个字符即可。因此我可以仅输入fed2 而不是上面的一长串字符。

正如我前面所说，通过哈希值指定提交记录很不方便，所以 Git 引入了相对引用。这个就很厉害了!

使用相对引用的话，你就可以从一个易于记忆的地方（比如 bugFix 分支或 HEAD）开始计算。

相对引用非常给力，这里我介绍两个简单的用法：

• 使用 ^ 向上移动 1 个提交记录
• 使用 ~<num> 向上移动多个提交记录，如 ~3

使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:

git branch -f master HEAD~3

上面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交

9.撤销变更

git reset

git revert

10.整理提交记录

1）git cherry-pick

2）git rebase交互式

11.git tag

和分支的区别，分支随着commit会变动，tag永远执行某一个提交，可以和分支一样被引用

五：远程操作

远程仓库只是本地仓库的一个copy，包括提交记录

1.git clone

你可能注意到的第一个事就是在我们的本地仓库多了一个名为 o/master 的分支, 这种类型的分支就叫远程分支。由于远程分支的特性导致其拥有一些特殊属性。

远程分支反映了远程仓库(在你上次和它通信时)的状态。这会有助于你理解本地的工作与公共工作的差别 —— 这是你与别人分享工作成果前至关重要的一步.

远程分支有一个特别的属性，在你检出时自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。

为什么有 o/？

你可能想问这些远程分支的前面的 o/ 是什么意思呢？好吧, 远程分支有一个命名规范 —— 它们的格式是:

• <remote name>/<branch name>

因此，如果你看到一个名为 o/master 的分支，那么这个分支就叫 master，远程仓库的名称就是 o。

大多数的开发人员会将它们主要的远程仓库命名为 origin，并不是 o。这是因为当你用 git clone 某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin 了

不过 origin 对于我们的 UI 来说太长了，因此不得不使用简写 o :) 但是要记住, 当你使用真正的 Git 时, 你的远程仓库默认为 origin!

说了这么多，让我们看看实例。

2.git fetch

git fetch 完成了仅有的但是很重要的两步:

• 从远程仓库下载本地仓库中缺失的提交记录
• 更新远程分支指针(如 o/master)

git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。

git fetch 并不会改变你本地仓库的状态。它不会更新你的 master 分支，也不会修改你磁盘上的文件。

2.git pull

git pull = git fetch + git merge o/master

3.git push

git push 负责将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。一旦 git push 完成, 你的朋友们就可以从这个远程仓库下载你分享的成果了！

你可以将 git push 想象成发布你成果的命令。它有许多应用技巧，稍后我们会了解到，但是咱们还是先从基础的开始吧……

注意 —— git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本，但是在教程中我们使用的是 upstream。 这没什么太大的影响，但是在你的项目中进行推送之前，最好检查一下这个配置。

偏离的工作

现在我们已经知道了如何从其它地方 pull 提交记录，以及如何 push 我们自己的变更。看起来似乎没什么难度，但是为何还会让人们如此困惑呢？

困难来自于远程库提交历史的偏离。如果在你pull之后，有人向远程分支提交了新的记录，那么你直接push会失败，失败是因为，你的提交不是基于最新的远程提交开发的，此时需要先把远程的提交更新到本地，然后merge或rebase，再push

 

之前已经说过git pull = git fetch + git merge

类似的：git pull --rebase = git getch + git rebase

rebase后提交记录比较清晰，merge反应是真实发生的情况，看个人喜好使用

六：idea中使用

1.git clone

添加忽略的文件（仅仅本地使用，不需要提交到git），如果配置后，commit时还能看到这些文件，可以重启下工程

2.git add

3.git commit

4.git push

5.git pull

6.git branch

切换分支

7.git merge

8.git log

参考网站

https://www.runoob.com/git/git-tutorial.html

https://learngitbranching.js.org/