这是一个创建于 759 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位大佬，请教一个 git 合并问题？
现有分支两个，dev 对应开发测试环境、master 对应线上环境。
4 人的 java 小组，如果我在 dev 上完成了一个模块的开发，测试验证没问题后，怎么省事一点合并到 master 上？
我用了两种合并方式，感觉都不是很方便：
1.手动复制这次改动的代码到 master 上对应的 java 类，然后 commit （合并到 master 会复制很多）
2.用 git cherry-pick 把涉及到的 commit 挪过来（我想怎么把 dev 上多次的 commit 压缩成一个）
2.1 本地建个临时分支，在临时分支上将多个模块 A 的 commit 压缩成 1 个
git checkout -b <new_branch_name> <commid_id>
git checkout -b testdev 107b726 （模块 A 的最后一次的 commit ）
git rebase -i HEAD~一个数
然后得到一个压缩后的 commit_id
2.2 在 master 上执行
git cherry-pick 03ef1d5 临时分支上的 commit_id
第 2 种方式用了之后，如果前一个 commit 和之后的 commit 有重叠修改的文件，经常会发生冲突。
大家又什么合并方法推荐吗？
现有分支两个，dev 对应开发测试环境、master 对应线上环境。
4 人的 java 小组，如果我在 dev 上完成了一个模块的开发，测试验证没问题后，怎么省事一点合并到 master 上？
我用了两种合并方式，感觉都不是很方便：
1.手动复制这次改动的代码到 master 上对应的 java 类，然后 commit （合并到 master 会复制很多）
2.用 git cherry-pick 把涉及到的 commit 挪过来（我想怎么把 dev 上多次的 commit 压缩成一个）
2.1 本地建个临时分支，在临时分支上将多个模块 A 的 commit 压缩成 1 个
git checkout -b <new_branch_name> <commid_id>
git checkout -b testdev 107b726 （模块 A 的最后一次的 commit ）
git rebase -i HEAD~一个数
然后得到一个压缩后的 commit_id
2.2 在 master 上执行
git cherry-pick 03ef1d5 临时分支上的 commit_id
第 2 种方式用了之后，如果前一个 commit 和之后的 commit 有重叠修改的文件，经常会发生冲突。
大家又什么合并方法推荐吗？
 |
1
superchijinpeng 2022-10-11 15:18:50 +08:00
每个改动一个分支，在 dev 测试过后，直接向 master 合并
|
 |
2
haha88 OP @superchijinpeng 如果我一周都在开发同一个功能，每天会在 dev 上 commit 一次或者多次，开发完这个功能之后 dev 上会有很多个 commit ，往 master 上合并用 git cherrypic 多个 commit id 这个命令？
|
|
3
superchijinpeng 2022-10-11 15:31:48 +08:00  1
@haha88 没必要直接提交到 dev ，提交到自己分支，合并到 dev ，在 dev 测试没问题，要上线，再把自己这个分支合并到 master
|
 |
5
unco020511 2022-10-11 15:58:16 +08:00
一般是基于 dev 拉一个自己的 feature 分支,在 feature 分支开发测试完之后提 mr 合到 dev,到了版本发布时,把 dev 同步到 master,发布并打 tag
|
 |
6
baolongzhanshen 2022-10-11 15:59:28 +08:00
同 git 小白但是大多数流程是先 master 切新分支
|
|
7
baolongzhanshen 2022-10-11 16:01:26 +08:00
@baolongzhanshen 然后在新分支完成功能开发后合并到 dev 测试，如果不想那么多 commit 的话可以 amend 或者 rebase 整合一下提交，最后合并到 master 。
|
|
8
haha88 OP 感谢大家的建议，以前没有建个人的 feature 分支，都是在公共的 dev 上直接开发，以后用这种方式试试。
|
 |
9
zhuweiyou 2022-10-11 17:07:30 +08:00 1
我司的做法是 每个人从 main 拉个人分支开发,
要上测试环境, 自己合到 dev. 所有人都随便往 dev 合( 但是不要勾选删除分支 ) ,这个分支可以一直持续往 dev 合. 直到要上线了, 再直接将个人分支合到 main |
|
10
superchijinpeng 2022-10-11 17:09:52 +08:00
@zhuweiyou 是的，现在基本都这种，社区上也是
|
 |
12
mascteen 2022-10-11 17:43:49 +08:00 via Android
建 PR 啊
|
 |
13
yc8332 2022-10-11 17:46:41 +08:00
开发功能应该是从 master 开新分支 feature ，然后合到 dev 测试。好了直接把 feature 合并到 master 。然后合并的时候你可以选择只保留一条提交信息
|
 |
14
JackCh3ng 2022-10-11 18:07:08 +08:00
拉自己的 feature 分支，然后直接合并到 dev ，一般 dev 到 master 不是一般开发人员合并，普通员工不用管。
你可能只是害怕碰到冲突，但其实冲突没那么容易出现，而且不是碰上大范围重构代码，冲突一般也很好解决。建议多了解了解怎么处理冲突，看懂发生冲突时 git 标记的 TAG 。 |
 |
