#序言
git rebase指示时常被认为是Git的妖术，新手如果避开它，但它事实上能让合作开发工程项目组在采用时更为随心所欲。那时，我们将git rebase与有关git merge指示展开较为。
#基本概念
具体而言要理解的是git rebase和git merge化解了反之亦然的难题。这三个指示都意在将更动从两个组成部分软件系统到另两个组成部分 – 它而已以相同的形式展开。换言之呵呵当你开始在专供组成部分中升级换代机能时另两个工程项目组核心成员以新递交预览master组成部分会出现什么。这会出现锯齿发展史纪录，对采用Git作为协同辅助工具的其它人而言都如果很熟识。
当分拆master组成部分到你的feature组成部分时，你有三个优先选择：merge或rebase。
#Merge
最简单最常见的是将master组成部分分拆到feature组成部分中：
这会在feature组成部分中建立两个捷伊“merge commit”，它将三个组成部分的发展史联络在一同，为你聚合如下表所示右图的组成部分内部结构：
分拆较好，因为它是一种非破坏力的操作方式。原有组成部分内部结构不能以任何人形式更动。这防止了rebase的大部份潜在性瑕疵（上面譬如）。再者，这也意味著每天下游更动时feature都须要分拆，且有毫无关系的分拆递交。如果master更动十分频密，这可能会轻微环境污染你组成部分的发展史纪录。虽然能采用高阶git log快捷键减低此难题的影响，但它可能使其它合作开发者无法认知工程项目的发展史更动记录。
#Rebase
作为merge的替代方法，你能采用以下指示将feature组成部分rebase到master组成部分上：
这会将整个feature组成部分移动到master组成部分的顶端，从而有效地整合了大部份master的新递交。但是，rebase不是采用merge commit，而是通过为原始组成部分中的每个递交建立全捷伊递交来重写工程项目发展史纪录。
rebase的主要好处是能获得更清晰的工程项目发展史纪录。具体而言，它消除了不必要的git merge产生的merge commit。其次，正如在上图中所看到的，rebase也会产生完美线性的工程项目发展史纪录 – 你能从feature组成部分顶端一直跟随到工程项目的开始而没有任何人的锯齿。
这使得它比指示git log，git bisect和gitk更容易浏览工程项目。但是，对这个原始的递交发展史纪录有三个权衡：安全性和可追溯性。如果你不遵循rebase的黄金法则，重写工程项目发展史纪录可能会对你的协同工作流程造成灾难性后果。其次rebase会丢失merge commit提供的上下文 – 你无法看到下游更动何时分拆到机能中。
#Interactive Rebase
Interactive rebase使你有机会在将递交移动到新组成部分时更改递交。这比自动rebase更强大，因为它提供了对组成部分递交发展史的完全控制。通常，这用于在分拆特征组成部分到master组成部分之前清理杂乱的发展史纪录。要开始基于交互式会话，请将i快捷键传递给git rebase指示：
这将打开两个文本编辑器，列出即将移动的大部份递交：
列表准确给出了执行rebase后组成部分的概况。通过更动pick指示和（或）重新排序，能使组成部分的发展史纪录成为你想要的内容。例如，如果第二次递交修复了第一次递交中的两个小难题，你能采用以下fixup指示将它压缩为单个递交：
保存并关闭文件时，Git将根据你的指令执行rebase，从而产生如下表所示右图的工程项目发展史纪录：
消除这种无意义的递交使你的发展史纪录更可读。这是git merge无法做到的事情。
rebase的黄金法则
一旦你认知了什么是rebase，最重要的是了解什么时候不采用它。git rebase的黄金法则是永远不要在公共组成部分采用它。例如，想想如果你把master组成部分rebase到你的feature组成部分会出现什么：
rebase将master大部份递交移动到feature顶端。难题是这只出现在你的仓库中。大部份其它合作开发者仍在采用原始版本master。由于rebase导致全捷伊递交，
Git会认为你的master组成部分的发展史与其它人的发展史相同。同步三个master组成部分的唯一方法是将它分拆在一同，从而产生额外的分拆递交和两组包含相同更动的递交（原始递交和来自rebase组成部分的更动）。
这将是两个十分令人困惑的情况。因此，在你运行git rebase之前，总是问自己，“还有其它人在用这个组成部分吗？”如果答案是肯定的，那就把你的手从键盘上移开，考虑采用非破坏力的形式展开（例如，git revert指示）。否则，你能随心所欲地重写发展史纪录。
强制推
如果你尝试将rebase过的master组成部分推到远程仓库，Git将阻止你这样做，因为它与远程master组成部分冲突。但是，你能通过传递–force标志来强制推送，如下表所示右图:
这将覆盖远程master组成部分以匹配rebase过的组成部分，并使工程项目组的其它核心成员感到困惑。因此，只有在确切知道自己在做什么时才能十分小心地采用此指示。
工作流rebase能根据你工程项目组的须要尽多地或少量地整合到你原有的Git工作流程中。在本节中，我们将了解rebase在机能合作开发的各个阶段的好处。任何人工作流程git rebase的第一步是为每个机能建立专供组成部分。这为你提供了必要的组成部分内部结构，以安全地利用rebase：
本地清理
将rebase加入工作流程的最佳方法之一是清理本地正在展开的机能。通过定期执行交互式rebase，你能确保机能中的每个递交都具有针对性和意义。这使你能写代码而无需担心将其分解为隔离多个的递交 – 你能在事后修复它。
调用git rebase时，有三个基（base）快捷键：feature的父组成部分（例如master），或feature中的发展史递交。我们在Interactive Rebasing部分看到了第两个快捷键的示例。当你只须要修复最后几次递交时，后一种优先选择较好。例如，以下指示仅针对最后3次递交的交互式rebase。
通过指定HEAD~3为捷伊基，你事实上并没有移动组成部分 – 你而已交互式地重写其后的3个递交。请注意，这不能将下游更动分拆到feature组成部分中。
如果要采用此方法重写整个机能，git merge-base指示可用于查找feature组成部分的原始基。以下内容返回原始基础的递交ID，然后你能将其传递给
交互式rebase的采用是引入git rebase工作流的好方法，因为它只影响本地组成部分。其它合作开发人员唯一能看到的就是你的成品，这如果是两个简洁易懂的组成部分发展史纪录。
但反之亦然，这仅适用于私有机能组成部分。如果你通过相同的组成部分与其它合作开发者协同，则该组成部分是公共的，因此你能重写其发展史纪录。
#总结
这就是你须要知道的关于rebase你的组成部分。如果你更喜欢递交的干净，消除不必要分拆的线性发展史纪录，那么你在继承另一组成部分的更动时如果采用git rebase 而不是git merge。
再者，如果你想保留工程项目的完整发展史纪录并防止重写公共递交的风险，你能仍然采用git merge。这两种优先选择都是完全能的，但至少能优先选择利用git rebase有它的好处。
