git 小白代码合并问题请教

[haha88]

各位大佬，请教一个 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 有重叠修改的文件，经常会发生冲突。
大家又什么合并方法推荐吗？

[superchijinpeng]

每个改动一个分支，在 dev 测试过后，直接向 master 合并

[haha88]

@superchijinpeng 如果我一周都在开发同一个功能，每天会在 dev 上 commit 一次或者多次，开发完这个功能之后 dev 上会有很多个 commit ，往 master 上合并用 git cherrypic 多个 commit id 这个命令？

[superchijinpeng]

@haha88 没必要直接提交到 dev ，提交到自己分支，合并到 dev ，在 dev 测试没问题，要上线，再把自己这个分支合并到 master

[popvlovs]

@haha88 嫌 commit 太乱的话可以用 squash 之类的命令整理一下，效果和你的 2.1 差不多

[unco020511]

一般是基于 dev 拉一个自己的 feature 分支,在 feature 分支开发测试完之后提 mr 合到 dev,到了版本发布时,把 dev 同步到 master,发布并打 tag

[baolongzhanshen]

同 git 小白但是大多数流程是先 master 切新分支

[baolongzhanshen]

@baolongzhanshen 然后在新分支完成功能开发后合并到 dev 测试，如果不想那么多 commit 的话可以 amend 或者 rebase 整合一下提交，最后合并到 master 。

[haha88]

感谢大家的建议，以前没有建个人的 feature 分支，都是在公共的 dev 上直接开发，以后用这种方式试试。

[zhuweiyou]

我司的做法是 每个人从 main 拉个人分支开发,
要上测试环境, 自己合到 dev. 所有人都随便往 dev 合( 但是不要勾选删除分支 ) ,这个分支可以一直持续往 dev 合.
直到要上线了, 再直接将个人分支合到 main

[superchijinpeng]

@zhuweiyou 是的，现在基本都这种，社区上也是

[tanranran]

@zhuweiyou #9 这种是正解

[mascteen]

建 PR 啊

[yc8332]

开发功能应该是从 master 开新分支 feature ，然后合到 dev 测试。好了直接把 feature 合并到 master 。然后合并的时候你可以选择只保留一条提交信息

[JackCh3ng]

拉自己的 feature 分支，然后直接合并到 dev ，一般 dev 到 master 不是一般开发人员合并，普通员工不用管。
你可能只是害怕碰到冲突，但其实冲突没那么容易出现，而且不是碰上大范围重构代码，冲突一般也很好解决。建议多了解了解怎么处理冲突，看懂发生冲突时 git 标记的 TAG 。

[AstroProfundis]

做任何事情都先切一个新分支，完成后尽快向来源分支（上游）合并，这样比多人 /多功能在一个分支上混合开发遇到难以处理的冲突的概率其实更小一些

[ghost024]

我们组是我版本控制代码，一共三个分支，master 分支是生产上正在跑的代码，只有我有合并和提交的权限，verify 分支是用来上线前验证的分支，test 分支是测试环境正在跑的代码分支，所有人从 verify 分支或者 master 分支拉出自己的功能分支进行开发，然后开发完成后合并到 test 进行测试，如果一切 ok ，等到需要上线前一周或者半周把代码合并到 verify ，然后打验证包进行验证，然后如果验证有问题的话，就在自己的功能分支上改，然后合并到 verify ，最后我把控所有人需要上线的功能，最后没问题上线前把 verify 分支的代码合并到 master ，最后打生产包。然后所有人把之前已经要上线的功能分支删掉，然后下次需要开发新功能就从 verify 或者 master 重新拉分支出来。这样的话代码管控不会乱，而且也很健壮。

[soupu626]

feat / dev / release / master
feat 功能分支，从 master 拉出，开发、自测连调用，自测通过以后提测合入 dev
dev 测试分支，测试通过以后合入 release ，
release 发布分支，定期发布窗口，设置冻结时间，发布预发，预发验证通过以后开始发布线上，线上跑的都是 release
master release 发布完成以后合入 master ，master 再合入 dev
hotfix 紧急问题修复，从 master 拉出，直接发布，发布完成后合入 master 和 dev

[andyJado]

姨? 没人提 rebase 呢

[haha88]

学到很多，感谢大家的干货

[jiangzhizhou]

mono repo. 不要多 branch 开发。
所有的工作都在 master 上面 rebase