GIt常用指令、概念及原理分析，图解rebase、merge指令区别，stash、reset贮藏重置等指令详解，每一条指令都有详细说明，值得收藏！_git rm stash

Git常见指令、概念及原理分析

1. Git原理

1.1 分布式版本控制系统：

客户端不只是提取最新的文件快照，而是将代码仓库完整的镜像一份，相当于一次对代码仓库的完整备份

1.2 直接记录快照，而非差异比较：

基于差异的版本控制：存储每个文件与初始版本的差异

git版本控制：保存变化文件的快照，没有变化的文件只保存之前快照的索引

1.3 近乎所有操作都是本地执行

本地拥有完整的历史记录

1.4 git保证完整性

GIt中所有的数据在存储前都计算校验和，然后以校验和来引用，SHA-1散列（hash，哈希）

1.5 git一般只添加数据

执行的git操作，几乎只往Git数据库中添加数据

1.6 三种状态

已提交（committed）：表示数据已经安全地保存在本地数据库中

已修改（modified）：表示修改了文件，但还没保存到数据库中

已暂存（staged）：表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照里。

1.7 三个阶段：工作区、暂存区、Git目录

工作区：某个版本的项目文件夹，在此修改文件

暂存区：暂存有更改的文件

Git仓库：保存项目的元数据和对象数据库的地方

转换：在工作区修改的文件会被添加至暂存区，暂存区的文件被提交更新后，保存到Git目录，并移动HEAD指针

2. Git基础

2.1 获取Git仓库

远程克隆：git clone url

本地初始化：git init

2.2 文件更新

git add 文件名：文件跟踪/文件暂存

git status：检查当前文件状态

​ --changed not staged for commit：跟踪文件未暂存

​ --to be commited：跟踪且已暂存文件待提交

​ --untracked files：未跟踪文件

git diff：查看未暂存的文件更新记录

git diff --staged：查看已暂存的文件的更新记录

git reset HEAD 文件名：取消文件暂存

git rm 文件名：删除文件

git rm --cached 文件名：删除文件的版本控制

git commit：文件提交

git commit -m ‘注释’

git commit -a ：跳过暂存区

git commit -a -m ‘注释’

git commit --amend ：重新提交（提交之后发现有文件漏掉，执行该命令，将暂存区的文件再次提交，最终只显示一次提交）

​ – 可视化操作：commit右下角Amend

2.3 提交历史

git log

git reflog：显示commit、rebase、commit amend等记录

2.4 撤销操作

取消暂存：git reset HEAD 文件名

取消修改：git checkout – 文件名 取消未暂存的文件修改【危险操作】

取消跟踪：git rm --cached 文件名

取消提交：git reset 索引

重新提交：git commit --amend

2.5 远程仓库的使用

git remote：列出指定的每一个远程服务器的简写

git remote -v：列出远程仓库使用的Git保存的简写与其对应的URL

git remote add 仓库别名 url：添加一个新的远程Git仓库，同时指定一个方便实用的简写

git fetch：抓取远程仓库，但不合并或修改当前的工作

git pull：抓取远程仓库并合并 <=> git fetch + git merge

git push ：推送到远程仓库

2.6 打标签

git tag ：列出标签

git tag -a v1-m ‘附注’：打附注标签，起名并附注

git tag v2：打轻量标签

git show v3：查看标签信息与之对应的提交信息，轻量标签没有额外的标签信息

​ --标签类型：轻量标签、附注标签

git tag -a v4 9fceb02：后期补打标签，指定某一个版本的序列号

git push origin v5：将标签推送到远程服务器上（本地打标签默认不会传送至仓库服务器上）

git push origin --tags： 推送所有本地新加的标签

git tag -d v6：本地删除v6标签，但不会删除该远程标签

git push origin :refs/tags/v6：删除远程标签，实际时将冒号前的空值推送至远程标签名，从而高效的删除它

git push origin --delete v6：更直观的删除远程标签的方式

2.7 Git别名

git config --global alias.ci commit：为commit指令创建别名—ci

3. Git分支–必杀技

3.1 分支简介

暂存操作：

为每一个文件计算校验和将当前版本的文件快照保存到Git仓库中，最终校验和加入到暂存区域等待提交

提交操作：

保存一个提交对象，包含指向暂存内容快照的指针、作者姓名邮箱、提交信息、指向父对象的指针。

首次提交，没有父对象，普通提交操作只有一个父对象（上一次提交对象），多个分支合并产生的提交对象有多个父对象。

计算目录的校验和，然后把校验和以树对象的形式保存在Git仓库中。

分支创建

git brahch 分支名

切换分支

git checkout 分支名：新建分支不切换

git checkout -b newBranchName：新建分支同时切换

HEAD指针指向当前分支

【分支切换会改变工作目录中的文件】

​ --在切换分支时，如果是比较旧的一个分支，你的工作目录会恢复到该分支最后一次提交时的样子。如果Git不能干脆利落的完成这个任务，它将禁止切换分支

删除分支

git branch -d 分支名

查看各个分支当前所指对象

git log --oneline --decorate

对比

与过去大多数版本控制形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。若项目规模较大，该过程十分耗时。

在Git中，任何规模的项目都能在瞬间创建新分支。同时，由于每次都会记录父对象，所以寻找恰当的合并基础也是同样的简单和高效。

