解析apkphpgit技巧_Git事理入门解析

Git，这个词实在源自英国鄙谚，意思大约是 “混账”。
Linux 为什么会以这样自嘲的名字来命名呢？这个中还有一段儿有趣的历史可以说一说：

Git 的出身：很多人都知道，Linus 在 1991 年创建了开源的 Linux，从此，Linux 系统不断发展，已经成为最大的做事器系统软件了。
Linus 虽然创建了 Linux，但 Linux 的壮大是靠全天下热心的志愿者参与的，这么多人在世界各地为 Linux 编写代码，那 Linux 的代码是如何管理的呢？事实是，在 2002 年以前，天下各地的志愿者把源代码文件通过 diff 的办法发给 Linus，然后由 Linus 本人通过手工办法合并代码！
你大概会想，为什么 Linus 不把 Linux 代码放到版本掌握系统里呢？不是有 CVS、SVN 这些免费的版本掌握系统吗？由于 Linus 武断地反对 CVS 和 SVN，这些集中式的版本掌握系统不但速率慢，而且必须联网才能利用。
有一些商用的版本掌握系统，虽然比 CVS、SVN 好用，但那是付费的，和 Linux 的开源精神不符。
不过，到了 2002 年，Linux 系统已经发展了十年了，代码库之大让 Linus 很难连续通过手工办法管理了，社区的弟兄们也对这种办法表达了强烈不满，于是 Linus 选择了一个商业的版本掌握系统 BitKeeper，BitKeeper 的雇主 BitMover 公司出于人性主义精神，授权 Linux 社区免费利用这个版本掌握系统。
安定联络的大好局势在 2005 年就被冲破了，缘故原由是 Linux 社区牛人聚拢，不免熏染了一些梁山豪杰的江湖习气。
开拓 Samba 的 Andrew 试图破解 BitKeeper 的协议（这么干的实在也不但他一个），被 BitMover 公司创造了（监控事情做得不错！
），于是 BitMover 公司怒了，要收回 Linux 社区的免费利用权。
Linus 可以向 BitMover 公司道个歉，担保往后严格管教弟兄们，嗯，这是不可能的。
实际情形是：Linus 花了两周韶光自己用 C 写了一个分布式版本掌握系统，这便是 Git！
一个月之内，Linux 系统的源码已经由 Git 管理了！
牛是怎么定义的呢？大家可以体会一下。
Git 迅速成为最盛行的分布式版本掌握系统，尤其是 2008 年，GitHub 网站上线了，它为开源项目免费供应 Git 存储，无数开源项目开始迁移至 GitHub，包括 jQuery，PHP，Ruby 等等。
历史便是这么有时，如果不是当年 BitMover 公司威胁 Linux 社区，可能现在我们就没有免费而超级好用的 Git 了。

版本掌握系统

不管是集中式的 CVS、SVN 还是分布式的 Git 工具，实际上都是一种版本掌握系统，我们可以通过他们很方便的管理我们的文件、代码等，我们可以先来畅想一下如果自己来设计这么一个别系，你会怎么设计？

摁，这不禁让我想起了之前写毕业论文的日子，我先在一个开阔的空间创建了一个文件夹用于保存我的各种版本，然后开始了我的 “毕业论文版本管理”，参考下图：

这彷佛暴露了我写毕业论文愉快的经历..但不管怎么样，我在用一个粗粒度版本的制度，在对我的毕业论文进行着管理，摁，我通过一直在原根本上迭代出新的版本的办法，不仅保存了我各个版本的毕业论文，还有这清晰的一个路径，完美？NO！

问题是：

并且可能问题还远不止于此，以是每每想起，就不自觉对 Linux 膜拜了起来。

集中式与分布式的不同

Git 采取与 CSV/SVN 完备不同的处理办法，前者采取分布式，而后面两个都是集中式的版本管理。

先说集中式版本掌握系统，版本库是集中存放在中心做事器的，而干活的时候，用的都是自己的电脑，以是要先从中心做事器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中心做事器。
中心做事器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本掌握系统最大的毛病便是必须联网才能事情，如果在局域网内还好，带宽够大，速率够快，可如果在互联网上，碰着网速慢的话，可能提交一个10M的文件就须要5分钟，这还不得把人给憋去世啊。

那分布式版本掌握系统与集中式版本掌握系统有何不同呢？首先，分布式版本掌握系统根本没有 “中心做事器”，每个人的电脑上都是一个完全的版本库，这样，你事情的时候，就不须要联网了，由于版本库就在你自己的电脑上。
既然每个人电脑上都有一个完全的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件 A，你的同事也在他的电脑上改了文件 A，这时，你们俩之间只需把各自的修正推送给对方，就可以相互看到对方的修正了。

和集中式版本掌握系统比较，分布式版本掌握系统的安全性要高很多，由于每个人电脑里都有完全的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。
而集中式版本掌握系统的中心做事器假如出了问题，所有人都没法干活了。

