屎山+++

[kahlkn]

屎山+++

[w292614191]

看下了我们的，你这还好。

业务(人性)太复杂了，习惯就好。

[beyondstars]

如果是用 rebase 而不是 merge 的话就不会这样。

[fields]

习惯就好了，能提交上去就不错了，靠人自觉维护好代码提交是不可能的

[Fleey]

习以为常

[kahlkn]

@Fleey 牛逼了，你这个 merge 也太多了吧。


@fields 是的，后续强调过 尽可能 避免这种，不过很多人都习惯了。


@beyondstars 嗯嗯。 我个人习惯就是走 rebase 的，，不过 很多人都不习惯 rebase 。


@w292614191 嗯嗯，，看到过楼下的那个，，，，确实我这个不算啥了。

[fields]

@kahlkn #5 有一定规模了 就搞个 ci 吧 集成到 git 里去，用程序强制规范代码提交行为

[kahlkn]

@fields CI 应该不能 规范 GIT 的操作吧？ 我了解的可以再 Git 中集成 代码扫描器，，如果代码扫描器 扫描的有问题，GIT 就会提交失败。

[fields]

@kahlkn #7 合并前可以检测到分支是否落后，如果落后可以禁止合并，还有每次提交只允许一个 commit 这样可以保证一条直线了 跑一下流水线就可以了

[kingofzihua]

咋看出来屎山的？

[wweerrgtc]

哪里屎山了, 这么多年一直都这样

[xudashan]

@kingofzihua 卧槽！！！！牛逼！！

[Jony4Fun]

@kingofzihua 您这是整理过的山？

[midsolo]

@kingofzihua 这是在织毛衣吗

[xing7673]

我们项目虽然没有过，但是我看过 swift 仓库

[linch97]

@kingofzihua 电子织布机

[LucasChang]

@kingofzihua #9 牛逼

[ethusdt]

是流行这种帖子吗？ /t/1004445

[ZLY201]

自从我知道 ld 会根据千行代码 bug 率和 commit 数量评估的时候我再也没用过 rebase

[yyancy517]

@kingofzihua #9 牛逼!!!

[kahlkn]

@kingofzihua 牛逼。 一般来说 rebase 和 merge 混用，尽可能避免出现极多层的 merge 嵌套（原因的话，可以问问 AI ）。 一般 merge 我个人觉得最多 嵌套 2-3 层。

@fields 以后有机会试试。

[kingofzihua]

@kahlkn #20 其实也并没有吧，只是并行的分支过多，分支模型就 master/dev/feat|fix-* ，gitlab 版本过低，merge 不支持 Squash

[kingofzihua]

@Jony4Fun 是的，有幸接手，亲手在屎山上拉了一坨新的

[xpfd]

这是用啥软件看的？

[tyrone2333]

@kingofzihua 什么赛博织布机😄

[imyip]

@xpfd sourcetree

[Maboroshii]

@xpfd git log --graph 也可以

[memorycancel]

哦！牛逼！你们都不用 rebase 的吗？

[maleclub]

@kingofzihua 我滴妈！！！

[kentons]

@ZLY201 还可以这么玩吗，很多公司为了分支合并不乱采用 rebase ，原来是为了统计