15
AstroProfundis 2022-10-11 18:33:08 +08:00
做任何事情都先切一个新分支，完成后尽快向来源分支（上游）合并，这样比多人 /多功能在一个分支上混合开发遇到难以处理的冲突的概率其实更小一些
|
 |
16
ghost024 2022-10-11 18:54:43 +08:00
我们组是我版本控制代码，一共三个分支，master 分支是生产上正在跑的代码，只有我有合并和提交的权限，verify 分支是用来上线前验证的分支，test 分支是测试环境正在跑的代码分支，所有人从 verify 分支或者 master 分支拉出自己的功能分支进行开发，然后开发完成后合并到 test 进行测试，如果一切 ok ，等到需要上线前一周或者半周把代码合并到 verify ，然后打验证包进行验证，然后如果验证有问题的话，就在自己的功能分支上改，然后合并到 verify ，最后我把控所有人需要上线的功能，最后没问题上线前把 verify 分支的代码合并到 master ，最后打生产包。然后所有人把之前已经要上线的功能分支删掉，然后下次需要开发新功能就从 verify 或者 master 重新拉分支出来。这样的话代码管控不会乱，而且也很健壮。
|
 |
17
soupu626 2022-10-11 19:05:22 +08:00 4
feat / dev / release / master
feat 功能分支，从 master 拉出，开发、自测连调用，自测通过以后提测合入 dev dev 测试分支，测试通过以后合入 release ， release 发布分支，定期发布窗口，设置冻结时间，发布预发，预发验证通过以后开始发布线上，线上跑的都是 release master release 发布完成以后合入 master ，master 再合入 dev hotfix 紧急问题修复，从 master 拉出，直接发布，发布完成后合入 master 和 dev |
 |
18
andyJado 2022-10-11 19:18:30 +08:00
姨? 没人提 rebase 呢
|
|
19
haha88 OP 学到很多，感谢大家的干货
|
 |
20
jiangzhizhou 2022-10-11 22:28:04 +08:00
mono repo. 不要多 branch 开发。
所有的工作都在 master 上面 rebase |
 |
21
weyou 2022-10-11 22:36:42 +08:00 1
@zhuweiyou 这种做法，dev 分支岂不是会被整的很乱， 而且很可能和 main 不一致， 测试环境都不一致， 测试的结果还可信么？
|
 |
22
yeqizhang 2022-10-11 22:45:12 +08:00 via Android
git merge 没用直接跳到 git cherry-pick 了？🐶
1 那种手动搬代码的想法简直就离谱，相同的内容在不同分支上两个提交点 |
|
23
yeqizhang 2022-10-11 22:48:56 +08:00 via Android
@weyou 他这个一看就很有问题，完了要上线大家再往 master 合并又要解决冲突之类的吗，搞出问题了也不知道……17 楼 soupu626 的这个流程才对
|
 |
24
CEBBCAT 2022-10-12 00:39:39 +08:00
我是用的 2 的方式，但有一些细微不同，我是直接全部 cp 到 master ，然后 rebase 合并的。
> 第 2 种方式用了之后，如果前一个 commit 和之后的 commit 有重叠修改的文件，经常会发生冲突。 你仔细看一下 git log ，用树形视图。自己写的代码之间一般是不会有冲突的。除非你这些 commit 不是一脉相承的，或者你这些 commit 所涉及到的文件，别人也有改动。 |
 |
25
simonlu9 2022-10-12 10:32:51 +08:00
目前团队采用这种方式，我觉得适合大部分小团队，而且用了一段时间，非常好用
https://github.com/xiaolyuh/mrtf-git-flow-4idea |
 |
26
seth19960929 2022-10-12 10:35:12 +08:00
@yeqizhang 17L 是标准的 gitflow, 是很好的标准, 但是很多人没用, 原因之一就是太复杂了.
试过用 sourcetree 自带的 gitflow 图形化操作, 很不错就是太慢了. 实际上我还是喜欢简单的 master, dev, feature 就差不多. 每次从 master 拉出 feature, 开发中不断提交到远程, 测试合并到 dev, 测试完成把 feature 合并到 master, 删除分支. 此次功能完成. 冲突这个问题什么工作流都解决不了的, 而是写代码的人去处理. |
 |
27
waterlaw 2022-10-12 12:29:40 +08:00 via Android
参考下我的 https://www.waterlaw.top/articles/57
上线时从 master 拉出一个 release 分支，merge 你的 dev 分支，上线后再把 release 同步回 master (即从 master 拉出分支 merge release, 后合并) |
|
28
waterlaw 2022-10-12 12:30:26 +08:00 via Android
这里的 dev 分支是你这边的，我那博客叫 feat 分支
|
 |
29
SoloCompany 2022-10-12 20:11:45 +08:00 via iPhone
不需要历史的话就用 merge —squash
|
|
30
yeqizhang 2022-10-13 00:13:07 +08:00 via Android
@seth19960929 合并到 dev 解决的冲突，然后测试通过了，再合并到 master 又有冲突了，那这次冲突又没经过测试，这样能行吗
|
|
31
seth19960929 2022-10-13 13:54:29 +08:00
@yeqizhang of course, 只要确保你的每一次提交的代码测试过. 冲突和测试没有关联关系.
|
Select Language