git 有两个分支 a、a->b， a 有更新以后用什么语句更新到 b？

git checkout a & git pull & git checkout b & git rebase a

线上分支不应该直接在上面更新代码吧

看看 git flow 流程， A 分支有 bug 应该新开一个 /hotfix 分支，修改上线后合并到 B 的 feature 分支

@markowitz73 你是不是看错需求了？

@orvice 啥意思？

@zioc 我觉得我写的满足了你的需求。

似乎只能使用 rebase 了

merge/rebase 有问题吗？ 一楼的说的应该没问题吧

切到 b 然后 rebase a

这种开发模式是非常典型可以用 Git 最佳实践的。请参考： http://jiongks.name/blog/a-successful-git-branching-model/

一楼可行，不想切分支的话可以这么搞，效果相同： 在 b 上 git pull --rebase origin a

一种做法是走 rebase
git checkout b
git rebase a

我觉得更好的做法是每一个 BUG 都从 a 拉出一个分支，这个分支开发完后同时 merge 到 a 和 b

@otakustay
@markowitz73
@ivyshark
先谢谢回复

rebase 或 merge 会删除分支吗？ 我的需求是 a 、 b 分支都不能消失

cherry-pick 看是不是你想要的

如果不是“同步”分支，建议 cherry-pick

@zioc 不会，分支只有你手动才删得掉，其它任何操作都不会删除分支

难道 不是 git checkout a -> git merge b 吗?

cherry-pick
cherry-pick
cherry-pick

少量提交可以用 cherry-pick
多一点的提交，看看能不能用 rebase

如果能 merge --ff-only, 也可以这样

建议楼主先熟悉一下 git 基础和 git-flow ，
楼上说的 rebase/merge/cherry-pick 都可以，
用哪种方法完全取决去个人爱好,
洁癖用 rebase
强迫症用 merge
爱折腾用 cherry-pick

在 b 上 merge a 就可以了啊，没有什么必要 rebase 。
cherry pick 会产生很多新的 commit ，更没有必要了。

@NemoAlex 用 b rebase a 就可以了啊，没有什么必要 merge 。

rebase 被玩坏了

建议用 merge

rebase 可能会导致 non-fastforward
cherry-pick 少量 commit 没问题，多了累

没有争议的问题 为啥还讨论这么激烈 蛋疼

git rebase -i <branch> 是正确的用法

On branch B

1. branch_b clean
git merge branch_a

2. branch_b can not merge before commit
git stash
git merge branch_a
* may need fix confilct then
git stash pop

遇到不可合并的二进制文件,需要重新 git checkout file