保持git提交记录干净易懂发布分支就是版本分支提交信息应该是基于一个版本的产品功能说明；而开发分支是为了方便开发人员管理

参考：

判断是否使用--squash选项最根本的标准是，待合并分支上的历史是否有意义 by git merge之squash

发布分支与开发分支

发布分支就是版本分支提交信息应该是基于一个版本的产品功能说明；而开发分支是为了方便开发人员管理自己的代码，为了便于追溯可以是一系列的动作记录。

前辈提出开发提交要保证发布分支历史清晰简洁——同一个功能点进行一次提交，杜绝“Merge branch 'xxx' into 'xxxxx'”这种提交；

在开发分支上，我会通过一次提交来进行行为的记录，便于之后追溯/回退，这并不符合发布分支的要求，要怎么实现前辈的的提议呢？

rebase
squash

git merge —squash [branchname]

master分支：受保护的主分支，保持提交的简洁，只merge其他分支
dev分支：开发分支
release分支：版本发布分支，保持提交的简洁

git checkout release
git merge --squash dev
git commit

在release分支上执行第2步后，从分叉的节点开始后的所有提交（dev分支上的）都会变成added的状态，继续执行第3步将所有的变更一次提交；commit的时候记录里会自动生成squashed from信息，会导致commit信息冗杂但也是一种记录，重新commit之后就看不到和原先的提交间的联系了。dev分支的提交记录仍然会保存。

git rebase and merge and rebase -i

m.n.k分支：版本分支，从master检出
feature分支：基于版本分支的特性分支

git checkout feature
git rebase m.n.k
git checkout m.n.k
git merge feature

执行完毕后，出现了提交时间这个属性（正常提交只有日期），提交时间记录了merge的时间，日期记录了commit的时间（sourceetree中这样区分）；feature分支变基到了m.n.k上；sourcetree上可以看到，feature和m.n.k在同一个历史线上，feature的起点发生了改变。

git rebase -i [startCommitID] [endCommitID]

执行完毕后，多次提交被合并为了1次提交。

git merge

m.n.k分支：版本分支，从master检出
feature分支：基于版本分支的特性分支

git merge feature
无冲突合并/解决冲突并提交

执行完毕后，产生了新的提交“Merge branch 'feature' into m.n.k”，（合并分支和被合并分支有分叉就会导致多处一次Merge branch的提交记录，点击此处了解更多）；sourcetree上可以看到，feature这条线被合并入m.n.k中，有明确的切出点、提交点、合并点。

git reflog and reset —hard reflogID

这一步是我在删除所有实验分支后执行的，目的是把dev分支回到变基前的状态

git checkout -b dev-recovery master
git reflog找到想要回到的ID
git reset --hard reflogID

dev-recovery分支回到了之前dev分支的状态！但我反而有些疑惑了，我修改的/恢复的只是一串串commitID，控制他们是否展现给用户吗？这些commitID其实一直存在，只是不同的操作导致了他们之间关系的变化，commitID/git提交记录本质上是链表吗？