113

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

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

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

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

push --force是一件坏事。

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

简单示例

两个分支：

  • v1.0 - 发布分支，仅包含补丁
  • master - 下一个主要版本的一切。

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

合并前

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

git checkout master
git merge v1.0

但现在我正在尝试

git checkout master
git rebase v1.0

所以现在我在这里：

在此处输入图像描述

的时间：

git push

没有骰子。

4

6 回答 6

46

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

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

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

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

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

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

于 2012-06-15T21:26:09.217 回答
26

@CodeGnome 是对的。您不应该在 v1.0 分支上重新设置 master 基础，而是在 master 上重新设置 v1.0 分支，这将产生重大影响。

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

创建一个指向 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

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

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

于 2012-06-21T12:11:07.670 回答
22

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

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

这是您使用 rebase 的工作流程的核心，但不要强制推送太多：在它们准备好之前不要发布东西，不要在推送后 rebase。

于 2012-06-15T21:20:35.980 回答
5

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

于 2014-06-24T14:45:33.343 回答
4

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

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
于 2015-01-21T23:53:15.407 回答
0

tl;dr 与共享分支合并，与各个分支合并。--force-with-lease是一种更安全的武力替代方案，应该可以帮助您在没有武力破坏性的情况下实现所说的 git 必杀技。

我见过的适用于各种团队工作流程的一般经验法则是merge用于共享分支（即主分支或开发分支）并rebase在处理您自己的功能分支时使用。这是一个特征分支的典型生命周期

git checkout master
git checkout -b new-feature
git commit -am "commit new work"
git push -u origin new-feature
# have code reviewed, run CI, etc.,
# meanwhile master has new commits
git checkout master
git pull origin
git checkout new-feature
git rebase -i master # -i for interactive rebase allows you to squash intermediate commits
git push --force-with-lease
git merge master

我们在这里所做的简单英文版：

  1. 从 master 创建了一个新分支
  2. 在分支上完成工作并推送到远程
  3. 重新调整主控
  4. 将工作推送到远程force-with-lease
  5. 使用非常干净的 git log 合并到 master 中，减少来自我们共享分支的多次合并的混乱，以使我们的分支“赶上”最新的 master（共享分支）

第四步非常重要，也是我开始提倡使用 rebase 的主要原因之一。force-with-lease检查远程以查看是否添加了任何新提交。如果你git push被证明是破坏性的，它不会推动！

我希望这能让某人更有信心使用 rebase。

于 2020-06-11T08:25:28.703 回答