git 重新定位以及重新定位推送提交意味着什么

Rebasing and what does one mean by rebasing pushed commits

提问by Hemant Kumar

It is often said that, you should not rebase commits that you have already pushed. What could be meaning of that?

人们常说，你不应该对已经推送的提交进行 rebase。那可能是什么意思？

采纳答案by Tim Henigan

The ProGit bookhas a good explanation.

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

The specific answer to your question can be found in the section titled "The Perils of Rebasing". A quote from that section:

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

When you rebase stuff, you're abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.

当您重新设置内容时，您将放弃现有提交并创建相似但不同的新提交。如果你将提交推到某个地方，而其他人将它们拉下来并在它们的基础上工作，然后你用 git rebase 重写这些提交并再次将它们向上推，你的合作者将不得不重新合并他们的工作，当你尝试这样做时，事情会变得混乱把他们的工作拉回你的工作。

Update:
Based on your comment below, it sounds like your are having difficulty with your Git workflow. Here are some references that may help:

更新：
根据您在下面的评论，听起来您的 Git 工作流程有问题。以下是一些可能有帮助的参考资料：

• The gitworkflowsman page: See "Merging Upwards" and "Topic Branches"
• ProGit: See "Private Managed Team"
• Jarrod Spillers blog: See "git merge vs git rebase: Avoiding Rebase Hell"

• 该gitworkflows手册页：请参见“合并向上”和“话题分行”
• ProGit：参见“私人管理团队”
• Jarrod Spillers 博客：参见“ git merge vs git rebase：避免 Rebase Hell”

回答by pseudoCoder

To understand this, we need to understand a bit about how git works. A git repository is a tree structure, where the nodes of the tree are commits. Here's an example of a very simple repository:

要理解这一点，我们需要了解一下 git 是如何工作的。一个 git 仓库是一个树状结构，其中树的节点是提交。这是一个非常简单的存储库示例：

it has four commits on the master branch, and each commit has an ID (in this case, a, b, c, and d). You'll notice that d is currently the latest commit (or HEAD) of the master branch.

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

Here, we have two branches: master and my-branch. You can see that master and my-branch both contain commits a and b, but then they start to diverge: master contains c and d, while my-branch contains e and f. b is said to be the "merge base" of my-branch in comparison to master -- or more commonly, just the "base". It makes sense: you can see that my-branch was based on a previous version of master.

在这里，我们有两个分支：master 和 my-branch。您可以看到 master 和 my-branch 都包含提交 a 和 b，但随后它们开始出现分歧：master 包含 c 和 d，而 my-branch 包含 e 和 f。与 master 相比，b 被认为是 my-branch 的“合并基础”——或者更常见的是，只是“基础”。这是有道理的：您可以看到 my-branch 基于以前版本的 master。

So let's say that my-branch has gone stale, and you want to bring it up to date with the latest version of master. To put it another way, my-branch needs to contain c and d. You could do a merge, but that causes the branch to contain weird merge commits that make reviewing the pull request much more difficult. Instead, you can do a rebase.

因此，假设 my-branch 已经过时，并且您希望将其更新为最新版本的 master。换句话说，my-branch 需要包含 c 和 d。您可以进行合并，但这会导致分支包含奇怪的合并提交，从而使拉取请求变得更加困难。相反，您可以进行变基。

When you rebase, git finds the base of your branch (in this case, b), finds all the commits between that base and HEAD (in this case, e and f), and re-plays those commits on the HEAD of the branch you're rebasing onto (in this case, master). Git actually creates new commits that represent what your changes look like on top of master: in the diagram, these commits are called e′ and f′. Git doesn't erase your previous commits: e and f are left untouched, and if something goes wrong with the rebase, you can go right back to the way things used to be.

当你 rebase 时，git 找到你的分支的基础（在这种情况下，b），找到该基础和 HEAD 之间的所有提交（在这种情况下，e 和 f），并在分支的 HEAD 上重新播放这些提交你正在变基（在这种情况下，主人）。Git 实际上会创建新的提交，这些提交代表您在 master 上所做的更改：在图中，这些提交称为 e′ 和 f′。Git 不会删除您之前的提交：e 和 f 保持不变，如果 rebase 出现问题，您可以立即恢复到以前的状态。

When many different people are working on a project simulateously, pull requests can go stale quickly. A "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project. The most common reason why pull requests go stale is due to conflicts: if two pull requests both modify similar lines in the same file, and one pull request gets merged, the unmerged pull request will now have a conflict. Sometimes, a pull request can go stale without conflicts: perhaps changes in a different file in the codebase require corresponding changes in your pull request to conform to the new architecture, or perhaps the branch was created when someone had accidentally merged failing unit tests to the master branch. Regardless of the reason, if your pull request has gone stale, you will need to rebase your branch onto the latest version of the master branch before it can be merged.

当许多不同的人在模拟项目上工作时，拉取请求会很快过时。“陈旧”的拉取请求是指不再与开发主线保持同步的拉取请求，它需要更新才能合并到项目中。拉取请求失效的最常见原因是由于冲突：如果两个拉取请求都修改了同一文件中的相似行，并且一个拉取请求被合并，则未合并的拉取请求现在将发生冲突。有时，拉取请求可能会在没有冲突的情况下过时：可能代码库中不同文件中的更改需要拉取请求中的相应更改以符合新架构，或者当有人不小心将失败的单元测试合并到主分支。不管是什么原因，

回答by J?rg W Mittag

Rebasing rewrites history. If nobody knows about that history, then that is perfectly fine. If, however, that history is publicly known, then rewriting history in Git works just the way it does in the real world: you need a conspiracy.

变基改写历史。如果没有人知道那段历史，那完全没问题。然而，如果这段历史是公开的，那么在 Git 中重写历史就像在现实世界中一样：你需要一个阴谋。

Conspiracies are reallyhard keep together, so you better avoid rebasing public branches in the first place.

阴谋真的很难保持在一起，所以你最好首先避免改变公共分支的基础。

Note that there areexamples of successful conspiracies: the pubranch of Junio C. Hamano's git repository (the official repository of the Git SCM) is rebased frequently. The way that this works is that pretty much everybody who uses puis also subscribed to the Git developer mailinglist, and the fact that the pubranch is rebased is widely publicized on the mailinglist and the Git website.

请注意，是成功的阴谋的例子：puJUNIO C.滨野的git仓库的分支（Git的SCM的官方资料库）经常重订。这样做的方式是，几乎每个使用pu它的人都订阅了 Git 开发人员邮件列表，并且pu分支重新定位的事实在邮件列表和 Git 网站上得到了广泛宣传。

回答by dsolimano

A rebase alters the history of your repository. If you push commits out to the world, i.e., make them available to others, and then you change your view of the commit history, it becomes difficult to work with anyone who has your old history.

变基会更改存储库的历史记录。如果您将提交推向全世界，即让其他人可以使用它们，然后您改变了对提交历史的看法，那么与拥有您旧历史的任何人合作将变得困难。

Rebase considered harmfulis a good overview, I think.

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