第二个问题: 我对同事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 时,可能会产生很多冲突
|