Git分支依赖问题：能否仅推送b2分支而不推送其依赖的b1分支？

嘿，这个问题我之前也碰到过，答案是可以的，但得看你具体想要哪种效果——是只是不想在远程仓库里出现b1这个分支标签，还是想让b2的变更完全独立于b1的改动？下面分两种情况给你说清楚：

这种场景最直接，你完全可以直接推送b2，Git不会自动在远程创建b1分支。

执行这条命令就行：

git push origin b2

远程仓库只会生成b2这个分支，虽然b2的提交历史里包含了b1的所有变更（毕竟b2是从b1切出来的），但别人看不到你本地曾经有过b1这个分支——他们拉取b2时只会看到完整的提交历史，不会看到b1的分支名。

唯一要注意的是：如果你之后把b1也推去远程，那这些提交就会和b2的历史关联起来，这是Git的正常逻辑，毕竟它们本来就共享提交链。

如果你希望b2的修改直接基于origin/master，完全不沾b1的改动（相当于把你在b2里做的修改单独摘出来，放到master的基础上），可以用下面两种方法：

方法1：用Cherry-pick挑出你的提交 #

这种方法适合你在b2上只有少量提交的情况：

1. 先切到最新的origin/master，并创建一个新分支：

git checkout origin/master -b b2-clean

2. 找出你在b2上相对于b1的所有提交ID——可以用这条命令查看：

git log b1..b2

3. 把这些提交逐个“复制”到新分支上：

git cherry-pick <提交ID1> <提交ID2> ...

4. 最后把新分支推送到远程，覆盖原来的b2（如果之前推过b2的话）：

git push origin b2-clean:b2

方法2：用Rebase变基重写历史 #

这个方法会把b2的提交直接“移”到origin/master的最新版本之后，适合你在b2上有多个提交的情况：

1. 先确保本地master是最新的：

git checkout master
git pull origin master

2. 切回b2分支，执行变基：

git checkout b2
git rebase master

3. 如果出现冲突，手动解决冲突后，执行这条命令继续变基：

git rebase --continue

4. 最后推送变基后的b2——因为变基修改了提交历史，需要用强制推送（注意：只有这个分支只有你自己在用的时候才这么做，不然会给其他协作者带来麻烦）：

git push origin b2 --force-with-lease

⚠️ 小提醒：如果b2已经被其他同事拉取过，强制推送变基后的分支会导致他们的本地分支和远程冲突，这种情况下优先用Cherry-pick的方式更稳妥。

内容的提问来源于stack exchange，提问作者MyCoy