变基，变基推送提交是什么意思

人们常说，您不应该为已经推送的提交重新设置基础。那可能是什么意思？

该ProGit本书有一个很好的解释。

您的问题的具体答案可以在标题为“变基的危险 ”的部分中找到。该部分的引言：

在对内容进行基础调整时，您将放弃现有的提交并创建相似但不同的新提交。如果您将提交推送到某个地方，而其他人则将其拉下并在其上进行工作，然后使用git rebase重写这些提交，然后再次将其上推，那么您的协作者将不得不重新合并其工作，并且当您尝试执行以下操作时，事情会变得混乱将他们的工作拉回到您的工作中。

更新：
根据下面的评论，听起来您的Git工作流程有困难。以下是一些可能有用的参考：

• 该gitworkflows手册页：请参见“合并向上”和“话题分行”
• ProGit：请参阅“ 私人托管团队 ”
• Jarrod Spillers博客：请参阅“ git merge vs git rebase：避免对地狱重新设置 ”

要了解这一点，我们需要对git的工作原理有所了解。git存储库是一种树结构，其中树的节点是提交。这是一个非常简单的存储库的示例：

它在master分支上有四个提交，每个提交都有一个ID（在本例中为a，b，c和d）。您会注意到d当前是master分支的最新提交（或HEAD）。

在这里，我们有两个分支：master和my-branch。您可以看到master和my-branch都包含提交a和b，但是它们开始偏离：master包含c和d，而my-branch包含e和f。与master相比，b是my-branch的“合并基础”，或更常见的是，仅仅是“基础”。这很有意义：您可以看到my-branch是基于master的早期版本的。

假设我的分支已经过时，并且您想使用最新版本的master来更新它。换句话说，我的分支需要包含c和d。您可以进行合并，但是这会导致分支包含奇怪的合并提交，这使得审查请求请求变得更加困难。相反，您可以重新设置基准。

重新确定基准时，git查找分支的基准（在本例中为b），找到该基准与HEAD之间的所有提交（在本例中为e和f），然后在分支的HEAD上重新播放这些提交。您将基于此（在本例中为master）。Git实际上创建了新的提交，它们代表您的更改在master上的外观：在图中，这些提交称为e'和f'。Git不会删除您以前的提交：e和f保持不变，如果重新设置发生问题，则可以恢复到以前的状态。

当许多不同的人模拟地在一个项目上工作时，拉取请求很快就会过时。“过时的”拉取请求已不再是最新的开发主线，并且需要先进行更新，然后才能合并到项目中。拉取请求过时的最常见原因是由于冲突：如果两个拉取请求都修改了同一文件中的相似行，并且一个拉取请求被合并，则未合并的拉取请求现在将发生冲突。有时，拉取请求会过时而不会发生冲突：也许代码库中不同文件的更改需要对拉取请求进行相应的更改以符合新的体系结构，或者可能是当某人意外合并失败的单元测试到分支时创建了分支。主分支。不管什么原因

变基重写历史记录。如果没有人知道那段历史，那完全可以。但是，如果该历史是众所周知的，那么在Git中重写历史就像在现实世界中那样工作：您需要一个阴谋。

串谋确实很难保持在一起，因此您最好首先避免改组公共分支机构。

请注意，是成功的阴谋的例子：puJUNIO C.滨野的git仓库的分支（Git的SCM的官方资料库）经常重订。这种工作方式是，几乎所有使用过pu的人也都订阅了Git开发人员邮件列表，并且pu分支机构已改组的事实在邮件列表和Git网站上广泛宣传。

重新设置将更改存储库的历史记录。如果您将提交推向世界，即将其提供给其他人使用，然后您更改了提交历史的视图，那么与拥有您的旧历史的任何人一起工作将变得很困难。

我认为，认为有害的Rebase是一个很好的概述。