3.2 分支的新建与合并

描述：

在master分支切出issue53分支开发需求53，开发途中需要紧急修复一个bug。

步骤：

1. 首先保存issue53的现场

2. 切回master分支

3. 切出新分支hotfix

4. 修改并提交到master后，删除hotfix分支

5. 返回issue53分支继续开发

6. 最后将issue53分支合并到master

可能存在的问题：

1. 第二步，当前处于issue53分支，无法检出到master分支

   【原因】工作目录和暂存区还没有被提交的修改，与即将检出的master分支产生冲突而组织Git切换到master分支

   【解决】切换分支之前，保持一个干净的状态，要么修改已经刚好全部提交，要么将修改内容暂存（stash，即保存现场），要么修补提交（commit amend）

2. 第六步，issue53合并到master时产生冲突

   【原因】两个不同分支中，对同一个文件的同一个部分进行了不同的操作，Git无法干净地合并它们。

   【解决】合并issue53之前，先提交所有代码保持干净状态，然后检出master分支，拉取最新代码，然后检出issue53分支，执行git merge master 解决冲突，然后重新提交，不能commit amend，此时提醒【fatal: You are in the middle of a merge – cannot amend.正在合并不能修改】

   【图解】图5为merge分支，图6为rebase解决冲突，区别在于rebase解决冲突直接变基

新概念：

fast-forward：快进，第四步涉及

​ 【描述】要合并的分支hotfix指向的提交对象中的父对象指针就是要与之合并的master分支，即hotfix当前指向的提交对象是master的直接后继，指针直接向前移动即可。换句话说，当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么Git在合并两者的时候，只会简单的将指针向前推进，因为这种情况下的合并操作没有需要解决的分歧。

​ 【图解】以下图1到图2的过程即为快进

三方合并：第六步涉及

​ 【描述】分叉合并，此时master分支所在提交不是issue53分支所在提交的直接祖先，Git会使用两个分支的末端所指的快照（C4和C5）以及这两个分支的公共祖先（C2），做一个简单的三方合并

​ 【图解】如下图

3.3 分支管理

git branch：分支列表查看

git branch -v :分支列表及最后一次提交

git branch --merged:过滤已经合并到当前分支的分支

git branch --no-merged:过滤没合并到当前分支的分支

3.4 变基

例子1

从master分支切出一个分支experiment，之后master分支有又一次提交，现将experiment的修改整合到master分支上，可以通过合并和变基两种操作

变基：提取b2的修改和补丁，在master最近一次提交的基础上应用，这种操作就叫做变基。将提交到某一分支上的所有修改拼接到另一分支上，如图7

​ 【操作】检出experiment,变基到master，检出master，快进合并experiment

​ git checkout experiment

​ git rebase master

​ git checkout master

​ git merge experiment：快进合并

合并：简单的三方合并，如图8

更有趣的变基例子2

git rebase --onto master server client

【解释】取出client分支，找出它从server分支分歧之后的补丁，然后把这些补丁在master分支上重放一边，让client看起来像是直接基于master修改一样

git checkout master

git merge client：快进合并

变基准则

对于某些提交，别人已经基于这些提交进行开发，不要执行变基

变基vs合并

变基：提交记录简洁

合并：提交记录完整

原则

可执行：尚未推送或分享给别人的本地执行，通过变基操作清理历史

不可执行：不对已经推送至别处的提交执行变基操作

4. 服务器上的Git

5. 分布式Git

6. GitHub

7. Git工具

7.3 贮藏与清理

贮藏

贮藏（stash）会处理工作目录的脏状态——即跟踪文件的修改与暂存的改动——然后将未完成的修改保存到一个栈上，而你可以在任何时候重新应用这些改动（设置在不同的分支上）

相关指令

git stash（git stash push）贮藏修改

git stash list 贮藏列表

git stash apply 应用最近一次贮藏

git stash apply stash@{2} 应用贮藏列表中序号为2的贮藏

git stash drop stash@{2} 删除贮藏

git stash pop 应用贮藏后立马从栈上删除

git stash -u(–include-untracked)贮藏内容包含未跟踪的文件

清理

清除工作目录中未追踪的文件以及空的子目录

清理工作目录有一些常见的原因，比如说为了移出由合并或外部工具生成的东西，或是为了运行一个干净的构建而移除之前构建的残留

指令

git clean -f -d 强制移除工作目录中所有未追踪的文件以及空的子目录

git clean -d -n 做一次移除演习，获知将要移除什么

git clean 移除没有忽略的未跟踪文件

更安全的清理

git stash all

7.7 重置揭秘

git reset ab2a1d6

等价于git reset --mixed ab2a1d6

git reset --soft ab2a1d6

移动HEAD到ab2a1d6 ，相当于撤销上一次的git commit命令，恢复HEAD

git reset --mixed ab2a1d6

在撤销上一次提交的基础上，取消暂存的所有内容，相当于撤销git commit和git add命令，恢复HEAD和暂存区

git reset --hard ab2a1d6

在撤销提交和暂存的基础上，恢复工作目录中的修改，相当于撤销git add和git commit并执行git restore，恢复HEAD、暂存区和工作目录【不安全，慎用】