3 回答
TA贡献1815条经验 获得超13个赞
我已经将其转换为健壮的脚本,并保存在我的git-extensions存储库中:
$ git-urebaselocalbr --help
Rebase all / the last committed N local branches (except for the current branch
and master) to the updated upstream head.
Usage: git-urebaselocalbr [--continue|--skip|--abort] [--branches "<branch1> ..."] [N] [-i|--interactive] [options]
TA贡献1811条经验 获得超6个赞
我相当确定没有办法自动执行此操作。请记住,“ git rebase master”还可以将您带回到需要您解决合并冲突的外壳程序中,因此,如果您要编写脚本来自动化所有这些操作,则需要考虑到这一点。
但是,您可以相当轻松地跟踪哪些分支需要更新。嗯,对于任何分支,如果分支不是最新的wrt(即仅在master之上提交),“ git rev-list branch..master”将产生输出。因此,您需要遍历除master以外的所有本地头来生成报告(nb“ git show-branch”将大致执行此操作):
git for-each-ref 'refs/heads/*' | \
while read rev type ref; do
branch=$(expr "$ref" : 'refs/heads/\(.*\)' )
revs=$(git rev-list $rev..master)
if [ -n "$revs" ]; then
echo $branch needs update
git diff --summary --shortstat -M -C -C $rev master
fi
done
因此,如果您感觉很勇敢,则可以用“ git checkout $ branch && git rebase master”之类的东西替换“ git diff”(如果已设置,则可能只是“ git pull --rebase”)。我认为您随后必须检查是否存在“ .git / rebase-apply”目录或检查未合并文件的索引(“ git ls-files -u”),以测试是否已经等待进行合并。
当然,如果没有冲突,那很容易...它会产生一些在不容易的情况下也能起作用的东西:p
这并不一定解决如果您的分支之一基于其他事物时会发生的情况……这就是为什么我提到使用“ git pull --rebase”代替,因为这会根据分支配置进行基础化,而不是盲目地掌握。尽管检测不是基于分支配置的,但是...可能最简单的方法是检出每个分支并执行“ git pull”并让分支配置处理所有事情,包括是否重新设置基础或合并?
TA贡献1848条经验 获得超10个赞
您总是可以像这样编写一线shell:
for branch in topic1 topic2 topic3;do git rebase master $branch;done
由于您希望重新定位的主题分支可能会随时间而变化,因此这是一种快捷的^ H ^ H ^ Hflexible解决方案:-)
- 3 回答
- 0 关注
- 673 浏览
添加回答
举报