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