git&github自学教程（5）：更改提交的操作：reset、release
通过(3)和(4)，已经能够实现在完成功能开发后进行提交并查看提交日志，接下来要学习如何操作历史版本。
git能够进行高效协同开发的另一个基础就是借助分散仓库的优势，在不影响其他仓库的前提下对历史版本进行操作。
1，reset
git rest --hard命令让仓库的 HEAD、暂存区、当前工作树回溯到指定时期的状态，仅需要提供指定时间点的哈希值即可，那么，在哪里去找到这个哈希值呢？记得git log --graph命令码？补充一下：git log命令只能查看以当前状态为终点的历史日志。
- 回溯到创建 feature-A 分支前：
结果表明，已经成功回溯到特性分支（ feature-A）创建之前的一个状态。由于所有文件都回溯到了指定哈希值对应的时间点上，README.md文件的内容也恢复到了当时的状态，让我们一起来康康：
果然，feature-A木有了。 - 创建 fix-B 分支
在README.md中添加一行fix-B并进行提交，方便后续学习回溯特性：
此时，我们处于这样一个状态：
接下来我们的目标是主干分支合并 feature-A 分支的修改后，又合并了 fix-B 的修改：
3.推进至 feature-A 分支合并后的状态
首先要恢复到 feature-A 分支合并后的状态的时间哈希值，显然git log命令是不能在当前状态以某种操作结束后得到 feature-A 分支合并后的状态的时间哈希值的，可以用**git reflog命令，查看当前仓库的操作结束后的所有操作日志。**在日志中找出所需的哈希值：
然后切换到master分支，在回溯到所需状态，如下：
结果表明，我们当前处于这样一个状态：
最后，就可以向之前master合并feature-A1一样合并fix-B啦：
？？？合并失败？提示是应为合并的README.md内容起了冲突，看来是feature-A 分支更改的部分与本次想要合并的 fix-B 分支更改的部分发生了冲突。
4.查看冲突部分并将其解决
打开README.md，发现：
发现======= 以上的部分是当前 HEAD 的内容，以下的部分是要合并的 fix-B 分支中的内容。
解决办法就是直接在文档里进行修改，改成需要的结果再合并就行：
此时，在解决冲突并提交后，fix-B就被合并到master分支中，达到目的啦。
提交后发现提交信息表达的仅是master合并fix-B的一个过程，并不能完全表达“合并”信息，这怎么办呢？继续看。
5.git commit --amend——修改提交信息
要修改上一条提交信息，可以使用 git commit --amend命令，直接在启动的编辑器里修改就行，修改后：
(graph图看着不舒服，就画圈圈和线条整理一下，graph图中线条的颜色没有也别的意义，仅是为了好区分)：
问题来了：怎样编写好的commit???