主页 / 问题 / 568660
Accepted
sys_dev
Asked:2020-09-21 17:21:15 +0000 UTC2020-09-21 17:21:15 +0000 UTC

在什么情况下可以并且应该进行 rebase，在什么情况下不能进行？

  • 772

我不能自己下结论，我应该什么时候下结论rebase？我请有经验的同志分享他们的经验，并说明影响需要做什么的决定的标准rebase。并举例说明没有必要这样做的情况。

假设我创建了一个 branch1 来实现 feature1。此时master分支提交到commit0。与我同时，Vasya在branch2中同步实现feature2并合并到master中。Branch2 由 commit1、commit2、commit3 组成，这些提交在 master 中结束。我想使用 GIT 将我的分支带到状态，就好像我从 commit3 开始创建我的 branch1 一样。

在我的情况下可以接受rebase吗？

git

2 个回答

  1. Best Answer

    备份

    如有疑问，请进行备份。任何方式都可以：

    git branch backup
git tag backup
git reflog

    保存历史！

    如果您在合并之前将功能分支变基到 master ，我强烈建议您使用merge --no-ff，即 强制创建合并提交。没有这个，将获得快进和完全线性的历史。

    合并提交将显示项目工作的历史记录，特别是功能分支被合并的时刻和合并作者（跳过 master 中的代码的人）。从 2.6.0 版本开始，git 已经能够撤消（还原）合并提交。如果没有合并提交，您将不得不指定要撤消的确切提交集，这对于线性历史来说并不容易。

    什么时候不

    • 您不能在稳定分支（master、stable、production等release-1.0）中对任何内容进行变基。
    • 当您将提交推送到远程（共享）存储库并且有人使用它时：
      • 回复他
      • cherry-pick在另一个线程中制作
      • 冻结在另一个线程
      • 引用了这个提交（GitLab 和 GitHub 然后在提交页面上创建一个提到链接的评论）
    • 你永远不应该改变别人的承诺。如果你这样做，Linus 会在晚上来找你并将双手重新放在臀部。

    小心

    当您从多个提交中变基分支并且您关心干预提交时，请在变基后检查每个分支。rebase 会重写每个中间提交的内容，因此如果您的特定提交的代码之前已经编译或通过测试，那么在 rebase 之后它就不会通过。

    如果你的分支有相当多的commit，并且有冲突，你将不得不多次解决它们（正是因为每次commit的内容都被覆盖了）。为了进行比较，对于正常的合并，您在实际的合并提交中解决它们一次。

    什么时候可以

    • 当您有一个不在远程存储库中的本地分支时
    • 或者当分支位于远程存储库中时，但肯定没有人使用过它。

    何时

    • 如果您的团队习惯于在master合并和/或打开合并请求之前进行变基。
    • 如果您的团队习惯于在合并和/或打开合并请求之前将提交合并（展平、压缩）。

    如果团队也有不使用其他人未在 master 中签出的提交的规则，则上述原因有效。如果满足“不允许时”部分中的任何条件，则不能变基。

    合并前测试

    Rebase 在测试中提供了一些优势。假设有分支master和feature。自动和手动测试、代码自动检查、分析器等在两个分支上都显示出积极的结果。合并后这个结果会持续吗？一般来说，它是未知的。即使合并没有冲突，合并后代码也可能根本无法编译。

    因此，有理由master在最终测试之前重新设置基准。然后 head 提交feature将与未来的合并提交相同。但是由于已经描述的原因，这种方法效率低下：

    1. 需要额外的工作来解决冲突
    2. 破坏中间提交的内容

    如果需要解决冲突并全面测试合并的结果，但还没有合并到 master 中，最好使用反向合并技术： master合并到feature. 因此，合并提交出现在feature.

    生成的合并提交可以在本地测试，可以推送到远程分支origin/feature以更新合并请求、运行测试、CI、部署到测试环境等。通过所有检查后，进行“直接”合并 - featurein master。

    您不需要master像那样合并到您的分支机构，在处理功能的过程中，这会导致莫斯科地铁地图形式的故事。如果你可以不合并master-feature一定要通过。

    • 15

  2. 在所描述的情况下，图形如下所示：

    > git log --graph --decorate --oneline --all
*   12ef823 (HEAD -> master) Merge branch 'b2'
|\
| * 3b8d7a6 (b2) b2:commit3
| * 5892389 b2:commit2
| * 245fefe b2:commit1
|/
| * ccca93c (b1) b1:commit1
|/
* 406f362 initial commit

    变基

    最简单和最合乎逻辑的更新方式是变基

    > git checkout b1
> git rebase master
> git log --graph --decorate --oneline --all
* 5f613a9 (HEAD -> b1) b1:commit1
*   12ef823 (master) Merge branch 'b2'
|\
| * 3b8d7a6 (b2) b2:commit3
| * 5892389 b2:commit2
| * 245fefe b2:commit1
|/
* 406f362 initial commit

    合并

    原则上可以嵌入master，但是图会变得比较复杂

    > git checkout b1
> git merge master
> git log --graph --decorate --oneline --all
*   16d4e98 (HEAD -> b1) Merge branch 'master' into b1
|\
| *   12ef823 (master) Merge branch 'b2'
| |\
| | * 3b8d7a6 (b2) b2:commit3
| | * 5892389 b2:commit2
| | * 245fefe b2:commit1
| |/
* | ccca93c b1:commit1
|/
* 406f362 initial commit

    而合并到master之后，图会变得更加复杂：

    > git checkout master
> git merge b1 --no-ff
> git log --graph --decorate --oneline --all
*   1443680 (HEAD -> master) Merge branch 'b1'
|\
| *   16d4e98 (b1) Merge branch 'master' into b1
| |\
| |/
|/|
* |   12ef823 Merge branch 'b2'
|\ \
| * | 3b8d7a6 (b2) b2:commit3
| * | 5892389 b2:commit2
| * | 245fefe b2:commit1
|/ /
| * ccca93c b1:commit1
|/
* 406f362 initial commit

    新分行

    您可以创建一个新分支并将您的提交移至那里，而不是变基

    > git checkout -b b1-1 master
> git cherry-pick ccca93c
> git log --graph --decorate --oneline --all
* ebaac4a (HEAD -> b1-1) b1:commit1
*   12ef823 (master) Merge branch 'b2'
|\
| * 3b8d7a6 (b2) b2:commit3
| * 5892389 b2:commit2
| * 245fefe b2:commit1
|/
| * ccca93c (b1) b1:commit1
|/
* 406f362 initial commit

    但这没什么意义，做一个变基更容易

    • 4

相关问题