V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
oppoic
V2EX  ›  git

你们的团队,不管大小,是怎么用 git 进行协作开发的?

  •  
  •   oppoic · 2019-03-04 17:50:45 +08:00 · 3750 次点击
    这是一个创建于 1851 天前的主题,其中的信息可能已经有所发展或是发生改变。

    master 分支维护一个稳定的可以发布的版本,这个版本不允许任何人直接提交,仅有管理员通过合并的方式进来代码,另一个 dev 分支是大家平时开发的分支。那么问题来了:

    1 )让团队里每一个人都有权限 push 代码到 dev 分支?

    2 )还是让大家 fork 一份 dev 分支,然后本地开发。开发完成了再发 pull request,管理员检查没问题后进到 dev 分支,再 master 分支 merge 下 dev 分支的代码? 第一种方式遇到 svn 选手不停的提交代码可能会代码不必要的麻烦,第二种情况没这个问题,但是略繁琐。

    大家一般怎么处理?完美的 git 协作是什么样子的?

    12 条回复    2019-03-04 19:46:30 +08:00
    msg7086
        1
    msg7086  
       2019-03-04 17:54:51 +08:00
    msg7086
        2
    msg7086  
       2019-03-04 17:56:51 +08:00
    不管怎么做,对程序员的能力都有要求。
    既然是工作了,那就拿出点专业精神来,把工作做好。
    relsoul
        3
    relsoul  
       2019-03-04 17:57:01 +08:00   ❤️ 2
    遵循 git flow 流程,
    master 分支严格对应线上版本,develop 分支对应开发版本,每次提交都需要 code view, feature/* 则为各自的功能分支,开发完毕后合并 develop 分支,再从 develop 分支打包 release 分支版本,测试结束后发布上线
    Jeremial
        4
    Jeremial  
       2019-03-04 17:57:50 +08:00   ❤️ 3
    master 只有管理员可以合并 pull request
    特性分支从 master checkout 新分支进行开发
    开发完成后, 将特性分支发 PR 合并进 develop 分支, 在 develop 环境联调
    联调完成后, 将特性分支发 PR 合并进 qa 分支, 由 qa 进行测试
    测试完成后, 将特性分支发 PR 合并进 master 部署
    msg7086
        5
    msg7086  
       2019-03-04 18:04:55 +08:00
    补充一下提交流程。
    master 或者 stable 是稳定版,是可以部署给客户或者线上的版本。
    dev 或者 master (看你们的命名习惯)是主线 /开发版,是每个功能完整提交合并后的分支。
    feature 分支则是每个 story 一个,会频繁 rebase 和 interactive rebase,开发时要求频繁提交,完成时要求按照大功能 squash 整理(比如数据库结构修改一个提交,后端 API 数个提交,前端页面数个提交等等),尽量保证每个提交都可以单独回滚。
    feature 分支合并前需要做 Code Review。我们并不拘泥于 Merge Request,一般就是同事之间招呼一下,签出提交看几眼,没问题就给过的。如果你们对代码质量要求高,可以用 MR 然后指定 2 名或者以上的同事来做 Review。
    合并的话谁都有权做,但是有权不代表就可以随便合并,还是要另一名同事给过了才合并。

    代码我们是测试驱动开发的,所以跑通测试的话问题不是很大,如果有意外出现的话,可能会回滚主线提交,或者在主线上再打补丁。
    janxin
        6
    janxin  
       2019-03-04 18:07:51 +08:00
    复杂的是 git flow

    简单的就是 master/develop
    GTim
        7
    GTim  
       2019-03-04 18:08:14 +08:00
    哎,一个分支开发到尾~,如果不是有 git 大牛坐镇,真的不如 SVN
    ducklyl
        8
    ducklyl  
       2019-03-04 18:23:55 +08:00
    大的项目用 gitflow,小的话,直接 master/develop,master 管理员维护,develop 其他都可以 push 上来。管理员 merge 进 master 再检查。
    mywaiting
        9
    mywaiting  
       2019-03-04 18:31:21 +08:00   ❤️ 1
    说到用 git 进行协作,脱离团队大小、人数多少来谈是没有意义的

    一两个人的话,聊天工具沟通一下,然后选择各自开发,直接合并到 master 分支即可,人少,搞太多流程简直内耗,觉得只用 master 分支不好的话,多开个 dev 分支也不错

    十来个人的团队的话,这就要规范一下下了,各自有自己的分支,然后 PR 合并到 master,master 推送到测试环境测试通过就自动 deploy

    要是再多人的话,那就只有严格按照 git flow 了,按照团队的功能开分支,逐一合并,最后合并到 master 分支,中间穿插 code review,生成代码质量报告,分环境进行测试,合成个人周报月报等等等

    还是看人数吧,人少都好办,人多就麻烦

    我自己的项目,开坑到现在都只有 master 分支~ [手动狗头~]
    my3157
        10
    my3157  
       2019-03-04 19:11:36 +08:00
    了解下 git flow
    ifaii
        11
    ifaii  
       2019-03-04 19:28:41 +08:00
    git flow + gitlab merge requests
    fire9
        12
    fire9  
       2019-03-04 19:46:30 +08:00
    github 和 gitlab 的 Git flow 流程不一样. 建议团队自己做一套适合自己团队的 git flow.
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5361 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 08:29 · PVG 16:29 · LAX 01:29 · JFK 04:29
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.