各位大佬你们团队开发 git 是如何管理的?

2024-08-08 09:51:20 +08:00
 liuchengfeng1

最好是 10 个人以上的技术团队,你们面对 版本协作开发、版本上线顺序前后不一致、开发途中穿插需求或是解决 bug 、如何减少代码冲突等等,是怎么处理的呢?有什么比较好的 git 管理方法

目前我们是这样:

从 prod 单独拉一个 release 分支,然后 4 、5 个人在这个分支上开发,按功能区分模块,完成后让某个人合到 dev 、test

但是有个问题,开发的人一多,这样特别容易造成代码冲突

9786 次点击
所在节点    git
75 条回复
weixind
2024-08-08 09:54:58 +08:00
https://nvie.com/posts/a-successful-git-branching-model/

就这个。feature 多 rebase develop 分支。
miaotaizi
2024-08-08 10:01:39 +08:00
差不多都是这样吧
Xu3Xan89YsA7oP64
2024-08-08 10:04:52 +08:00
gitflow ,代码分支自上而下的同步得写脚本之类的自动进行
冲突在所难免,超过 500 行代码就该提交下进行冲突处理和 code review 了
liuchengfeng1
2024-08-08 10:05:17 +08:00
@miaotaizi 就是想知道还有没有最优解
iMusic
2024-08-08 10:05:19 +08:00
我是这样的,比如大家代码都合并到 develop 分支。
开发新需求我在本地创建一个新分支比如 feat
开发完后切换到 develop 分支拉取最新代码,然后切换回 feat 分支,合并 develop 代码,有冲突解决冲突
再次切换到 develop 分支,合并 feat 代码,最后推上去

develop> git co -b feat
啪啪啪写代码
feat> git co develop
develop> git pull
develop> git co feat
feat> git rebase develop
啪啪啪解决冲突,add, rebase --continue
feat> git co develop
develop> git merge feat
deveop> git push
aababc
2024-08-08 10:07:00 +08:00
服务端开发,我们就比较简单了,开发的起点是 master ,从 master 创建 feature 分支,不同的项目需求创建不同的分支,然后合并到 test 进行测试,上线的时候后把 feature 直接合并到 master 。不过这么做也有一个小问题,大家在功能测试的时候比较容易互相影响,但是总体还是可控的。
catinsides
2024-08-08 10:07:33 +08:00
如果避免不了很多人修改同一个文件同一处代码,项目结构也得调整吧,靠 git 可能无法解决
justplaymore
2024-08-08 10:11:39 +08:00
“开发的人一多,这样特别容易造成代码冲突”

这个和 git 分支策略没有太大关系,根本问题是在项目本身的结构设计是否合理,功能模块划分是否清晰,每个类的职责是否足够单一。

冲突是在分配开发任务的时候就决定了的,而不是在做分支策略的时候决定的。
如果这些任务对应的代码是不够独立清晰的,那么冲突就是必然的。
liuchengfeng1
2024-08-08 10:12:14 +08:00
@aababc 俺们也是这样
DamonLin
2024-08-08 10:14:42 +08:00
开发前多拉开发分支的代码,不要一次性提交太多代码,多人开发冲突是难以避免的,解决冲突还是要细心。
liuchengfeng1
2024-08-08 10:24:41 +08:00
@weixind 不太适合呀,就是一个项目迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.(我不会谈论任何项目的细节,只会谈论分支策略和发布管理。)
liuchengfeng1
2024-08-08 10:24:56 +08:00
@weixind 就是不太适合呀,就是一个项目里迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.(我不会谈论任何项目的细节,只会谈论分支策略和发布管理。)
liuchengfeng1
2024-08-08 10:26:16 +08:00
@DamonLin 真的是 事在人为😂
isnullstring
2024-08-08 10:27:35 +08:00
一开始老项目换 Git 时候也遇到类似问题,后面重新整理代码,拆分功能
各自管各自的,冲突也减少,即使有紧急 BUG 或者需求要上都不影响
qxhnks
2024-08-08 10:28:09 +08:00
Google 搜 trunk-based development
yanqing07
2024-08-08 10:29:38 +08:00
@liuchengfeng1 #4 都是在这基础上变,适合自己项目就好。代码冲突是无解的,所以才要将功能拆分到不同文件,用现在的话说,就是分模块。
举例,如果两个人同时要在一个页面做开发,这个页面有个入口文件(index.ts|js),他们各自写自己模块( a.ts,b.ts ),在 index.ts 引入这两个文件。基本上冲突就只在 index.ts 出现,只要没人在 index 写大段业务逻辑,可以说基本冲突为零。
weixind
2024-08-08 10:30:08 +08:00
@liuchengfeng1 #11 冲突是必然的,要想办法减小冲突的粒度。开发分支要多 rebase develop 分支,多次解决冲突,不要最后堆到一块解决。同时项目模块划分要更清晰。
miaotaizi
2024-08-08 10:30:35 +08:00
可以试试 dev 分支 更新了之后要求 各个 feature 分支将 dev 合并到自己分支内部会不会好些
qxhnks
2024-08-08 10:31:36 +08:00
xuld
2024-08-08 10:35:02 +08:00
按上线计划拆分分支,而不是一个功能一个分支,也不是一个人一个分支。假定上线计划是一周一发布,那 dev 分支放本周需要上线的内容,如果有内容需要本周开发,但不知道什么时候上线,或者你们上线计划经常变化,那建立单独 dev 分支。每个功能做完之前拉代码,做完立即提交。每个人都这样做,问题就不会太大。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1063393

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX