讨论多人开发协作的时候,你们的 git 都用的怎样的分支模型?

greatghoul110阅读23评论2 个月前

如题。

讨论话题:
技术讨论
加载中…
精选评论
2 个月前夏芸

我习惯的是,基于master去创建一个带版本号的分支,开发测试完成后提交cr,最后合并到master上去。

最近接触到的是,开发过程中有个devlop分支,每个人创建自己的分支,最后发起pr合并到develop上去。 说实话,不太适应。

2 个月前greatghoul

我们最近也是 master , develop 这种模型,用起来也觉得挺繁琐的。

2 个月前波派

两个分支还闲繁琐啊?哈哈

2 个月前ElmerZhang

上上家公司用的 master + feature/bugfix branch 模型,用起来很舒服。

上家公司用的 master + develop + feature/bugfix branch 模型,但是合并流程管理并不严格,经常出现紧急的 bugfix 合并到了 master 却忘了合并 develop 的情况, master 的代码也很少向 develop merge,结果就是偶尔会因为这个出 BUG。

两种模型各有优劣,我的感觉是:第一种适合频繁迭代,每次发布只发一个 feature 的项目,比如多数后端项目或者 Web 项目;第二种适合定期发版,一次发布多个 feature 的项目,比如 Android 和 iOS 项目。

2 个月前greatghoul

感觉 master + featue/bugfix 这种很简洁,不过对于有些 feature 如果在上生产环境前想在一个测试环境上跑一下,只有个 master 感觉比较难处理呢。

2 个月前ElmerZhang

并不难啊,我来细讲一下之前我们 master + feature/bugfix branch 的开发和部署流程:

整个流程中有四个环境:

1. 开发环境,可以是你本地或者某个专用开发环境;

2. 测试环境,一般用于新功能测试,可以有多套;

3. 预发布环境,仅有一套,上线前最后的回归测试;

4. 生产环境。

下面开始讲流程:

1. 开始开发: 从 master 创建一个 branch 出来;

2. 开发完成准备测试: 将 master merge 到 branch,以防止你开发过程中 master 合入的新代码和你的 branch 有代码或者业务逻辑上的冲突;

3. 将 branch 部署到测试环境进行测试;

4. 测试完成后,再次将 master merge 到 branch,然后马上部署到 预发布环境进行回归测试,并将预发布环境锁定,禁止其他 branch 部署;

5. 预发布测试完成后将 branch 部署到生产环境,部署完成确认没问题后,将 branch 合并到 master,释放预发布环境。如果在生产环境发现了问题,马上将生产环境回滚到 master,然后根据具体情况来决定是在预发布环境修复、测试后重新上线,还是释放预发布环境回测试环境去测试、修复。

上上家公司时,几百人的技术团队都是照这个流程来走的;小公司或者创业团队规模比较小的时候,可以适当精简一下流程。

2 个月前greatghoul

感谢,解释的这么详细。👍

有的公司对 git tree 也有洁癖,会要求尽量使用 rebase,不过我个人两种都能接受,只有有效就可以了。

2 个月前ElmerZhang

要求 git tree 整齐的话,最后 merge master 的时候把整个 branch 合并为一个 commit 就可以了。master 本身也并没有必要保留 branch 中的每一个 commit。

2 个月前波派

我之前参加的团队,怎么操作的都有。这方面我比较随性,能适应团队需求就行。举2个例子:

例子1

master/beta/dev

1. 开发用dev分支开发,维护最新的代码

2. beta用来做内部演示环境,给测试的版本也会在这个branch上打tag

3. master是线上环境

例子2 extends 例子1

master/beta/dev

1. 开发每个story从dev上拉一个分支,然后提PR merge到dev上。这个流程相对正规点,但也麻烦点。好处是能根据每个story的所有改动。原来我们用gitlab的时候,自己写了小工具,能提高点效果。

这东西你会发现每个团队一个玩法,可能和大家的研发流程不完全一样有一定关系吧。

