github分支处理stash,rebase,merge,fastforward以及分支代码提交主分支

1 git 文件存储的三个区域

Git对文件的存储一共分为3个区域，分别是工作区(workspace)，暂存区(staging area)以及代码仓库(repository)。分为三个区的目的也非常明确，就是能够将本地未跟踪代码以及仓库版本代码进行隔离，并且能够极大程度上为本地未跟踪代码入库提供便利。

工作区是git软件未对代码进行跟踪的位置，我们修改代码就如同没有版本管理软件一般操作；

代码仓库是本地git版本管理软件进行所有提交版本存储的位置；

中间的暂存区不言而喻就是进行缓冲的一个区域，可以整合每一次向暂存区提交的修改，并且在所有修改都完成后统一将代码推向本地代码仓库。

git软件同时还提供了一个栈式的结构stash，相比较于暂存区，stash操作只能以快照的形式处理每一次压栈，并且每一次压栈所存储的快照之间是不能够合并的。这就能体现出暂存区的优势出来

Git采取的是增量式文件存储系统，类似于hadoop中的redo log 或者是MySql主从模式下的bin log，因此每一次提交实质上记录的是与上一次提交相比不同的记录。

2 git 简单提交格式以及三种位置文件的查询修改

1. git 将文件从工作区提交到本地版本仓库一套流程十分清晰：

> git add . # 一次性添加全部文件
> git add [file_name] [file_name] ... # 添加特定文件
> git commit -m "comments for this commit"

2. 如果我们需要查询各个位置的文件，可以使用 ls-files工具

> git ls-files -c # 列出在暂存区的文件
> git ls-files -o # 列出未跟踪，即在工作区的文件
> git ls-files -t # 列出所有跟踪的文件
> git ls-files -s # 显示所有文件状态信息

3. 在查询到文件所在位置后，如果希望清除已经提交到暂存区的文件，可以使用–cached长参数删除暂存区文件

> git rm -r --cached # 将暂存区清空
> git rm [file_name] [file_name] ... --cached # 清空指定文件

3 git rebase

rebase 操作适用于将同一个分支上的多个提交合并成为一个提交，目的在于简化该分支上的提交历史。rebase操作通常有以下三个步骤

1. 发起rebase
2. 进入交互界面选择合并commit以及保留commit，并为此次rebase添加说明
3. 结束rebase 或 终止rebase

> git rebase -i [需要合并的最旧提交编号] [需要合并的最新提交编号]

• 注意： 第二个参数若空白git默认为HEAD指针指向的提交，一般为最新提交
• 另外我们也可以使用HEAD～[位置]指定提交，HEAD指针指向的提交（一般是最新的提交）默认是HEAD～1，位置为阿拉伯数字，该值从HEAD指针指向的提交往前依次递增；
• 以上的合并区间是左开右闭的

需要注意的是，rebase只能够对拥有至少一个公共祖先提交的一系列提交进行合并，但这个公共祖先不能够是该仓库的首个提交。

进入交互界面后，前几行便是需要进行合并的commit提交编号，注意，所有的提交是按照时间顺序降序排列的，即较新的提交在上方，较老的提交在下方。我们通常会选择保留最新的提交，也就是保留第一行，然后合并第一行以后的所有行或合并到指定行
按照提示，保留参数为p，合并参数为s

最后，如果没有任何冲突，我们将会进入最后commit说明的提交阶段。git会默认将所有合并的commit说明一并记录到合并后保留的commit说明中，我们也需要为这次合并添加一个新的说明。如果不需要过去的所有说明，可以在这个阶段对不需要的说明行进行删除。

如果rebase出现问题，需要进行以下操作

> git rebase --todo #重新修改合并文件，返回第二步
> git rebase --continue #修改过后，继续rebase的过程
> git reabse --abort #终止此次过程

在rebase后，本地代码可能会与远程代码产生历史差异，并且远程代码版本可能会滞后于本地版本。此时如若确定本地版本是最新版本，并且希望通过本地的代码提交历史记录覆盖远程的历史记录，需要使用–force参数进行强制覆盖，用法如下

> git push [remote repo alias] [local branch name]:[remote branch name] --force

4 git merge

