Git 的主要工作是要确保你永远不会丢失已提交的更改。但是，它同时也是为了让您在您的开发工作流的完全控制。这包括让您定义确切地是什么您的项目历史样子 ；然而，它还创建可能遭受损失提交。Git 提供其历史重写命令下使用它们可能会导致丢失内容的免责声明。
本教程讨论了一些覆盖致力的快照的最常见原因，并显示你如何避免这样做。
的命令是一个方便的方法来解决最近提交了。它允许您阶段性的变化结合之前的提交，而不是提交作为一个完全新的快照。它也可以用于只需编辑以前提交消息，而无需更改其快照。
但修订并不只是改变最近提交 — — 是完全替换了它。到 Git，它会看起来像全新的提交，则显示为星号 (*） 在上面的图。很重要的是要记住这一点，当工作与公共存储库。
使用
结合上一次提交的阶段性的变化和上次提交替换所生成的快照。这个运行时上演的什么都不允许您编辑以前提交消息而不改变其快照。
讨论
过早提交发生在你日常的发展过程中的所有时间。它很容易忘记阶段文件或者格式化您的提交消息错误的方式。的国旗是简便的方法来修复这些小错误。
不要修改公共提交
对页面上，我们谈论如何你应该永远不会重置已与其他开发人员共享的提交。这同样适用于修正： 永远不会修改已经被推向一个公共版本库的提交。
实际上完全新的提交，并修订的提交上次提交从项目历史记录中删除。这已重置公众的快照相同的后果。如果你修改提交，其他开发人员有基于他们的工作，它会看起来像他们工作的基础从项目历史记录里消失了。这是一个令人困惑的局面，开发人员需要在和它很复杂，从恢复。
示例
下面的示例演示 Git 为基础的发展中的一个常见场景。我们编辑我们想要在一个单一的快照，犯下的几个文件，但之后我们忘了添加一个文件的第一次。修复错误只是暂存另一个文件并与犯标志：
编辑器将填充来自上次提交的消息，包括国旗将让您可以向您提交修订而不改变其提交消息。你可以改变它，如果必要，否则为只是保存并关闭该文件像往常一样。由此产生的提交将替换不完整的和它将看起来像我们承诺的变化和在单个快照。
重订基期是将一个分支移到一个新的基地交付的过程。一般的过程可以被可视化为以下内容：
从内容的角度来看，重订基期真的只一个分支从移动一次提交到另。但在内部，Git 完成这通过创建新的提交，并将它们应用到指定的基 — — 这从字面上重写您的项目历史。它是非常重要的是要明白即使分支看起来相同，它组成的完全新的提交。
使用
变基到当前分支< 基地 >，可以是任何一种提交参考 （ID、 分支名称、 标记或对相对引用).
讨论
重订基期的主要原因是保持线性项目历史记录。例如，请考虑主分支已在功能上开始工作之后的情况：
有两个选项可用于集成到您的功能分支： 直接合并或重订基期，然后合并。前一种选择结果 3 种方式合并，合并提交，而后者结果在快进合并和完美的线性的历史。下面的关系图演示如何到基址便于快进合并。
重订基期是常见的方式，将上游的改动纳入本地资源库。拉动上游的变化在每次您想要查看的项目的进展如何的多余合并提交的结果。另一方面，重订基期是像是在说，"我想要我的变化的基础每个人都已经所做的是什么"。
不重订公共历史
正如我们已经讨论与和你应该永远不会变基已经被推向一个公共版本库的提交。Rebase 将以新的取代旧的提交，它会看起来像您的项目历史那部分突然消失了。
例子
下面的示例结合 git rebase git 合并，以保持线性项目历史记录。这是一种确保您合并将是节目的快速简便的方法。
在我们的特色，我们意识到我们的项目有一个安全漏洞
合并后该修补程序的主人，我们有分叉的项目历史记录。而不是平原 git 合并，我们会把他们的特性分支结合 rebase 能够保持一个线性的历史：
这将新功能移到尖端的主人，让我们做一个标准的快进合并从主服务器：
运行与国旗开始基址的交互式会话。而不是盲目地移动所有提交到新基地，交互式基期给你的机会来改变个人提交过程中。这允许您通过删除、 拆分，并改变现有系列的提交清理历史。这就像注射了类固醇。
使用
变基到当前分支但使用基址的交互式会话。这为每个提交基期打开编辑器，您可以在其中输入命令 （如下所述）。这些命令确定如何个人即属将转移到新的基地。您还可以重新安排提交清单更改提交自己的顺序。
讨论
交互式基期给您完全控制您的项目历史是什么样子。这给开发人员，提供很大的自由，因为它让他们犯下"的混乱"的历史，虽然他们专注于编写代码，然后回去和事后清理它。
大多数开发人员喜欢使用交互式 rebase 抛光特性分支合并到主代码库中之前。这给了他们机会壁球微不足道的提交，删除过时的并确保其他的一切都是为了给"官方"的项目历史记录之前。对其他人来说，它会像整个特征开展了周密提交单一系列。
例子
找到下面的例子是一个从非交互式互动适应页。
最后一个命令将打开编辑器填充从新功能以及一些说明的两个承诺：
您可以更改每个提交前的挑命令，以确定它如何获取移动在 rebase 期间。在我们的例子，让我们只是结合两次提交一个壁球命令：
保存并关闭编辑器开始 rebase。这将打开另一个编辑器中寻求合并的快照的提交消息。定义提交消息之后, rebase 是完整，你应该能够看到被压扁的犯在你输出。这整个的过程如下：
请注意被压扁的提交具有不同的 ID，比原来的承诺，告诉我们它确实是一个全新的提交。
最后，你可以快进合并，以融入主代码库的抛光的特性分支：
交互式重订基期的真正力量可以见于产生的主分支的历史 — — 额外的提交是无处可寻。对其他人来说，它看起来像你是聪明的开发人员实现的人同属第一次的完美量。这是如何互动的基期可以保持干净和有意义的项目历史记录。
Git 跟踪的尖端的分支机构使用一种称为 reflog 机制的更新。这允许您回到变更集，即使他们未引用的任何分支或标记。后改写历史，reflog 包含分支的旧状态信息，并允许您回到那种状态，如有必要。
使用
表明 reflog 的本地资源库。
显示与相对日期信息 （例如 2 周前） reflog。
讨论
每次当前头获取更新 （通过切换分支，拉新的变化，改写历史或简单地通过添加新的提交） 一个新的条目将添加到 reflog 中。
示例
要了解让我们看一个示例。
Reflog 上述显示签出从硕士到 2.2 分支和背部。从那里，有一个年长的提交到硬重置。最近的活动表示顶部标有.
如果事实证明你意外搬回来，reflog 将包含指向 （0254ea7） 之前你意外下降 2 提交, 提交硕士。
使用它是然后可能要回到以前提交更改母版。这提供一个安全网，以防被意外更改历史。
它是重要的地注意到 reflog 只提供一个安全网，如果更改已致力于您的本地存储库，它只跟踪运动。