Git 的工作区域和流程
要想弄懂 Git 是怎么对我们的代码进行管理的，那首当其冲的是了解 Git 的工作区域是如何构成的。因为，只有彻底弄懂了 Git 工作区域的构成，你才可以在适当的区域使用合适的命令。如下图所示，此图包含了 Git 的4个工作区和一些常见的操作。
Workspace：工作区，就是平时进行开发改动的地方，是当前看到最新的内容，在开发的过程也就是对工作区的操作
Index：暂存区，当执行 git add 的命令后，工作区的文件就会被移入暂存区，暂存区标记了当前工作区中那些内容是被 Git 管理的，当完成某个需求或者功能后需要提交代码，第一步就是通过 git add 先提交到暂存区。
Repository：本地仓库，位于自己的电脑上，通过 git commit 提交暂存区的内容，会进入本地仓库。
Remote：远程仓库，用来托管代码的服务器，远程仓库的内容能够被分布在多个地点的处于协作关系的本地仓库修改，本地仓库修改完代码后通过 git push 命令同步代码到远程仓库。
一般来说，Git 的工作流程分为以下几步
1.在工作区开发，添加，修改文件。
2.将修改后的文件放入暂存区。
3.将暂存区域的文件提交到本地仓库。
4.将本地仓库的修改推送到远程仓库。
Git 基本操作
git add
添加文件到暂存区
# 添加某个文件到暂存区，后面可以跟多个文件，以空格区分
git add xxx
# 添加当前更改的所有文件到暂存区。
git add .
git commit
# 提交暂存的更改，会新开编辑器进行编辑
git commit
# 提交暂存的更改，并记录下备注
git commit -m "you message"
# 等同于 git add . && git commit -m
git commit -am
# 对最近一次的提交的信息进行修改,此操作会修改commit的hash值
git commit --amend
git pull
# 从远程仓库拉取代码并合并到本地，可简写为 git pull 等同于 git fetch && git merge
git pull <远程主机名> <远程分支名>:<本地分支名>
# 使用rebase的模式进行合并
git pull --rebase <远程主机名> <远程分支名>:<本地分支名>
git fetch
与 git pull 不同的是 git fetch 操作仅仅只会拉取远程的更改，不会自动进行 merge 操作。对你当前的代码没有影响
# 获取远程仓库特定分支的更新
git fetch <远程主机名> <分支名>
# 获取远程仓库所有分支的更新
git fetch --all
git branch
# 新建本地分支，但不切换
git branch <branch-name>
# 查看本地分支
git branch
# 查看远程分支
git branch -r
# 查看本地和远程分支
git branch -a
# 删除本地分支
git branch -D <branch-nane>
# 重新命名分支
git branch -m <old-branch-name> <new-branch-name>
git stash
# 备份当前的工作区的内容，从最近的一次提交中读取相关内容
git stash
# 自定义命名暂存文件的名称
git stash save "message"
# 打印当前的Git栈信息
git stash list
# 取出指定版本号
git stash apply stash@{x}
# 清空Git栈
git stash clear
# 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容
git stash pop
# 删除指定编号的stash
git stash drop stash@{x}
git reset
# 不删除工作空间改动代码，撤销commit，并且撤销git add .
git reset HEAD^
# 不删除工作空间改动代码，撤销commit，不撤销git add .
git reset --soft HEAD^
# 删除工作空间改动代码，撤销commit，撤销git add .
git reset --hard HEAD^
工作中使用 Git 解决问题的场景
git rebase 让你的提交记录更加清晰可读
git rebase 的使用
rebase 翻译为变基，他的作用和 merge 很相似，用于把一个分支的修改合并到当前分支上。
如下图所示，下图介绍了经过 rebase 后提交历史的变化情况。
举一个实际的例子来解释一下上面的过程。
假如我们现在有1个feature分支，在此分支上新切一个rebase/dev分支，然后feature分支增加c.ts，d.ts两个文件，分别进行了2次提交；rebase/dev分支增加a.ts, b.ts两个文件，也分别进行了2次提交；
此时，两个分支的提交记录如下：
feature分支如下图：
rebase/dev分支如下图：
接着在rebase/dev分支上，执行 git rebase feature操作，然后提交；我们在SourceTree上看一下最终合并图表
如上图所示，提交记录没有交叉，非常清晰，上面演示是比较顺利的情况，但是大部分情况下，rebase 的过程中会产生冲突的，此时就需要手动解决冲突，然后依次使用 git add 、git rebase --continue 的方式来处理冲突，完成 rebase 操作过程； 如果不想要某次 rebase 的结果，那么需要使用 git rebase --skip 来跳过这次 rebase 操作。
git merge 使用
不同于 git rebase 的是，git merge 在不是fast-forward (快速合并) 的情况下， 会产生一条额外的合并记录，类似 Merge branch 'xxx' into 'xxx' 的一条提交信息。
按照 git rebase 的方式，也列举一下实际的例子进行演示：
假如我们现在有1个feature分支，在此分支上新切一个merge/dev分支，然后feature分支增加c.ts，d.ts两个文件，分别进行了2次提交；merge/dev分支增加a.ts, b.ts两个文件，也分别进行了2次提交；
此时，两个分支的提交记录如下：
feature分支如下图：
merge/dev分支如下图：
接着在merge/dev分支上，执行 git merge feature 操作，然后提交；我们在SourceTree上看一下最终合并图表
如上图所示，提交记录是有交叉的，并且会将 merge/dev 和 feature 分支最新一次提交合并后生成一个新的commit，有冲突的话需要先解决冲突，在merge过程中，也可以使用 git merge --abort 来取消本次merge；
总结一下 git rebase 和 git merge 区别
-
git rebase操作实际上是将当前执行rebase分支的所有基于原分支提交点之后的commit打散成一个一个的patch，并重新生成一个新的commit hash值，再次基于原分支目前最新的commit点上进行提交，并不根据两个分支上实际的每次提交的时间点排序，rebase完成后，切到基分支进行合并另一个分支时也不会生成一个新的commit点，可以保持整个分支树的完美线性
-
git merge 操作合并分支会让两个分支的每一次提交都按照提交时间（并不是push时间）排序，并且会将两个分支的最新一次 commit 点进行合并成一个新的commit, 最终分支数呈现非整条线性直线的形式