Git更改提交

冰镇可乐

　　提交记录我们的工作历史记录，提交自身是一成不变的。Git提供了几个工具和命令，抓门用来帮助修改完善版本库中的提交。
　　实际工作中存在很多情况需要我们去修改或返工某个提交或者整个提交序列：
　　1，可以在某个问题变为遗留问题之前修复它；
　　2，可以大而全面的变更分解为一系列小而专的提交；
　　3，删除以外提交的调试代码；
　　4，在不破坏构建需求的情况下重新排列提交序列；
　　5，可以将提交调整为一个更合乎逻辑的序列；
　　一般而言，如果能让提交更简洁和利于理解，应该区更改提交或提交序列。
　　作为一般原则，只要没有其他协同工作人员已经获取了你的版本库的副本，你就可以自由地修改或完善版本库中的提交历史。
　　换言之，只要没人有版本库中某个分支的副本，你就可以修改该分支。如果一个分支已经公开了，并且可能已经存在于其他版本库中了，那就不应该退历史提交进行修改。
　　使用 git reset 命令
　　git reset 命令会调整 HEAD 引用指向给定的提交。默认情况下还会 更新暂存区 以匹配给定的提交。
　　根据需要，git reset 命令也可以 修改工作区 以呈现给定提交代表的项目修订版本。
　　git reset 命令是具有”破坏性的“，它可以覆盖并销毁 工作区 的修改。然而，此命令的重点为 HEAD，暂存区 和 工作区 建立与恢复状态。
　　git reste 命令有三个主要选项：--soft，--mixed 和 --hard。
　　git reset--soft [commit]
　　--soft 选项会将 HEAD 引用指向给定的commit。暂存区 和 工作区 的内容保存不变。
　　git reset --mixed [commit]
　　--mixed 是默认选项，会将 HEAD 指向给定的commit，暂存区 会跟着改变以符合给定commit的目录树（tree）。但是 工作区 的内容保持不变。
　　git reset --hard [commit]
　　--hard 选项会将 HEAD 引用指向给定的commit，暂存区 会跟着改变以符合给定commit的目录树（tree），并且，工作去 也会跟着改变以反映给定提交标识的目录树（tree）。
　　git reset 选项的影响范围
选项HEAD暂存区工作区--soft是否否--mixed是是否--hard是是是　　使用 git revert 命令
　　该命令用于 引入一个新的提交 来抵消指定提交的影响。git revert 命令不会修改版本库中现存的历史记录。相反，它会往历史记录中添加新的提交。
　　git revert 最常见的用途是“撤销”可能深埋在历史记录中的某个提交的影响。如下图中，在 master 分支上，出于某种原因，提交 D 被视为有缺陷的：

　　一个简单的方法是执行 git revert 命令。git revert master~3 #commit D，下标从0开始。
　　其中提交 D' 是提交 D 的逆转。

　　reset，revert 和 checkout 的困惑!
　　三条Git命令 reset，revert，checkout 的确很让人困惑，因为它们都执似乎类型的操作。
　　不过，也有一些很好的指引和规则，指明每条命令应在何时使用。
　　1，如果你相切换到不同的分支，使用 git checkout。当前分支 和 HEAD 引用都会变为匹配给定分支的头。
　　2，git reset 命令不会改变分支，它只会重置当前分支的 HEAD 引用，并且有可能会改变 暂存区 和 工作区的状态。
　　3，git revert 命令作用于全部提交，而不是文件。如果其他的协同工作的人员已经克隆的你的版本库或者获取了一些提交，那么修改提交历史记录就有很多影响。在这种情况下，不应该使用修改版本库中历史记录的命令。相反，应该使用 git revert 命令。
　　修改最新提交
　　改变当前分支的最近一次提交的最简单方法之一是使用 git commit --amend。该命令会弹出编辑器会话，可以在里面修改提交信息，甚至是元信息（--author 可以改变提交的作者）。
　　使用 git commit --amend 来修改最近提交的效果会是下面的两张图片所显示的效果：

　　提交 C 的实质依然是相同的，但它已经被修改成 C' 。HEAD 引用已经从旧的提交 C 指向替代的引用 C' 。
　　变基提交
　　git rebase 命令用来改变一串提交是以什么为基础的。此命令至少需要提交将迁往的分支名。默认情况下，不在目标分支中的当前分支提交会变基。
　　说白了，就是改变一个分支的起始分支基点。它最常用的作用就是“保持我们正在开发的一系列提交相对于另一个分支是最新的，那通常是 master 分支或者来自另一个版本库的追踪分支”。
　　例如下面图片的示例：有两个分支正在开发。最初，分支 topic 是从 master 分支 的提交 B 处开始的。但是一段时间后 master 分支已经进展到了提交 E。　　

　　可以改写提交让分支 topic 基于最新的提交 E 而不是 提交 B。可以这样来操作：
　　git checkout topic #检出topic分支
　　git rebase master #变基为master最新的提交
　　或者
　　git rebase master topic

　　这种情况下，使用 git rebase 命令通常成为向前移植（forward porting）。在Git中做一个向前或者向后移植的变基都可以使用 git rebase 实现。
　　git rebase 命令也是使用 --onto 选项把 一整条分支 整个移植到不同的分支上。

　　分支 feature 是基于 分支 maint 的提交 Y 的。现在想把 feature 分支整个从 manit 分支迁移到 master 分支，操作命令为：git rebase --noto master maint^ feature #找准基点就行

　　变基操作是从各自原始位置迁移到新的提交基础。因此，每个移动的提交都有可能会出现冲突。如果发现冲突 git rebase 命令会临时挂起进程以便我们来解决冲突，冲突的解决方式和合并的冲突解决方式一样。一旦所有冲突都解决了，并且索引项已经更新了，就可以使用 git rebase --continue 命令恢复变基操作。
　　最后，如果你临时发现不应该进行变基操作，就可以使用 git rebase --abort 来中止操作，并把版本库恢复到发出 git rebase 命令之前的状态。