2 个月前波派

另外,我刚才一伙兄弟喜欢用merge。说是能看到谁合了代码,merge也有会多问题。如:在merge的那个commit时,看不到是具体哪个commit改的代码。还有log tree会非常乱。

另一伙人,喜欢用rebase。这样会维护一条非常漂亮的log tree,方便维护。我个人比较喜欢这种。

2 个月前阡陌

我们是master+dev,2个分支。master上就是线上版本,dev是开发版本。dev开发环境测完,合并到master,发布到集成测试环境测试,完了才打tag,发到正式环境。

我极力要求团队里用rebase,merge commitlog会重复,历史树太难看了。个人开发,rebase同步dev,切一个本地分支去开发。这个流程和参与开源项目的流程大体差不多,少了一个fork的步骤。

如果线上有bug,从master切出一个hotfix分支,修复bug,单独测试并发布到正式环境。然后再把hotfix合并到master上。

2 个月前greatghoul

看来大部分都是 master dev

2 个月前在线炒粉

我这边有 开发环境 + 测试环境 + 内外灰度环境 + 正式环境 😇😇😇

2 个月前Ivan一万

gitflow

不喜欢太多分支,一般就2个,master+dev

2 个月前穆笺

git flow
有新功能建一个feature,写完后,随便找个闲着的测试服务器切到对应分支供测试测试。
测试通过后合develop,在测试一回,没问题后合master上线,嗯,灰度的只是华东,一天后,客服没炸,全面上线。

2 个月前EROSss

我用的是master + develop模型,我更关心项目回退时,能够快速准确定位。楼上对比了merge和rebase的好坏,我感觉跟个人使用的工具【git CLI 还是 git GUI】也有关。二者其实可以搭配使用吧,使用rebase有条黄金法则【不要在公共分支上使用】。

2 个月前💯💯💯

根据具体的业务复杂度调整的gitflow

2 个月前SmyxCoding

公司按照自己的名字新建分支,然后提交给指定的项目经理合并。提交代码注释写功能的需求号+全称,修改BUG代码提交注释需求号+功能+修改点。

2 个月前xaut

master+develop+tag,用户都是基于develop拉取自己的分支开发,然后提交,最后统一的跟master做merge,master分支做发布使用,然后打tag。bufix也是基于master进行

2 个月前孔祥岩

git-flow

1 个月前XL

1. 代码提交流程
Commit 提交代码到本地仓库
Pull 拉取远程仓库代码(如果有冲突,联系相关开发者,一起解决。)
Push 推送本地仓库代码到远程仓库

2. 代码分支规范
分支含义
主分支 -> master -> 主分支,需要发布版本的时候将dev合并到master发布
发布分支 -> release.{v.1.0.1} 版本号 -> 发布master版本稳定后,创建分支resease_{版本号},提供可回滚稳定版本。
协同开发分支 -> dev -> 开发成员协同开发分支,在本地分支开发完以后合并到dev分支
本地开发分支 -> dev_{local} 本地分支名称 -> 本地分支,按需求、BUG等创建本地分支,目的是在同时开发多个BUG的时候,各个BUG修复提交互相不冲突。

3. 代码提交规范
type代表某次提交的类型,比如是修复一个bug还是增加一个新的feature,所有的type类型如下:
feat: 新增feature
fix:修复bug
doc:仅仅修改了文档,比如README, CHANGELOG, CONTRIBUTE等等
refactor:代码重构,没有加新功能或者修复bug
perf:优化相关,比如提升性能、体验
test:测试用例,包括单元测试、集成测试等
chore:改变构建流程、或者增加依赖库、工具等
revert:回滚到上一个版本
tag:标记或者打标签

16 小时前Phony Lou

Trunk-Based Development,所有提交直接去master,每次提交都会触发CI / CD

保持代码树干净,拉新代码用 git pull --rebase

尽量不用PR

推荐话题
    加载中…
加入组织

微信扫码,每周推送工作机会。