如何在不需要强制推送的情况下使用 git rebase？

How can I use git rebase without requiring a forced push?

提问by Roy Truelove

In an attempt to achieve git nirvana, I'm spending the day learning how to leverage rebase for situations where I currently merge.

为了实现 git 必杀技，我花了一天时间学习如何在我目前合并的情况下利用 rebase。

When running through what I consider to be a git 101 flow (which I spell out below), I have to push --forcewhen pushing my changes back to the origin.

当运行我认为是 git 101 流程（我在下面详细说明）时，我必须push --force将更改推回原点。

I'm not the only one - I know that this is covered ground (see 1,2,3,4,5), and I understand the technical reasons whya force is necessary. My issue is this --- there are many (many) blog entries singing the praises of rebase and how it's changed their lives (see 1,2,3,4to list a few), but none of them mentions that push --forceis part of their flow. However, nearly every answer to the existing stackoverflow questions say things like "yeah, if you're gonna rebase, ya gotta use push --force".

我不是唯一的人 - 我知道这是覆盖地面（参见1、2、3、4、5），并且我理解为什么需要使用力的技术原因。我的问题是 --- 有很多（很多）博客文章赞美 rebase 以及它如何改变了他们的生活（请参阅1、2、3、4列出一些），但没有人提到这push --force是他们的流量。然而，几乎所有现有 stackoverflow 问题的答案都说“是的，如果你要变基，你必须使用push --force”。

Given the number and religiosity of rebase advocates, I have to believe that using 'push --force' is not an inherent part of a rebase flow, and that if one often has to force their pushes, they're doing something wrong.

鉴于 rebase 拥护者的数量和宗教信仰，我不得不相信使用 'push --force' 不是 rebase 流程的固有部分，如果一个人经常不得不强迫他们推动，他们就做错了。

push --forceis a bad thing.

push --force是件坏事。

So here's my flow. In what way could I achieve the same results without a force?

所以这是我的流程。 在没有力量的情况下，我可以通过什么方式获得相同的结果？

Simple Example

简单示例

Two branches:

两个分支：

• v1.0- a release branch, contains only patches
• master- everything for the next major release.

• v1.0- 一个发布分支，只包含补丁
• master- 下一个主要版本的所有内容。

I've got a few patch commits and a few commits for the next release.

我有一些补丁提交和下一个版本的一些提交。

I'd like to incorporate the patches into my master so that they're not lost for the next release. Pre-enlightenment I'd simply:

我想将补丁合并到我的母版中，这样它们就不会在下一个版本中丢失。启蒙前我只想：

git checkout master
git merge v1.0

But now I'm trying

但现在我正在尝试

git checkout master
git rebase v1.0

So now I'm here:

所以现在我在这里：

Time for:

的时间：

git push

No dice.

没有骰子。

采纳答案by Todd A. Jacobs

Rebasing is a great tool, but it works best when you use it to create fast-forward merges for topic branches onto master. For example, you might rebase your add-new-widget branch against master:

Rebase 是一个很棒的工具，但是当您使用它为主题分支创建快进合并到 master 时，它的效果最佳。例如，您可以针对 master 重新设置 add-new-widget 分支：

git checkout add-new-widget
git rebase -i master

before performing a fast-forward merge of the branch into master. For example:

在执行分支到 master 的快进合并之前。例如：

git checkout master
git merge --ff-only add-new-widget

The benefit of this is that your history won't have a lot of complex merge commits or merge conflicts, because all your changes will be rebased onto the tip of master before the merge. A secondary benefit is that you've rebased, but you don't have to use git push --forcebecause you are not clobbering history on the master branch.

这样做的好处是你的历史不会有很多复杂的合并提交或合并冲突，因为你的所有更改都会在合并之前重新基于 master 的提示。第二个好处是您已经重新定位，但您不必使用，git push --force因为您不会破坏主分支上的历史记录。

That's certainly not the only use case for rebase, or the only workflow, but it's one of the more sensible uses for it that I've seen. YMMV.

这当然不是 rebase 的唯一用例，也不是唯一的工作流程，但它是我见过的更明智的用途之一。天啊。

回答by Fabien Quatravaux

@CodeGnome is right. You should not rebase master on v1.0 branch but v1.0 branch on master, that will make all the difference.

@CodeGnome 是对的。你不应该在 v1.0 分支上 rebase master，而应该在 master 上 rebase v1.0 分支，这会有所不同。

git checkout -b integrate_patches v1.0
git rebase master
git checkout master
git merge integrate_patches

Create a new branch that points to v1.0, move that new branch on top of master and then integrate the new version of the V1.0 patches to the master branch. You will end up with something like :

创建一个指向 v1.0 的新分支，将该新分支移动到 master 之上，然后将新版本的 V1.0 补丁集成到 master 分支。你最终会得到类似的东西：

o [master] [integrate_patches] Another patch on v1.0
o A patch on v1.0
o Another change for the next major release
o Working on the next major release
|  o [v1.0] Another path on v1.0
|  o A patch on v1.0
| /
o Time for the release

This way to use rebase is recommended by the official git documentation.

这种使用rebase的方式是git官方文档推荐的。

I think you are right about git push --force: you should only use it if you made a mistake and pushed something you did not want.

我认为你是对的git push --force：你应该只在你犯了错误并推送了你不想要的东西时使用它。

回答by Daniel Pittman

You have to force push if you rebase, andyou have already published your changes, right?

如果你变基了，你必须强制推送，而且你已经发布了你的更改，对吗？

I use rebase a whole bunch, but I either publish to something private where a force push doesn't matter (eg: my own clone on GitHub, as part of a pull request), or I rebase before I push for the first time.

我使用了一大堆变基，但我要么发布到一些与强制推送无关的私有内容（例如：我自己在 GitHub 上的克隆，作为拉取请求的一部分），要么在我第一次推送之前变基。

This is the heart of the workflow where you use rebase, but don't force push much: don't publish things until they are ready, don't rebase after you push.

这是使用 rebase 的工作流程的核心，但不要强制推送太多内容：在准备好之前不要发布内容，不要在推送后重新设置。

回答by 8forty

I think there's a good use-case for this rebase-then-force-push pattern that's not a result of a mistaken push: working on a feature branch by yourself from multiple locations (computers). I do this often, since I sometimes work at the office on my desktop, and sometimes from home/customer-site on my laptop. I need to rebase occasionally to keep up with the main branch and/or to make merges cleaner, but I also need to force-push when I leave one machine to go work on another (where I just pull). Works like a charm, as long as I'm the only one working on the branch.

我认为这种 rebase-then-force-push 模式有一个很好的用例，它不是错误推送的结果：您自己从多个位置（计算机）处理功能分支。我经常这样做，因为我有时在办公室使用台式机工作，有时在家里/客户现场使用笔记本电脑工作。我需要偶尔变基以跟上主分支和/或使合并更干净，但是当我离开一台机器去另一台机器工作时（我只是拉），我也需要强制推送。只要我是唯一一个在分支上工作的人，它就像一种魅力。

回答by redolent

Here's what I use (assuming your branch name is foobar):

这是我使用的（假设您的分支名称是foob​​ar）：

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work