请教 1 个 git 合并的常见问题

[unt]

从 dev 分出来的两个 feature 分支 A 和 B 。A 开发了一些底层一点的功能，B 开发过程中用得到。B 这时候如何处理呢。
1. checkout dev
merge a
merge b
2. checkout dev
merge a
rebase dev
3. cherry-pick a

第二个问题： 我对同事git重命名没有管好，他批量修改了很多文件名（只修改了大小写，导致没有监测到），现在本地和远程仓库一团糟，请问有办法把远程仓库和本地仓库同步吗

[UN2758]

我选择把底层依赖的代码 commit 做个 cherrypick

[silentsky]

都行，如果仅仅想合并 a 分支中的一个 commit 就用 cherry-pick

[wu67]

我习惯公用部分直推 dev, 然后其他分支,主动合并 dev 的内容过来. 最后功能开发完, 合并回 dev, 谁晚合并的谁负责解决冲突.

[masker]

我都是 rebase

[rrfeng]

先 merge A
然后 B rebase dev

前提是 A 可靠。

[yuandj]

我一般使用 rebase ，这样做可以把代码冲突在 rebase 的过程中解决，从而 merge 到主分支时，就不会报冲突错误了。使用 rebase 可以把提交记录保持线性，路线比较清晰而且美观。

[morty0]

@UN2758 +1

[Vegetable]

让 A 赶紧把底层的功能合并掉，不要攒一大堆不提交，影响别人效率。义正言辞的

[wu00]

拆成 A 、B 、C 、D...
A 只开发底层功能，完成后合并到 dev ； B 、C 、D...并行进行业务开发(依赖处搁置)。
B 、C 、D... 将 dev 分支中的底层依赖 pull rebase 回来，缝合-测试-提交-合并

[unt]

@yuandj #6 现实情况好像是有些公司禁止 rebase,有些公司提倡 rebase

[yuandj]

@unt #10
使用 rebase 有个原则：永远不要对已经提交到远程的分支进行 rebase ，否则已经拉过此分支的同事都会抓狂。
所以平时开发只对你本地的临时开发分支进行 rebase ，对别人来说是毫无影响，并且是无感的。他们只能感觉到你的提交永远是一条线，很干净

[unco020511]

我一般是 pick

[darknoll]

就 cherry-pick 得了

[unt]

如果 AB 两个都完成了开发，这时候 dev merge a, dev merge b 把两个 feature 分支都合并入 dev 分支， 然后开始进行下一阶段开发，我现在是把 ab 两个分支删掉，然后重新从 dev chekout 出新分支 featureA2 ，featureB2 ，这样操作对吗，有更好的操作方式吗

[xboxv]

我觉得你依赖他的那个 commit ，或者哪个 commit 中的某个 file 的修改，然后 cherrypick 过来就可以了。
所以我想不通这个方案会有什么缺点吗？

[DrakeXiang]

你们都这么注意 commit 么，我感觉很少有阅读 commit 的情况，前公司还要求都用 rebase ，但是碰到过两次不知道什么情况丢失修改的情况，现公司就直接 merge ，所以这种的话如果 A 的开发基本完成了，那么我就直接在 B 上 merge A ，后面哪边先合 dev ，后合的就处理冲突之类的

[unt]

@DrakeXiang 那不行吧，两个特性分支互相 merge

[nothingistrue]

首先，a 和 b 都是临时特性分支，他们在合并的时候无需区别对待。所以下面的步骤只列出 a ，b 的操作步骤是一摸一样的，a b 的顺序也没有要求。

非线性历史，传统合并方式：
checkout dev
merge a
如果有冲突，以新提交的方式解决冲突；但是如果 dev 分支是受保护分支，就要在额外的临时分支中解决冲突，然后再合并临时分支。

准线性历史，变基合并方式：
1 、checkout a
2 、rebase dev
3 、如果有冲突，在 a 上解决冲突
4 、checkout dev
5 、merge a
6 、此时如果有冲突，反转第 5 步（通过 reset --hard 方式），然后回到第 1 步继续

此外还有完全线性历史的压缩合并方式，但是这个基本不会用到。

以上合并方式，虽然步骤很多，但是如果在界面操作 Pull Request 或 Merte Request ，就很简单了。


不建议 cherry-pick 方式，因为你的 dev 、a 、b 是有共同祖先的的，没必要用 cherry-pick 。

[andyJado]

@yuandj

如果新开一个 branch 然后在新开的这个 branch 上 rebase 呢

[yuandj]

@andyJado 新开一个分支，是本地还是远程分支呢？在新分支 rebase 之后，新分支是 merge 到主分支，还是单独创建一个远程分支呢？
如果是本地分支，并且后续需要 merge 到主分支，结论还是和 6 楼的一样。
如果新分支会推送到远程，那么和普通新分支没什么区别，只是 rebase 的时候可能需要处理一些冲突而已

[andyJado]

@yuandj

对不起我没有表达清楚

我当时没想明白的点在于, 如果已有一个的分支推到远程, 但自己还在这个分支上工作, 并 rebase 再 push, 相当于翻出公共历史的旧账堆在顶上, 强行续上自己的线性历史. 让自己永远是 commit line 中最连贯的仔.

>否则已经拉过此分支的同事都会抓狂

现在想通了, 觉得这个有点搞笑, rebase 远程分支要处理无数 conflict 吧?

[yuandj]

@andyJado 是的，如果对远程分支进行 rebase ，那么已经拉过此分支并且进行了本地 merge 的人，再次 pull 时，都需要处理一遍你在 rebase 时处理过的“合并操作”，每个人的处理方法或者逻辑可能会有所不同，那么当多人再次 push 时，可能会产生很多冲突