 |
101
crysislinux Mar 6, 2025 via Android
merge master 到 feature 也没啥，最后 merge feature 回去的时候只用 squash merge 就好了。像 github 这些先 merge master 到 feature 算是常规操作了。
|
 |
102
veightz Mar 6, 2025
我一般的操作是：
1. master rebase 到 feature ， 在 feature 中做冲突处理，不变更 master 。 2. feature merge 到 master ，铁不冲突。 |
 |
103
Kevin2 Mar 6, 2025 via Android
之前在某 杭州中厂外包，要合并代码到生产分支前要提交 merge request 。冲突了要求用第二种方式。。。
|
 |
104
wyntalgeer Mar 6, 2025
@sir283 叫你 leader 下午去趟财务室
 |
 |
105
k2sy Mar 6, 2025  1
首先前提是 master 是当做《发布前预发布分支》用还是《发布后归档分支》用？
不能直接合给 feature 的唯一风险就是其他已经合入 master 的 feature 不上了……一合的话不就污染了么。 方案 1 是把 master 同时当做这两者在用了。 方案 2 看上去是打算把 master1 当做发布前预发布分支用，意味着可能有不同人的不同 feature 分支都在此汇聚解决冲突。同时也可以不影响 master 归档分支。如果万一发布前有哪个需求不上了，也可以重新拉个 master2 来合。待发布完成尘埃落定后合入 master 。 |
 |
106
wnpllrzodiac Mar 6, 2025
feature 直接 merge 到 master 啊。开个 master_1 干啥。
有 PR 不就行了。PR code review ，jenkins automation 过了就能合并。 master_1 多次一举。 感觉是怕把 master 搞坏，才要开个 master_1, 流程完善，不可能有问题的。 |
 |
107
accelerator1 Mar 6, 2025
首先要看怎么理解你说的“合入”。
如果是 merge 操作，无论哪种都是极其危险的操作，因为会破坏原有分支的 commit 顺序，想要把合入了 feat 功能分支合入 master ，只能是 push -f 了，这是不现实的，正常这些分支都会有保护，不允许这么做。 如果是 rebase 分支，那其实没啥区别了，唯一的区别应该就是楼上说的，保持 feat 分支的独立性，这感觉在实际开发中不存在，不太可能你负责的功能跟别的模块没有任何数据交互，你迟早要 rebase 到最新的 master 分支。 |
 |
108
exiledkingcc Mar 6, 2025
1. 先在 master 分支上 pull remote
2. 然后在 feature 分支上 rebase master ，解决冲突 3. 把 feature 分支 merge 到 master 4. 在 master 分支上 push remote 如果是多人合作，那么最好有一个 maintainer 来干这个事。然后： developer： 1. 更新 master 2. 然后在 feature 分支上 rebase master ，解决冲突 3. feature 分支推送到 remote maintainer： 1. 更新 master 2. 拉取 remote 的 feature 分支到本地 3. 合并 feature 到 master 4. 推送 master 分支到 remote |
 |
109
acerphoenix Mar 6, 2025
正常上线都会有个 release 分支, master 切出来的, 把 release 分支合到 feature 解决冲突再合回去就行.
如果没有 release, 犯不着 master 再搞个 master_1. |
 |
110
callv Mar 6, 2025
最舒服的做法：
在 feature 分支执行 git rebase master 有冲突就解决冲突，解决冲突之后 git push --force-with-lease origin feature ，推上去之后再新建一个 Pull Request ，将 feature 合并到 master ，这时候就可以合并了。 |
 |
111
skiy Mar 6, 2025
方案二是基操吧？
反正我基本是方式二。 如果从 master 合入你的分支，不就相当于以你作为主分支吗？ |
 |
112
Bingchunmoli Mar 6, 2025 via Android
@sfz97308 有个问题，如果是 feature rebase master 相当于 master 的提交在 feature 重放，如果 featue 去合并 master 会出现文件内容一样但是提示冲突的问题，是我操作不对吗
|
 |
113
rammiah Mar 6, 2025
rebase +1
|
 |
114
wangyingbo Mar 6, 2025
当我刚入行时，也经常使用 merge 合并分支，并且排斥其他的分支合并方式，不过敲了十年代码以后，踩得坑多了以后，我觉得现在我的提交流程是最正确且最合理的。
给你说一下我一般的操作流程： 基于 feature 分值创建 feature_0305 分支， 在 feature_0305 分支上执行 git rebase master ， 执行完 rebase 后，feature_0305 分支最前面的几次提交应该都是你自己的提交，再执行 git rebase -i commit_hash ，把你自己的提交压缩成一个 commit_new ， 这样分支 feature_0305 的 HEAD 就只指向了一个 commit_new ，这个时候再切回 master 分支，使用 git cherry-picker 把 commit_new 这一个提交遴选到 master 分支。 这样的好处是 master 分支的每一个 commit 都是一个 owner 对应的功能代码，不会出现使用 merge 时那种情况，一个人进个需求代码，master 分支多了几十个 commit ，且时间线还是乱的。 总结：推荐熟练使用 rebase ，不要使用 merge 。 |
 |
115
35aZ4P8mT576683q Mar 7, 2025
我觉得都没问题
leader 让搞一个单独的 master_1 可能是把 feature 分支当成 backup 分支来看待了 这种情况 leader 没有方向性的错误，就当成他的个人喜好吧 这种冲突是别的分支先合进 master 了吧, 每天早上 rebase 可以减少这种问题出现的概率 |
 |
116
dingyaguang117 Mar 7, 2025 via iPhone
好奇大家为什么都用 rebase ， 如果使用 git flow 这种开发方式，大家都往 develop 分支合，rebase 会引入无穷无尽的问题
|
 |
117
rich1e Mar 7, 2025
代码合并分两种形式：非/同源。
同源合并，建议使用 git rebase ，可以保证代码历史呈线性增长，容易溯本逐源。举个例子，feat 向 dev 合并时，使用 git rebase ，如果出现冲突，在本地解决后再重新推送合并请求。 非同源合并，即跨分支合并。建议使用 git merge ，减少代码冲突，使用 git rebase 会出现无穷无尽的 confict 。举个例子，dev 向 master 合并时，使用 git merge ，如果出现冲突，优先使用 dev ，强制覆盖 master ，顺带加上 squash ，清理开发 commit 。 以上希望对你有帮助 |
 |
118
X0V0X Mar 7, 2025
没有测试分支吗，如果习惯了第一种，直接把 test 合入 feature 那就 gg 了
|
 |
119
sfz97308 Mar 7, 2025
@Bingchunmoli "相当于 master 的提交在 feature 重放"这个理解是有问题的，可以理解为相当于你重新从最新的 master 拉出了新的分支，并把你在 feature 分支里的 commits 放进去，应该是你的操作有问题。
可以看下： https://git-scm.com/book/en/v2/Git-Branching-Rebasing |
 |
120
sngxx OP @gzyguy 我们会用 feature 在测试阶段、uat 阶段分别 merge 到 test 和 uat 。
假如已经合入过一次 test 分支了，然后 master 分支有更新，在 feature rebase master 。这时候再去 merge 到 test 会出现改动内容一样但提示冲突吧？ 应该是因为 rebase master 之后 commit id 都变了，跟之前 merge 到 test 的 commit id 不同了。 还是说合 test 也不用 merge 方式了？ |
 |
121
nenseso Mar 8, 2025
我们是每个人的 feature 合到版本 develop 提测，测过了没问题提上线申请走流程审批，再由有权限的合 master
|
Select Language