在实际利用分布式版本掌握系统的时候，实在很少在两人之间的电脑上推送版本库的修正，由于可能你们俩不在一个局域网内，两台电脑相互访问不了，也可能本日你的同事病了，他的电脑压根没有开机。
因此，分布式版本掌握系统常日也有一台充当 “中心做事器” 的电脑，但这个做事器的浸染仅仅是用来方便 “交流” 大家的修正，没有它大家也一样干活，只是交流修正未便利而已。

当然，Git 的强大还远不止此。

Git 初始化

首先，让我们来创建一个空的项目目录，并进入该目录。

$ mkdir git-demo-project$ cd git-demo-project

如果我们打算对该项目进行版本管理，第一件事便是利用 git init 命令，进行初始化。

$ git init

git init 命令只会做一件事，便是在项目的根目录下创建一个 .git 的子目录，用来保存当前项目的一些版本信息，我们可以连续利用 tree -a 命令查看该目录的完全构造，如下：

Git 目录大略解析

config 目录

config 是仓库的配置文件，一个范例的配置文件如下，我们创建的远端，分支都在等信息都在配置文件里有表现；fetch 操作的行为也是在这里配置的：

objects 目录

Git 可以通过一种算法可以得到任意文件的 “指纹”（40 位 16 进制数字），然后通过文件指纹存取数据，存取的数据都位于 objects 目录。

例如我们可以手动创建一个测试文本文件并利用 git add . 命令来不雅观察 .git 文件夹涌现的变革：

$ touch test.txt$ git add .

git add . 命令便是用于把当前新增的变革添加进 Git 本地仓库的，在我们利用后，我们惊奇的创造 .git 目录下的 objects/ 目录下多了一个目录：

我们可以利用 git hash-object test.txt 命令来看看刚才我们创建的 test.txt 的 “文件指纹”：

$ git hash-object test.txte69de29bb2d1d6434b8b29ae775ad8c2e48c5391

这时候我们可以创造，新创建的目录 e6 实在是该文件哈希值的前两位，这实在是 Git 做的一层类似于索引一样的东西，并且默认采取 16 进制的两位数来当索引，是非常得当的。

objects 目录下有 3 种类型的数据：

文件都被存储为 blob 类型的文件，文件夹被存储为 tree 类型的文件，创建的提交节点被存储为 Commit 类型的数据；

一样平常我们系统中的目录(tree)，在 Git 会像下面这样存储：

而 Commit 类型的数据则整合了 tree 和 blob 类型，保存了当前的所有变革，例如我们可以再在刚才的目录下新建一个目录，并添加一些文件试试：

提交一个 Commit 再不雅观察变革：

首先我们可以不雅观察到我们提交了一个 Commit 的时候在第一句话里面返回了一个短的像是哈希值一样的东西：[master (root-commit) 30d51b1] 中 的 30d51b1，对应的我们也可以在 objects 找到刚才 commit 的工具，我们可以利用 git cat-file -p 命令输出一下当前文件的内容：

$ git cat-file -p 30d5tree 5efb9bc29c482e023e40e0a2b3b7e49cec842034author 我没有三颗心脏 <wmyskxz@wmyskxzdeMacBook-Pro.local> 1565742122 +0800committer 我没有三颗心脏 <wmyskxz@wmyskxzdeMacBook-Pro.local> 1565742122 +0800test: 新增测试文件夹和测试文件不雅观察.git文件的变革

我们创造这里面有提交的内容信息、作者信息、提交者信息以及 commit message，当然我们可以进一步看到提交的内容详细有哪些：

$ git cat-file -p 5efb100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test.txt

我们再试着提交一个 commit 来不雅观察变革：

可以不雅观察到这一次的 commit 多了一个 parent 的行，个中的 “指纹” 和上一次的 commit 千篇一律，当我们提交两个 commit 之后我们的 Git 仓库可以简化为下图：

解释：个中由于我们 test 文件夹新增了文件，也便是涌现了变革，以是就被标识成了新的 tree 类型的工具；

refs 目录

refs 目录存储都是引用文件，如本地分支，远端分支，标签等

引用文件的内容都是 40 位长度的 commit

$ cat .git/refs/heads/master9dfabac68470a588a4b4a78742249df46438874a

这就像是一个指针一样，它指向了你的末了一次提交（例如这里就指向了第二次提交的 commit），我们补充上分支信息，现在的 Git 仓库就会像下图所示：

HEAD 目录

HEAD 目录下存储的是当前所在的位置，其内容是分支的名称：

$ cat HEADref: refs/heads/master

我们再补充上 HEAD 的信息，现在的 Git 仓库如下图所示：

Git 中的冲突

