【问题标题】:git rebase as close to HEAD as possible?git rebase 尽可能接近 HEAD?
【发布时间】:2016-03-08 12:35:03
【问题描述】:

我在 git 中有一个私人分支,我已经有一段时间没有碰过它了。我想在master 之上重新定义它,所以我:

git checkout master
git pull

git checkout my-branch
git rebase master

First, rewinding head to replay your work on top of it...
Applying: a bunch of stuff
Applying: more stuff
Applying: and so on
CONFLICT (content): Merge conflict in src/foo.c
error: Failed to merge in the changes.

哦不,我不能直接变基到HEAD

git rebase --abort  # sigh

此时我通常会尝试使用git rebase SHA1git rebase SHA2(其中 SHA1SHA2 等在 master),直到我找到它成功变基的最近点。

我挑选候选rebase点的常用技巧是在每次合并到master之后立即尝试。

有没有好办法让这个过程自动化?

【问题讨论】:

  • 基于 SHA1/2 的 rebase 有什么好处?您最终将不得不基于 master 进行 rebase,并且您将遇到相同的冲突。
  • 解决冲突和git rebase --continue
  • 如果变基中有个成功的合并,它们会被应用,并且我在分支上的提交(和潜在的冲突)更少。

标签: git rebase


【解决方案1】:

我不相信 Git 具有您正在寻找的开箱即用的东西。

但是,您可以使用脚本和 Git 别名来创建一种“模糊变基”命令。这将尝试针对另一个 ref 进行 rebase,如果失败,它将沿着它的后代树向上走,直到找到可以干净地 rebase 的 ref。

这是一个 perl 脚本:

#!/usr/bin/perl -w

# get ref
my $ref=shift @ARGV;
if (!defined $ref) {
    warn "need ref to rebase against!\n";
    exit 1;
}

# attempt rebase
`git rebase $ref 2>&1`;

# detect if conflict occurred
# if so, abort the rebase
# and try again with the rebase target's parent
my @result = `git ls-files --unmerged`;
if (scalar @result > 0) {
    print "failed at $ref\n";
    `git rebase --abort 2>&1`;
    system("$0 $ref~");
} else {
    print "done at $ref\n";
}

假设您在~/scripts/fuzzyRebase.pl 有这个。像这样定义一个 Git 别名:

git config --global alias.fuzzyRebase !/~/scripts/fuzzyRebase.pl

现在,无论何时你想调用你的模糊变基,你都可以使用:

git fuzzyRebase master

【讨论】:

  • 我会试一试,但实际上考虑一下,面对合并到主控,这会变得复杂,因为“主控”在向后走并击中时没有什么特别的合并。嗯...
  • @RogerLipscombe 同意...我认为这里的重点是您正在寻找的内容需要一些脚本,并且脚本可能会因合并​​提交等各种边缘情况而变得复杂
  • 这里注意一下,你不必git ls-files --unmergedgit rebase的退出状态为0表示成功,1(一般非零,但当前实际为1)表示冲突。
猜你喜欢
  • 1970-01-01
  • 2014-06-06
  • 2021-10-28
  • 2022-06-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多