git 深入理解

之前一直是对git的基础命令有了解，最近正好有这个时间和需求，将git命令重新理解了下。
git仓库中保留的是你的目录下所有文件的快照。还有提交记录，这个记录很轻量，git会将此次版本与上一次的版本进行对比，将所有的差异打包到一起作为一个提交记录。

先说一些简单的之前模糊的概念。

1. origin

origin：origin可以说是远程仓库的一个指针。 其实就是远程仓库服务器的一个copy。
git remote可以列出当前所在分支对应的每一个远程服务器的简写。

git remote show origin 查看origin对应的远程仓库的详细信息。

当我们clone一个远程仓库到本地的时候，git会默认创建一个标签（或者说是指针）指向你clone的那个远程仓库，这个标签（指针）就是origin。
如果使用 git clone -o newOriginName ，这时你拉取的对应地址的远程仓库指针就是 newOriginName。

除了git clone之外，也可以使用git remote add XXX https://github.com/Martina001来添加一个新的远程Git仓库，并指定XXX为对应的服务器简写名儿。

使用git remote -v就可以看到origin（所有远程仓库指针的）对应的仓库。

我们平时用的 git fetch 没有指定对应的远程仓库指针的，默认就是从origin对应的远程仓库地址拉取最新的内容。所以说如果我们有很多个仓库，最好是分别为其设置一个指针（别名）。

fetch之后要merge。既然origin只是一个指针，所以自己在merge的时候只是将本地仓库和本地的远程仓库merge了。此时的本地的远程仓库指的是上一次fetch到的远程仓库的版本，所以在merge之前要拉取远程仓库最新的版本并解决冲突之后再进行合并。

重命名和删除
git remote rename origin myOrigin 重命名指针
git remote remove origin或者 git remote rm origin//这个命令会删除origin对应的远程仓库相关的所有追踪分支和配置信息

2. git push

众所周知 git push的作用，这里将git push 的几种命令放在一起记录一下。

1. git push origin localBranch：remoteBranch 这是完整操作，就是将当前本地分支推送到远程分支,如果远程分支不存在就新建该远程分支。
2. git push origin localBranch 省略了远程分支的名称，此时默认会将本地分支推送到存在追踪关系的远程分支（一般同名）上，若远程分支不存在则被新建。
3. git push origin ：remoteBranch 省略了本地分支的名称。这可要注意了，这就相当于是将一个空的本地分支推送到了远程分支上，就意味着原来的远程分支会被删掉，相当于git push origin --delete remoteBranch
4. git push origin 省略了本地和远程的分支，只是指定了远程仓库的指针（别名），就会将此时所在的本地分支推至已追踪的远程分支上。
5. git push 就是不指定远程仓库和分支，使用git config中的当前分支的默认远程仓库别名（一般就是remote），将此时所在的本地分支推送至已追踪的远程分支（此命令适用于只有本地分支只有一个远程分支的情况）。git pull 和git fetch也是同样的道理。一般如果在了解当前分支的情况下，大家为了方便挺经常用不指定远程仓库和分支的命令，但是这种模糊的命令在关联了多个仓库、有多个分支的时候，还是比较容易混淆。
   

还有一个 git push -u origin master这种用于当前分支和多个主机（多个远程仓库）存在追踪关系，则可以使用-u参数指定一个默认的远程仓库的别名，这样就可以使用git push，也就是上面第五种命令，默认只推送当前分支。这叫做Simple的方式（一般push.default就是simple。还有一个是matching，这种方式下git push命令会推送所有对应的远程分支的本地分支）。

3. HEAD

HEAD其实就是当前分支的别名。（一般如果你在使用push、pull等命令不指定具体的分支时，就默认使用head指向的本地分支。）
如下图所示，HEAD指向了当前分支。

还有一个命令：
git reset HEAD < file > 将文件恢复到初始状态

4. git reset

很简单，git reset --hard < commitID > 或者git reset --soft < commitID > 用于回退到之前提交的某个版本。hard是全部丢弃，soft是放回到暂存区。
其实 reset的过程就是修改HEAD指向位置（HEAD 向后移动）的过程。
每次回退想要推送至远程，就要git push -f或者是git push --force。

如果现在有一种情况是，提交了A、B、C三次。但是你想要消除掉B提交。那么可以reset --soft A_ID，然后cherrypick C的，然后解决冲突，merge或者rebase，然后push -f，将本地的内容推送至远程。此时本地和远程就都是A、C提交了。

