29 条回复 2023-12-30 12:00:30 +08:00
 | 1 w292614191 2023 年 12 月 29 日 看下了我们的，你这还好。 业务(人性)太复杂了，习惯就好。 |
 | 2 beyondstars 2023 年 12 月 29 日 如果是用 rebase 而不是 merge 的话就不会这样。 |
 | 3 yylxbiubiu 2023 年 12 月 29 日 习惯就好了，能提交上去就不错了，靠人自觉维护好代码提交是不可能的 |
 | 4 Fleey 2023 年 12 月 29 日  1  习以为常 |
 | 5 kahlkn OP @Fleey 牛逼了，你这个 merge 也太多了吧。 @fields 是的，后续强调过 尽可能 避免这种，不过很多人都习惯了。 @beyondstars 嗯嗯。 我个人习惯就是走 rebase 的，，不过 很多人都不习惯 rebase 。 @w292614191 嗯嗯，，看到过楼下的那个，，，，确实我这个不算啥了。 |
| 6 yylxbiubiu 2023 年 12 月 29 日 @kahlkn #5 有一定规模了 就搞个 ci 吧 集成到 git 里去，用程序强制规范代码提交行为 |
 | 7 kahlkn OP @fields CI 应该不能 规范 GIT 的操作吧？ 我了解的可以再 Git 中集成 代码扫描器，，如果代码扫描器 扫描的有问题，GIT 就会提交失败。 |
| 8 yylxbiubiu 2023 年 12 月 29 日 @kahlkn #7 合并前可以检测到分支是否落后，如果落后可以禁止合并，还有每次提交只允许一个 commit 这样可以保证一条直线了 跑一下流水线就可以了 |
 | 9 kingofzihua 2023 年 12 月 29 日 12 咋看出来屎山的？  |
 | 10 wweerrgtc 2023 年 12 月 29 日 1 哪里屎山了, 这么多年一直都这样 |
 | 11 xudashan 2023 年 12 月 29 日 @kingofzihua 卧槽！！！！牛逼！！ |
 | 12 Jony4Fun 2023 年 12 月 29 日 @kingofzihua 您这是整理过的山？ |
 | 13 midsolo 2023 年 12 月 29 日 1 @kingofzihua 这是在织毛衣吗 |
 | 14 xing7673 2023 年 12 月 29 日 我们项目虽然没有过，但是我看过 swift 仓库 |
 | 15 linch97 2023 年 12 月 29 日 @kingofzihua 电子织布机 |
 | 16 Liver6 2023 年 12 月 29 日 @kingofzihua #9 牛逼 |
 | 17 ethusdt 2023 年 12 月 29 日 是流行这种帖子吗？ /t/1004445 |
 | 18 ZLY201 2023 年 12 月 29 日 自从我知道 ld 会根据千行代码 bug 率和 commit 数量评估的时候我再也没用过 rebase |
 | 19 yyancy517 2023 年 12 月 29 日 @kingofzihua #9 牛逼!!! |
| 20 kahlkn OP @kingofzihua 牛逼。 一般来说 rebase 和 merge 混用，尽可能避免出现极多层的 merge 嵌套（原因的话，可以问问 AI ）。 一般 merge 我个人觉得最多 嵌套 2-3 层。 @fields 以后有机会试试。 |
| 21 kingofzihua 2023 年 12 月 29 日 @kahlkn #20 其实也并没有吧，只是并行的分支过多，分支模型就 master/dev/feat|fix-* ，gitlab 版本过低，merge 不支持 Squash |
| 22 kingofzihua 2023 年 12 月 29 日 @Jony4Fun 是的，有幸接手，亲手在屎山上拉了一坨新的 |
 | 23 xpfd 2023 年 12 月 29 日 这是用啥软件看的？ |
 | 24 tyrone2333 2023 年 12 月 29 日 @kingofzihua 什么赛博织布机 |
 | 26 Maboroshii 2023 年 12 月 29 日 @xpfd git log --graph 也可以 |
 | 27 memorycancel 2023 年 12 月 29 日 哦！牛逼！你们都不用 rebase 的吗？ |
 | 28 maleclub 2023 年 12 月 29 日 via Android @kingofzihua 我滴妈！！！ |
Select Language