这是一个创建于 860 天前的主题，其中的信息可能已经有所发展或是发生改变。
从 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
1. checkout dev
merge a
merge b
2. checkout dev
merge a
rebase dev
3. cherry-pick a
第 1 条附言 · 2022-07-19 23:54:27 +08:00
第二个问题： 我对同事git重命名没有管好，他批量修改了很多文件名（只修改了大小写，导致没有监测到），现在本地和远程仓库一团糟，请问有办法把远程仓库和本地仓库同步吗
 |
1
UN2758 2022-07-18 17:44:46 +08:00
我选择把底层依赖的代码 commit 做个 cherrypick
|
 |
2
silentsky 2022-07-18 17:48:19 +08:00
都行，如果仅仅想合并 a 分支中的一个 commit 就用 cherry-pick
|
 |
3
wu67 2022-07-18 17:48:35 +08:00
我习惯公用部分直推 dev, 然后其他分支,主动合并 dev 的内容过来. 最后功能开发完, 合并回 dev, 谁晚合并的谁负责解决冲突.
|
 |
4
masker 2022-07-18 17:50:47 +08:00 via Android
我都是 rebase
|
 |
5
rrfeng 2022-07-18 17:51:39 +08:00
先 merge A
然后 B rebase dev 前提是 A 可靠。 |
 |
6
yuandj 2022-07-18 17:55:28 +08:00
我一般使用 rebase ，这样做可以把代码冲突在 rebase 的过程中解决，从而 merge 到主分支时，就不会报冲突错误了。使用 rebase 可以把提交记录保持线性，路线比较清晰而且美观。
|
 |
8
Vegetable 2022-07-18 17:59:44 +08:00  1
让 A 赶紧把底层的功能合并掉，不要攒一大堆不提交，影响别人效率。义正言辞的
|
 |
9
wu00 2022-07-18 18:12:56 +08:00
拆成 A 、B 、C 、D...
A 只开发底层功能，完成后合并到 dev ； B 、C 、D...并行进行业务开发(依赖处搁置)。 B 、C 、D... 将 dev 分支中的底层依赖 pull rebase 回来，缝合-测试-提交-合并 |
|
11
yuandj 2022-07-18 18:29:25 +08:00 1
@unt #10
使用 rebase 有个原则：永远不要对已经提交到远程的分支进行 rebase ，否则已经拉过此分支的同事都会抓狂。 所以平时开发只对你本地的临时开发分支进行 rebase ，对别人来说是毫无影响，并且是无感的。他们只能感觉到你的提交永远是一条线，很干净 |
 |
12
unco020511 2022-07-18 18:29:35 +08:00
我一般是 pick
|
 |
13
darknoll 2022-07-18 18:50:53 +08:00
就 cherry-pick 得了
|
 |
14
unt OP 如果 AB 两个都完成了开发，这时候 dev merge a, dev merge b 把两个 feature 分支都合并入 dev 分支， 然后开始进行下一阶段开发，我现在是把 ab 两个分支删掉，然后重新从 dev chekout 出新分支 featureA2 ，featureB2 ，这样操作对吗，有更好的操作方式吗
|
 |
15
xboxv 2022-07-18 22:20:32 +08:00 via Android
我觉得你依赖他的那个 commit ，或者哪个 commit 中的某个 file 的修改，然后 cherrypick 过来就可以了。
所以我想不通这个方案会有什么缺点吗？ |
 |
16
DrakeXiang 2022-07-18 22:44:58 +08:00
你们都这么注意 commit 么，我感觉很少有阅读 commit 的情况，前公司还要求都用 rebase ，但是碰到过两次不知道什么情况丢失修改的情况，现公司就直接 merge ，所以这种的话如果 A 的开发基本完成了，那么我就直接在 B 上 merge A ，后面哪边先合 dev ，后合的就处理冲突之类的
|
|
17
unt OP @DrakeXiang 那不行吧，两个特性分支互相 merge
|
 |
18
nothingistrue 2022-07-19 09:48:45 +08:00 1
首先，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 。 |
|
20
yuandj 2022-09-26 14:10:32 +08:00
@andyJado 新开一个分支，是本地还是远程分支呢？在新分支 rebase 之后，新分支是 merge 到主分支，还是单独创建一个远程分支呢？
如果是本地分支，并且后续需要 merge 到主分支，结论还是和 6 楼的一样。 如果新分支会推送到远程，那么和普通新分支没什么区别，只是 rebase 的时候可能需要处理一些冲突而已 |
 |
21
andyJado 2022-09-26 15:08:26 +08:00
@yuandj
对不起我没有表达清楚 我当时没想明白的点在于, 如果已有一个的分支推到远程, 但自己还在这个分支上工作, 并 rebase 再 push, 相当于翻出公共历史的旧账堆在顶上, 强行续上自己的线性历史. 让自己永远是 commit line 中最连贯的仔. >否则已经拉过此分支的同事都会抓狂 现在想通了, 觉得这个有点搞笑, rebase 远程分支要处理无数 conflict 吧? |
|
22
yuandj 2022-09-26 17:44:10 +08:00
@andyJado 是的，如果对远程分支进行 rebase ，那么已经拉过此分支并且进行了本地 merge 的人，再次 pull 时，都需要处理一遍你在 rebase 时处理过的“合并操作”，每个人的处理方法或者逻辑可能会有所不同，那么当多人再次 push 时，可能会产生很多冲突
|
Select Language