merge操作的本质是将拥有至少一个公共祖先的两个提交中的修改合并，并结合并结果产生一个新的提交存储在代码仓库中。从这个概念出发，我们能够将merge操作分为两种不同的情况：

1. 从同一个commit出发，分出两个不同的分支A和B。今后A和B同时独立进行开发提交，最后希望将B分支合并到A分支中，这就是最普遍的三路合并，我们也可以说merge操作是将指定分支合并到当前分支

> git checkout [branch A] #需要首先处于合并后处于主干的分支上
> git merge [branch B] # merge的参数需要是合并后消失的分支

在提交merge请求后，会进入交互界面，如果两次提交中出现两个版本同时出现的差异，这也被称作冲突；该交互界面将会通过对对比显示两个版本之间的冲突，并且相应文件中也会产生清晰的提示信息。此时需要我们退出交互界面，然后对相应的文件进行修改。

需要注意的是，合并过程中工作区的文件实际上是git在两个 commit共同祖先处提取并且叠加两个分支需要合并的commit产生的修改呈现出来的文件。因此这是一个全新的文件系统快照，不是两个comiit中的任何一个。然后选择继续合并或者是终止合并；

> git add . # 进行冲突修改后，需要将修改后的代码存入暂存区
> git merge --continue # 继续进行merge，这个指令会进入产生新的commit的步骤
> git merge --abort # 此时终止merge，系统会退回merge之前的状态

继续merge的操作实际上就是产生新的commit的操作，需要我们在交互界面中提交此次commit的说明，然后提交commit，merge即结束。

2. 从同一个commit出发，在同一个分支上的两个不同的commit。 此时git会采用fast-word模式进行合并，即直接将HEAD指针指向最新的提交，并且不会生成新的commit
3. 如果希望git 不采用fast-forward模式进行合并，即希望能够在同一分支的提交合并后产生一个标记合并的commit，可以采用 --no-ff 参数

> git merge [commit]  --no-ff

5 merge 与 rebase 区别

1. 首先，rebase建议使用在单独的分支上，而不要使用在分支间，以减少分支间提交产生混乱
2. 其次，rebase在相同分支上的操作类似于merge fast foward 操作，存在的不同在于rebase将会同步删除掉合并区间内的所有commit，而merge fast forward只会移动当前的HEAD到指定提交，并且不会删除掉两个合并点中间的commit
3. 所以merge常用于解决分支间合并操作，是开发分支并入主分支的重要操作；而rebase常用于解决分支内部多余提交的合并，是开发分支内协调整理的重要操作。

6 git stash

stash 提供了一个栈式存储空间，用于存放工作区产生的修改。但是需要注意的是，stash存储的存储区文件仅基于当前分支，并且为了避免产生版本冲突，在进行stash之前最好先进行一次提交。

stash中的文件区快照以栈的方式储存，每一个位置都有自己的编号，如果存入多个文件区快照，我们能够通过编号进行索引

> git stash save "message" #将当前未提交的修改保存到暂存区，并添加一个说明信息。
> git stash list #列出所有的 stash 记录。
> git stash apply [stash_id] #应用某个 stash 记录，并将其从栈中删除。
> #如果不指定 stash_id，则默认应用最新的 stash 记录。
> git stash pop [stash_id] #应用某个 stash 记录，并将其从栈中删除。
> #与 apply 的区别是，pop 操作会将栈顶 stash 记录弹出。
> git stash drop [stash_id] #删除指定的 stash 记录。
> git stash clear #清空所有的 stash 记录。
> git stash branch [branch_name] [stash_id] 
> #创建一个新分支，并应用某个 stash 记录到该分支上。
> #如果不指定 stash_id，则默认应用最新的 stash 记录。

7 开发中的应用

在开发中，我们常常从master中pull出分支，然后进行产品功能的迭代开发，在开发完成后，我们再将该分支合并回主分支，此时建议：

a. 通过git stash，将自己开发分支的代码保存到暂存区中，恢复本地仓库到修改前的状态；
b. checkout master进入主分支，git pull拉取master的最新commits；
c. checkout mydev进入开发分支，通过git rebase master将master最新的提交，合并到自己的开发分支上， 保证该分支的历史提交与master相同；
d. git stash pop将自己的修改取出；git commit、git push提交到远程开发分支上；
e. 发起merge请求，合并到master分支