5. git revert

git revert用于消除之前的某次提交的修改，要求执行此命令时工作树必须是干净的。
HEAD其实是向前移动的。
个人总结了一下，revert 和reset其实结果都是为了能回退到某一次的提交，再重新修改。但是reset就意味着被隔离出来的几次commit就没有了。revert是还留有提交历史的。所以一般自己的分支就随意，但是合入master之后，尽量不要用reset。因为是合作开发的，还是不要去动别人的commit。

6. git pull和git fetch

听过有人说过git pull和git fetch的区别就是前者等于后者+git merge。
然后又有一个理论说实际上，git pull改变了当前refs/heads/master（咱默认就看master分支）的commitID和refs/remotes/origin/master中的commitID，但是git fetch再merge是改变了refs/remotes/origin/master中的commitID，并不会改变refs/heads/master中的commitID。
然后我又试验了一下。最新的git已经完善了上述缺点，也就是说 git pull实际上就等于git fetch + git merge

7. 详解.git文件

有图如上，我们可以很明显的看出几个文件各自的含义。

1. logs文件中记录的是对head以及本地、远程分支分别进行的操作。.git/logs/refs文件中有remotes/origin和heads两个文件夹。分别记录了对远程分支和本地分支的操作。
2. .git/refs文件夹下存放的是本地和远程分支所在的commitId。以及tags标签。
   
3. .git/config文件自不用说，记录的是git的一些默认配置。
4. .git/HEAD和.git/ORG_HEAD中分别记录的是当前分支所在的当前commitID以及HEAD起初所在的commitID。

8. git branch

之前熟知的就是 git branch < newBranchName >
新增一个命令：
git branch -f < branchName > < commitRef > 这个命令用来将指定的branch强制指向某一次commit。
关于本地和远程之间的跟踪，两种方式：

1. git branch -u remoteBranch localBranch 其中若是就想指定当前所在分支的远程分支，localBranch可以省略。
2. git checkout -b newBranch remoteBranch 新建并切换到newBranch上，且指定当前本地分支对应跟踪的远程分支。

9. git rebase

关于rebase的使用，详细见我的另一篇文章《git rebase四种常用场景》
这里只对rebase的简单使用进行介绍，仅作个人学习所用。
首先 rebase就是“变基”的意思。
切换到dev分支上，可以使用git rebase master命令来讲dev上的提交合并到master分支上的最后，相当于dev的“基”变为了master。

rebase和merge区别

1. 一是在于提交树（rebase很清晰，merge较为复杂）。
2. 二是在于commit的不同，rebase不会产生新的提交，但是如果有冲突，在解决冲突之后会提示是否要修改master原来的那个最新的commit。而merge（默认，fast-forward模式）会在处理完冲突之后，git add然后git commit，产生一个新的提交节点。
   其实提交树的不同也是由于commit的不同导致的。
   示例：
   master分支：
   自己操作的分支：
   
   （有冲突，解决之后）图1是merge，图2是rebase
   
   
   一般我们要注意，不会公共分支上进行rebase。

10. git merge

git merge默认的参数是git merge --ff ， 即 fast-forward 方式。还有两个分别是 --no-ff以及–squash --no-squash等参数。官方解释如下：

--ff
When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default behavior.

--no-ff
Create a merge commit even when the merge resolves as a fast-forward. This is the default behaviour when merging an annotated (and possibly signed) tag.

--squash
--no-squash
Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit, move the HEAD, or record $GIT_DIR/MERGE_HEAD (to cause the next git commit command to create a merge commit). This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).

With --no-squash perform the merge and commit the result. This option can be used to override --squash.

用图表示他们的区别如下（没有冲突的情况）：

–squash很明显，就是将dev上的提交合并为一个提交之后merge入master并产生一个新的提交。一般用于dev分支上的提交大多琐碎且没有意义的情况。

–no-ff和-ff的区别重点在没有冲突的情况下。前者即使在没有冲突的情况下也依然会在合入master时产生一个新的提交，且保留了dev分支上的提交（如下图1示）。默认-ff，就是fast-forward模式，就是快进，在没有冲突的时候就不会产生新的提交，合并之后dev分支上的提交就不复存在（如下图2示）。


目前看来，如果有冲突的话，两者（–no-ff 和 -ff）没有啥区别。因为都要 在解决冲突之后，git add 然后git commit，so~~

资料来自：https://www.jianshu.com/p/418323ed2b03