• Git上手:四种常见的Git协同工作方式


    1.集中式工作流

    适用人群:开发小团队(4-5人),习惯使用SVN工具的小团队。

    工作方式:团队组长创建远程仓库,创建一个master分支,组员可读可写。

                      每个开发人员都git clone远程仓库到本地仓库,在master分支上开发。

                      每次开发都要git pull更新到远程仓库的master分支版本。

                      每次开发完成就git commit到本地仓库, 接着git push到远程仓库。

    缺点:忘了git push,一直会提交到本地仓库,没有推送到远程仓库。

               忘了git pull,导致本地仓库与中央仓库不一致,发生文件冲突。

               大量操作git pull,导致增加git分支合并次数,增加了git变基次数,降低了git的性能。

    2.分支工作流

    适用人群:开发中团队(10人以上,100人以下),熟悉Git分支的团队。

    工作方式:团队组长创建远程仓库,创建一个master分支,组员可读不可写。

                      每个开发人员都git clone远程仓库到本地仓库。

                      每个开发人员创建自己的feature分支,在feature分支上开发。(记住,feature分支是基于master分支)

                      每个开发人员每次开发完成就git commit到本地仓库中自己的feature分支, 接着git push到远程仓库。

                      通过pull request提醒团队组长,浏览组员提交feature分支。

                      组长把feature分支拉下来并合并到自己本地仓库的master分支上测试。

                      组长测试feature分支通过之后,由组长负责把feature分支合并到远程仓库的master分支上。

                      组长在远程仓库把合并过的feature分支删除。

                      组员在本地仓库把合并过的feature分支删除。

                      组员将本地仓库分支切换为master分支,然后git pull将本地仓库的master分支更新到远程仓库的master分支版本。

    缺点:增加团队组长的工作量。

               增加团队组员提交步骤。

    PS:Pull Request作用是可以让其他组员或组长可以查看你的代码,并可以提出代码修改意见或者讨论。

    3.Gitflow工作流(多分支工作流)

    适用人群:开发团队(100人以上),熟悉Git分支的团队。

    工作方式:项目维护者创建项目维护者的远程仓库,创建master分支与develop分支,贡献者可读不可写。

                      每个贡献者git clone远程仓库中的develop分支到本地仓库。(记住,develop分支相当于master的分支,包括功能开发,修改,测试。master分支相当于最终分支)

                      每个贡献者在本地仓库创建自己的feature分支,在feature分支上开发。

                      在feature分支又可以创建多个feature分支,继续开发项目。

                      每个贡献者每次开发完成就git commit到本地仓库中自己的feature分支, 接着git push到远程仓库。

                      通过pull request提醒项目维护者,浏览贡献者提交feature分支。

                      项目维护者把feature分支拉下来并合并到自己本地仓库的develop分支上测试。

                      组长测试feature分支通过之后,由组长负责把feature分支合并到远程仓库的develop分支上。

                      项目维护者会release分支上git tag打上版本号。

                      项目维护者可以从develop分支创建release分支,接着把release分支合并到master分支上,同时master分支同步到develop分支。

                      项目维护者在远程仓库把合并过的feature分支删除。

                      每个贡献者在本地仓库把合并过的feature分支删除。

                      每个贡献者将本地仓库分支切换为develop分支,然后git pull将本地仓库的master分支更新到远程仓库的develop分支版本。

                      

    PS:Gitflow工作流是Vincent Driessen工程师提出的多分支工作流。

               

    4.分叉工作流(分布式仓库工作流)

    适用人群:开发团队(1000以上),熟悉Git分支的团队。

    工作方式:主项目维护者创建主项目维护者的远程仓库,创建一个master分支,从项目维护者可读不可写。

                      从项目维护者通过fork主项目维护者的远程仓库的副本到自己的远程仓库,包括master分支。(记住,从项目维护者的远程仓库独立于主项目维护者的远程仓库)

                      从项目维护者git clone主项目维护者的远程仓库的副本到本地仓库。

                      从项目维护者创建自己的feature分支,在feature分支上开发。

                      从项目维护者每次开发完成就git commit到本地仓库中自己的feature分支, 接着git push到远程仓库。

                      通过pull request从项目维护者合并自己feature分支到从项目维护者的远程仓库的master分支上。

                      从项目维护者在远程仓库把合并过的feature分支删除。

                      从项目维护者在本地仓库把合并过的feature分支删除。

                      从项目维护者在远程仓库通过pull request向主项目维护者的远程仓库的推送。

                      主项目维护者通过pull request获取从项目维护者的远程仓库的推送。

                      主项目维护者进行从项目维护者的远程仓库代码审查,测试。

                      主项目维护者确认无误后,可以直接合并到主项目维护者的远程仓库。

  • 相关阅读:
    hibernate和mybatis区别
    Spring事务的传播行为和隔离级别
    数组拷贝
    spring mvc 一次请求 两次查询
    手游性能之渲染分析3
    Android pm 命令详解
    Android am命令使用
    Android dumpsys命令详细使用
    java处理高并发高负载类网站的优化方法
    关于ArrayList的5道面试题
  • 原文地址:https://www.cnblogs.com/Sroot/p/9560548.html
Copyright © 2020-2023  润新知