您也在上面理解到了，在 Git 等分支是一种十分轻便的存在，仅仅是一个指针罢了，我们在广泛的利用分支中，不可避免的会碰着新创建分支的合并，这时候不论是选择 merge 还是 rebase，都有可能发生冲突，我们先来看一下冲突是如何产生的：

图上的情形，并不是移动分支指针就能够办理问题的，它须要一种合并策略。
首先我们须要明确的是谁与谁的合并，是 2，3 与 4， 5， 6 两条线的合并吗？实在并不是的，真实合并的实在只有 3 和 6，由于每一次的提交都包含了项目完全的快照，即合并只是 tree 与 tree 的合并。

这可能提及来有点绕，我们可以先来想一个大略的算法，用来比较 3 和 6 的不同。
如果我们只是纯挚的比较 3 和 6 的信息，实在并没故意义，由于它们之间并不能确切的表达出当前的冲突状态。
因此我们须要选取它们两个分支的不合点（merge base）作为参考点，进行比较。

首先我们把 1 作为根本，然后把 1、3、6 中所有的文件做一个列表，然后依次遍历这个列表中的文件。
我们现在拿列表中的一个文件进行举例，把在提交在 1、3、6 中的该文件分别称为版本1、版本3、版本6，可能涌现如下几种情形：

1. 版本 1、版本 3、版本 6 的 “指纹” 值都相同：这种情形则解释没有冲突；

2. 版本 3 or 版本 6 至少有一个与版本 1 状态相同（指的是指纹值相同或都不存在）：这种情形可以自动合并，比如版本 1 中存在一个文件，在版本 3 中没有对该文件进行修正，而版本 6 中删除了这个文件，则以版本 6 为准就可以了；

3. 版本 3 or 版本 6 都与版本 1 的状态不同：这种情形繁芜一些，自动合并策略很难生效了，以是须要手动办理；

merge 操作

在办理完冲突后，我们可以将修正的内容提交为一个新的提交，这便是 merge。

可以看到 merge 是一种不修正分支历史提交记录的办法，这也是我们常用的办法。
但是这种办法在某些情形下利用起来不太方便，比如我们创建了一些提交发送给管理者，管理者在合并操作中产生了冲突，还须要去办理冲突，这无疑增加了他人的包袱。

而我们利用 rebase 可以办理这种问题。

rebase 操作

假设我们的分支构造如下：

rebase 会把从 Merge Base 以来的所有提交，以补丁的形式一个一个重新打到目标分支上。
这使得目标分支合并该分支的时候会直接 Fast Forward（可以大略理解为直接后移指针），即不会产生任何冲突。
提交历史是一条线，这对强制症患者可谓是一大福音。

实在 rebase 紧张是在 .git/rebase-merge 下天生了两个文件，分别为 git-rebase-todo 和 done 文件，这两个文件的浸染光看名字就大概能够看得出来。
git-rebase-todo 中存放了 rebase 将要操作的 commit，而 done 存放正操作或已操作完毕的 commit，比如我们这里，git-rebase-todo 存放了 4、5、6 三个提交。

首先 Git 会把 4 这个 commit 放入 done，表示正在操作 4，然后将 4 以补丁的办法打到 3 上，形成了新的 4，这一步是可能产生冲突的，如果有冲突，须要办理冲突之后才能连续操作。

接着按同样的办法把 5、6 都放入 done，末了把指针移动到最新的提交 6 上，就完成了 rebase 的操作。

从刚才的图中，我们就可以看到 rebase 的一个缺陷，那便是修正了分支的历史提交。
如果已经将分支推送到了远程仓库，会导致无法将修正后的分支推送上去，必须利用 -f 参数（force）强行推送。

以是利用 rebase 最好不要在公共分支上进行操作。

Squash and Merge 操作

大略说便是压缩提交，把多次的提交融合到一个 commit 中，这样的好处不言而喻，我们着重来谈论一下实现的技能细节，还是以我们上面最开始的分支情形为例，首先，Git 会创建一个临时分支，指向当前 feature 的最新 commit。

然后按照上面 rebase 的办法，变基到 master 的最新 commit 处。

接着用 rebase 来 squash 之，压缩这些提交为一个提交。

末了以 fast forward 的办法合并到 master 中。

可见此时 master 分支多且只多了一个描述了这次改动的提交，这对付大型工程，保持主分支的简洁易懂有很大的帮助。

通过上面的理解，实在我们已经大致的节制了 Git 中的基本事理，我们的 Commit 就像是一个链表节点一样，不仅有自身的节点信息，还保存着上一个节点的指针，然后我们以 Branch 这样轻量的指针保存着一条又一条的 commit 链条，不过值得把稳的是，objects 目录下的文件是不会自动删除的，除非你手动 GC，不然本地的 objects 目录下就保留着你当前项目完全的变革信息，以是我们常日都会看到 Git 上面的项目常日是没有 .git 目录的，不然仅仅通过 .git 目录理论上就可以还原出你的完全项目！