结构

• 工作区：电脑目录中能看到的文件
• 暂存区：使用git add *操作提交文件的位置，一般位于.git\index，这个文件里面存储了当前位于暂存区的所有文件的校验和
• 版本库：隐藏目录.git
• 忽略文件：.gitignore文件，可以将git提交时需要忽略的文件添加到这里面，如日志等文件，这个文件中可以使用一些匹配规则来批量匹配

简单来说，工作区写完内容之后，使用git add命令提交内容到暂存区，暂存区内容存储在.git\index里面，可以使用git ls-files --stage命令查看内容，里面会给出暂存区中每一个文件的校验和，可以使用git cat-file -p checksum来查看指定的checksum所对应文件的内容

基本操作

help

• 可以使用git help --web order在网页端查看order命令的具体命令格式

提交

• 首先git add *可以将当前目录下所有文件移入暂存区，git reset *将当前目录下所有不在暂存区的文件移出暂存区，当执行git add命令的时候实际上是把当前提交到暂存区的所有文件生成一个快照，并计算文件的SHA-1哈希值
• 当文件进入暂存区之后，可以使用git commit 相关命令将暂存区文件提交至版本库，这时，git将会创建一个包含当前暂存区快照的提交对象，并将其保存到git的对象数据库中，这个提交对象包含了作者、提交时间、提交信息等元数据，以及指向前一个提交的指针。然后我们可以使用git push相关命令提交到远程仓库
• 如果想添加远程仓库地址，使用git remote add origin [url]，如果需要更改远程仓库地址，使用git remote set-url [url]

提交例子如下，每次提交会在原来的节点后面新增一个节点，形成一条链

a - b - c - d - e

分支

• 但是我们的git记录不会总只有一条链路，因为一个工程往往是有很多人协同开发的，一般地，我们会有一个master分支，这表示主分支，也就是当前的最新版本；除此之外，我们会有很多其他的开发分支、测试分支、bugfix分支等等，例如dev分支，develop分支，hotfix分支等
• git有HEAD指针的概念，这个指针指向的是git提交记录中的某个节点，它指向的节点就是当前目录下的文件状态
• 如下图所示

a - b - c - d - e (master)\ f - g - h (feature)

上图中，b节点是c和f节点的父节点，也就是说，如果我们的feature开发完了，需要合并到master分支上，需要执行rebase或者merge命令。在此图中，feature工作目录下的HEAD指针指向的是h节点

• 使用git merge或者git rebase命令可以将其他分支的代码合并到指定分支，这两种合并方法有本质上的区别

git merge和git rebase对比

1. 如下图所示

a - b - c - d - e (master)\f - g - h (feature)

• 现在我们想把feature合并到master，如果使用git merge，得到的会是下图

a - b - c - d - e - i (master)\           /f - g - h     (feature)

• 如果你有一些开发经验的话，你经常会看到在提交MR的时候，会有一条git记录，里面的描述是Merge request…，这其实就是上面的i节点，也就是把两条分支的最后一个节点合并起来，并保存了这两个节点的提交记录的所有信息。不过这里面还有一些合并细节，比如--ff，--no-ff，--squash等，默认情况下使用的是normal merge，或者说递归合并，会将两个分支的更改合并到一个新的提交中，如果存在冲突，需要解决冲突
• 在merge的时候，git会尝试使用三路合并的方法进行，如上图，e和h合并的时候，会提取出e和h的最近公共祖先，也就是b节点，观察e和h相对于b节点的变化，如果都有变化且变化都不同则需要手动进行冲突的处理，这里的变化指的是存在两节点都对某个文件的某行进行了处理且处理方法不同

2. 那么如果使用git rebase命令进行分支合并，注意它的合并是根据提交记录的时间来进行的，假设按照字母顺序表示提交的时间，也就是说，a先于b提交，如下图所示

a - b - c - d - e (master)\ f - g - h (feature)

• 那么当对e和h进行rebase操作的时候，结果会是下面这样

a - b - c - d - e 			 (master)\ f - g - h (feature)

• 可以看到，最终的提交记录是一条线，这是比较乐观的情况，因为e节点的提交时间刚好在feature的f节点的提交时间之前，那么如果是下面这种提交记录的话，执行rebase会如何呢

a - b - e - f - h (master)\ c - d - g (feature)

• 结果应该是下图

a - b - e - f - h         (master)\c - d - g         (feature)

• 那么这个时候一旦feature向master上合并就会出现问题了，因为feature如果想合并到master，需要调整master节点之间的先后关系，那么这种情况下，就会把master分支的e，f，h节点合并到feature并以feature的形式提交到master上，这也就是git提交记录里面可能有who创建并由who提交这种记录出现的原因

拉取

• git clone相关命令可以将远程仓库代码拉到本地
• git fetch和git pull命令可以把远程仓库的最新提交和分支信息拉到本地，但是fetch不会自动合并，而是用户之后再根据需要手动合并，而git pull命令会自动进行合并，实际上，git pull包含了fetch和merge两个过程
• 如果你想创建本地分支并绑定到远程分支，需要执行命令git checkout -b 本地分支名x origin/远程分支名x