这是我的历史：
* 8 [mybranch, origin/mybranch]
* 7
|\
| * 6 [master, origin/master]
* | 5
* | 4
|/
* 3
* 2
* 1
自第3次提交以来，创建了一个新的分支，在几次提交之后，我将我的分支与更新的master合并（我应该有rebase但是我做了一个合并）。所以，为了拥有更清晰的历史，我想实现这一目标（线性历史）：
* 8 [mybranch, origin/mybranch]
* 7
* 6 [master, origin/master]
* 5
* 4
* 3
* 2
* 1
有可能吗？
由于
答案 0 :(得分：2)
你应该可以通过以下方式做到这一点：
$ git rebase master mybranch
重新定位默认情况下会平展历史记录，而上述咒语表示要修改mybranch中尚未位于master master之上的所有内容。结果应如下所示：
* 8' [mybranch]
* 5'
* 4'
* 6 [master, origin/master]
* 3
* 2
* 1
这不是你要求的，但我认为这是你想要的。保留master分支，只会影响您的mybranch历史记录。
另请注意，提交7在此过程中丢失了。合并提交不应出现在平坦的历史记录中，因为它们不应自行引入任何更改。即使对于需要解决冲突的合并，情况也是如此。通过将一个分支重新定位在另一个分支之上，将在一个或多个重新分支的分支提交中发生（并且需要解决）冲突。实际上，合并提交之前完成的工作将被折叠到重新提交的提交中。
假设mybranch是其他人没有使用的东西，我认为在这种情况下做这个rebase是有道理的。但我同意@amn：最好避免过多地抄袭历史。我认为＆＃34;更简单＆＃34;是对线性历史的更好描述，而不是将其描述为＆＃34;更清洁＆＃34;，因为我认为后者倾向于暗示合并是一种不太理想的工作流程。合并比重新定位更稳健，更具可扩展性。使用后一种工作流程，您真的应该构建并测试每个重新定位的提交，而使用合并工作流程，您只需要测试最终的合并提交。
答案 1 :(得分：0)
你必须创造一个新的历史。首先创建所需历史记录的最直接方法是
* 8' mybranch
* 5'
* 4'
* 6 master origin/master
* 3
* 2
* 1
这不是你到目前为止创建的历史，它是一个不同的历史，所以新提交的id都是不同的，但它看起来像
origin/mybranch在你的回购中，你的git push -f origin mybranch以及历史记录被提取或推入的所有其他回购中的refs仍然指的是你不再喜欢的旧回购。如果你与那些拥有旧历史副本的人进行了良好的沟通，并且他们可以很好地进行获取和重新设置以切换到新历史记录，master是迄今为止处理此问题的最佳方法。
尽可能接近您要求的文字结果，12345678历史记录，也涉及重写mybranch - 分支历史记录，并生成一个如果你做得对的话你不会得到的历史记录第一次。
另一种选择，特别是如果现有的{{1}}历史记录已经找到了与您没有多少联系的回购路径，那就是保持原样并继续下去。线性很好，但就是这样。
答案 2 :(得分：-1)
你实际上无法使用Git移动提交 - 提交父权是其身份的一部分 - 一旦你重新提交提交，它就不再是相同的提交，即使它带来的更改集是相同的。 Git有目的地消化了对其身份的承诺。这有助于Git确保整个存储库的数据完整性。请注意，提交的损坏将总是散列到另一个标识符中，该设计符将会影响整个图形，因为Git无法解析父引用，并且基本上会告诉您图形已损坏。
无论如何，您的提交6，7和8在任何情况下都不会直接参与最终图表，而是它们的等价物（假设您在解决期间解决潜在的合并冲突）他们的创作）将表示为6'，7'和8'。
你需要做的是＆＃34; reparent＆＃34; （在引号中，因为如上所述，更改父级不再是相同的提交）提交6，由master分支偶然指向：
git rebase 5 master
上面创建了与提交6一起引入的等效更改，但好像这些更改已应用于提交5之上。此可能<或> 成功没有合并冲突，这完全取决于您通过编辑具有冲突内容区域的文件来解决。
您可以尝试使用交互式rebase（将-i开关添加到上面的命令中）以完全控制，但我怀疑在您的情况下它不会是必要的。
因此，您的提交6将保持不变，但是另一次提交，我们称之为6'将5作为唯一的父级 - rebase产品。默认情况下，提交按其时间戳排序git log显示，因此期望在图表/列表的顶部看到6'。
以类似的方式，然后在新提交mybranch之上重新定位6'指向的提交，这也是您现在的新master：
git rebase master mybranch
完成两个重新定位操作后，您将获得所需的提交图表。请注意，因为您正在追踪您的＆＃34;来源{34}的master分支。存储库（使用origin/master），该分支引用的提交将保留，这可能看起来令人困惑，但是必要的，因为在所有git之后将无法同步存储库。
我还建议你不要过多地了解历史。我知道这看起来令人困惑，但有一件事你必须记住，人类工作通常是非线性的，足以实际产生那种我们往往会发现不整洁的图形。但这些图表只代表我们的工作，而且本身并不整洁。这一点只是我的意见，你的可能会有所不同。