精华内容
下载资源
问答
  • Git分支管理流程
    千次阅读
    2021-03-24 10:50:50

    前言

    有幸参与一次大型项目,人员较多,需求较多,代码管理方面值得学习,记录总结一下分支管理。

    本文参考:

    李刚的学习专栏

    程序员大本营

    管理流程简介

    流程图例

    大体管理流程如下:

    在这里插入图片描述
    在这里插入图片描述

    案例解析

    如上图所示:

    生产初始版本为v0.5,项目初始develop与master是保持一致的

    现有新需求:

    • 平台注册功能
    • 平台登录功能

    版本规划:

    • 平台注册功能v1.0版本上线

    • 平台登录功能v1.1版本上线

    开发任务:

    • 注册功能由张三负责

    • 登录功能由李四负责

    张三同学:v1.0版本开发到上线

    • 从develop新建一个用于开发注册功能的分支
    • 命名为feature_register
    • 本地拉取分支代码,开发注册功能,测试,修改再测试等流程
    • 开发完成,提交到develop,此时feature_register可以删除
    • 从develop新建一个预发布分支release-v1.0
    • 从release-v1.0打包发布到测试环境
    • 测试修复bug,测试通过更新到master以及develop
    • master打包,打tag,tag信息为v1.0相关信息

    李四同学:v1.1版本开发到上线

    • 从develop新建一个用于开发登录功能的分支
    • 命名为feature_login
    • 本地拉取分支代码,开发登录功能,测试,修改再测试等流程
    • 开发完成,提交到develop,此时feature_login可以删除
    • 从develop新建一个预发布分支release-v1.0
    • 从release-v1.0打包发布到测试环境
    • 测试修复bug,测试通过更新到master以及develop
    • master打包,打tag,tag信息为v1.0相关信息

    测试环境

    • 测试修复bug,测试通过更新到master以及develop
    • master打包,打tag,tag信息为v1.0相关信息

    注:hotfix-xxx分支主要是针对master上bug的修复,修复完成之后需要把hotfix合并到maser,master打包,打tag,tag信息为hotfix相关信息,并发布生产,同时合并到develop分支,使develop和master一致,此时hotfix可删除。

    更多相关内容
  • git分支管理策略

    2018-07-23 15:48:22
    git分支管理策略,git分支管理策略,git分支管理策略,git分支管理策略
  • git多分支管理方案

    2018-11-15 09:29:42
    git flow完整管理方案 第一步:由部门经理在gitlab上创建各自部门项目,之后从默认的master分支fork出一条分支,命名为dev。master主分支用作线上版本发,dev用来稳定版本。
  • 简单的,基于四个主要分支的分支管理方法 概述 通常的软件工程,一般会经过开发、测试,最后发布生产三个阶段。团队在开发时,一般会按照功能拆分分支,或按个人拆分分支。但是在大多数情况下,一般一个团队或一个...
  • 该文档定义了分支管理规范-GIT分支流程开发规范。
  • svn分支管理

    2016-07-27 13:45:17
    内容包含: SVN并行开发分支管理指南 SVN分支管理模式解析 软件配置管理引发的版本分支思考
  • 本文来自segmentfault,文章介绍了创建与合并分支分支的操作管理以及多人协作开发等相关知识。利用分支就可以实现多人开发的伟大模式,从而提高生产效率。在整个GIT之中,主分支(master)主要是作为程序的发布使用...
  • 分支管理流程图.vsdx

    2017-01-03 11:32:56
    分支管理流程图.vsdx
  • GIT分支管理

    2019-01-02 15:18:37
    GIT分支管理 远程分支 本地分支 GIT分支管理 远程分支 本地分支
  • 为了规范代码库分支管理和版本管理,使代码分支及版本结构清晰,方便维护,并避免由于维护造成的错误的版本发布等问题。通常每个应用或者是二方库的代码将包括master、develop、release、hotfix、feature分支,...
  • 分支合并 解决冲突 比较差异 分支管理策略 Bug分支 保存工作现场 查看工作现场 恢复工作现场 删除工作现场 恢复并删除工作现场 合并某一次的提交 feature分支 远程仓库(多人协作) 本地仓库关联远程仓库 第一次先...

    您好,我是码农飞哥,感谢您阅读本文,欢迎一键三连哦
    💪🏻 1. Python基础专栏,基础知识一网打尽,9.9元买不了吃亏,买不了上当。 Python从入门到精通
    ❤️ 2. Python爬虫专栏,系统性的学习爬虫的知识点。9.9元买不了吃亏,买不了上当,持续更新中 。python爬虫入门进阶
    ❤️ 3. Ceph实战,从原理到实战应有尽有。 Ceph实战
    ❤️ 4. Java高并发编程入门,打卡学习Java高并发。 Java高并发编程入门
    😁 5. 社区逛一逛,周周有福利,周周有惊喜。码农飞哥社区,飞跃计划
    全网同名【码农飞哥】欢迎关注,个人VX: wei158556

    1. Git是什么?

    Git是一款开源的分布式版本控制系统,可以有效,高速处理从很小到非常大的项目版本管理。 Git是通过C语言开发实现的。

    2. Git与SVN的比较

    Git和SVN是两种截然不同的版本控制系统,Git是分布式版本控制系统,而SVN则是集中式版本控制系统。要想比较Git和SVN的区别,首先需要了解分布式版本控制系统和集中式版本控制系统的基本概念。
    集中式版本控制系统:一个显著的特征是版本库是存放在中央服务器上的,由中央服务器统一管理项目的版本信息和分支信息。团队中的每个成员在工作时都需要先从中央服务器上拉取最新的代码,然后开始干活。干完活之后再将代码提交到中央服务器上。集中式版本服务器有两个弊端:

    1. 必须联网才能工作,当没有网络或者网络很差时,则团队中的成员无法协同工作。
    2. 安全性不好,因为版本库存放在了中央服务器,当中央服务器损坏时则会丢失版本库,使所有成员都没法工作。

    集中式版本控制系统的网络拓扑图如下图所示:
    在这里插入图片描述
    可以看出团队中所有成员的工作电脑都只与中央服务器打交道。如果把版本库比做书库的话,那么每个人(每个电脑)都需要先从书库借到书(拉取最新的代码),阅读完之后然后还给书库(修改之后提交到中央服务器)

    分布式版本控制系统: 与集中式版本控制系统最大的不同是团队中所有成员的工作电脑上都有一个完整的版本库,并且没有中央服务器。,这就相当于团队中每个成员都有一个自己的小书库(版本库),成员之间可以互相交换自己书库中的图书(将自己的修改提交给对方)。这里完全不需要中央服务器来管理协调管理。
    在实际使用分布式版本控制系统时,其实很少在两人之间的电脑上进行版本库推送,这是因为有时候你们不在同一个局域网内,或者你同事的电脑关机了。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。这台充当“中央服务器”的电脑上的版本库称之为远程版本库,其他成员电脑上的版本库称之为本地版本库。后面会详细介绍。

    分布式版本控制系统的网络拓扑图如下图所示:

    在这里插入图片描述
    分布式版本控制系统剔除了中央服务器,这充分体现了分布式的核心概念,就是去中心化。这样带来的好处有两点:

    1. 没有网络也能上班:团队中的每个成员在没有网络的情况下也能工作,因为本地有完整的版本库,不需要担心数据的丢失。
    2. 数据更安全:当某个成员的电脑坏掉了不要紧,只需要从其他成员的电脑上复制一份即可。但是集中式版本控制系统的中央服务器出问题,则可能会丢失版本库,使得所有人都没法工作。

    3. 系统环境

    系统版本
    WindowsWindows10
    LinuxUbuntu16.04

    4. 安装Git客户端

    说完了Git的基本概念,接下来还是安装个Git客户端下来耍一耍。这里分不同的操作系统简单的介绍一下Git客户端的安装。

    Linux系统下

    首先通过git --version 命令查看电脑上是否已经安装了Git客户端。
    在这里插入图片描述
    如果已经安装了就可以跳过此章节。如果没有安装的话就接着往下面看:
    Linux系统有不同的发行版本,可以通过cat /proc/version 命令查看Linux的版本。

    1. Debian或Ubuntu下安装Git
      在 Debian或Ubuntu可以通过apt包管理工具安装Git,命令如下:
    sudo apt-get install git
    
    1. Red Hat 或者CentOS下安装Git
      Red Hat 或者CentOS下可以通过yum包管理工具安装Git,命令如下:
    yum install git -y
    

    如果找不到yum命令的话,则需要先安装yum工具。可以参考下面命令

    #删除yum.repos.d目录下所有文件
    rm -f /etc/yum.repos.d/*
    #然后重新下载阿里的yum源
    wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
    #清理缓存
    yun clean all
    

    Windows系统下

    Git的官方下载地址是:Git的下载地址
    在这里插入图片描述
    下载好安装包之后,一直点击下一步即可安装。再次就不在赘述。

    5.本地版本库操作

    Windows下安装好Git之后会出现Git Bash 和Git GUI两个应用程序,其中Git Bash是Git的命令行工具,而Git GUI则是Git的可视化工具(一般很少用)。

    创建本地版本库

    创建本地版本库分为两步:
    第一步是创建一个空文件夹,命名为: git_learn。
    第二步就是在该文件夹下执行git init 命令将该文件夹变成git可以管理的版本库。
    执行第二步之后,在 git_learn目录下会出现一个名为.git的隐藏文件夹,该文件夹就是git的版本库。切记不要手动修改.git文件夹下的任何内容,以免本地版本库不可用

    本地版本库建好之后就可以在git_learn文件夹下创建一个文件进行测试了。这里创建了一个名为readme.txt的文件。
    添加到暂存区
    通过git add readme.txt命令可以将readme.txt文件提交到暂存区(关于暂存区的概念后面会详细介绍)。如果有多个文件需要添加的话,可以执行git add . 命令。
    提交到版本库
    因为git的本地都是有完整版本库的,所以还需要将前面创建的readme.txt文件提交到本地版本库的当前分支,默认是master。命令格式是git commit -m '<message>' ,其中写入你的提交备注。

    工作区和暂存区

    这里有两个很重要的概念,一个是工作区,另一个是暂存区(Git特有的概念)。
    工作区
    工作区就是你电脑上能看到的目录(不包括隐藏文件),例如:git_learn目录就是一个工作区。

    暂存区
    工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库,其中最重要的是暂存区(stage)。

    还有Git为我们自动创建的第一个分支叫master,以及指向master的一个指针叫HEAD。

    前面提到了工作区,暂存区,git add命令和git comit 命令。那么他们之间有啥关系呢?下面就用一张流程图展示一下:
    在这里插入图片描述
    通过add命令将工作区中ABC文件夹提交到暂存区stage,在通过commit命令将stage中的ABC文件夹提交到当前分支master。

    管理修改

    Git管理的是修改而非文件。这里的修改指的是对工作区的任何操作,包括新增文件;删除文件;修改文件等等。哪怕是在文件中增加一句话或者删除一个字符都可以算是修改。下面就举例说明下,还是以readme.txt文件为例:

    1. 第一次在readme.txt文件中增加一个词语 gittest。然后执行git add readme.txt,并通过命令git status查看状态。
      hello world
      gittest

      在这里插入图片描述
    2. 第二次再在readme.txt文件上添加一行内容git tracks changes
      hello world
      gittest
      git tracks changes

    直接执行git commit -m 'git tracks changes'命令。然后通过 git status ,可以发现第二次的修改没有提交。这是因为第二次的修改没有先提交到暂存区中。
    在这里插入图片描述
    我们的操作过程是第一次修改 -> git add -> 第二次修改 -> git commit。当使用git add 命令后,在工作区中的第一次修改被放入暂存区中,准备提交,在工作区中的第二次修改没有被放入暂存区中,所以,git commit只负责把暂存区中的修改提交到当前分支。所以第二次的修改没有提交。
    也就是说,所有的修改必须先通过git add 提交到暂存区,然后通过git commit 提交到当前分支。。在实际开发中一般是将所有修改合并起来add,然后在一起commit。

    删除文件

    当前分支上有一个已经废弃不用的文件,该如何删除呢?比如要删除一个名为test1.txt文件。只需要两行命令。

    git rm test1.txt
    git commit -m "remove test.txt"
    

    5.Ubuntu搭建私有的git仓库

    前面介绍了在实际开发中,一般会拿一台电脑作为“中央仓库”,充当中央仓库的电脑需要安装一个代码仓库软件,这里选用开源软件GitLab,它是基于git实现的在线代码仓库软件,提供web可视化管理界面,可以在本地部署。通常用于企业团队内部协作开发。当然,如果你不想搭建私人的git仓库,那么也可以直接使用最大的同性交友网站Github(使用与GitLab类似)。
    那么该如何在Ubuntu上安装GitLab软件,搭建私有的Git仓库呢?

    1. 安装必须的一些服务
    #更新apt源
    sudo apt-get update
    #安装依赖包,运行命令
    sudo apt-get install curl openssh-server ca-certificates postfix
    sudo apt-get install -y postfix
    
    1. 接着信任 GitLab 的 GPG 公钥:
    curl https://packages.gitlab.com/gpg.key 2> /dev/null | sudo apt-key add - &>/dev/null  
    
    1. 配置镜像路径
      由于国外的下载速度过慢,所以配置清华大学镜像的路径。
    sudo vi /etc/apt/sources.list.d/gitlab-ce.list  
    

    在该文件中写入如下代码

    deb https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu xenial main 
    
    1. 安装gitlab-ce
    sudo apt-get update
    sudo apt-get install gitlab-ce
    

    安装gitlab-ce成功之后。
    5. 修改外部url
    在gitlab配置文件/etc/gitlab/gitlab.rb中修改外部url,改为自己的ip地址或者域名。

    sudo vi /etc/gitlab/gitlab.rb
    

    找到external_url,修改其默认的地址,这里改成了我本机局域网IP:192.168.40.138

    external_url 'http://192.168.40.138/'  ## 本机的局域网ip地址为192.168.41.128
    
    1. 执行配置
      前面步骤顺利的话就可以执行配置了,该过程可能需要较长的时间。
    sudo gitlab-ctl reconfigure
    
    1. 启动GitLab
    sudo gitlab-ctl start
    

    可以通过ps -ef|grep gitlab 命令查看GitLab是否启动成功。
    8. 进行浏览器访问
    GitLab成功启动之后就可以通过浏览器访问GitLab的主页了。在浏览器上输入http://192.168.40.138/;
    在这里插入图片描述
    默认输入的用户名是root用户,输入的密码是root的账户密码。
    至此GitLab的安装就全部结束,我们也成功的搭建了属于自己的Git仓库。

    GitLab的使用

    添加用户

    点击设置按钮,进入设置栏,选中Users->New User 进入添加用户页面。
    在这里插入图片描述
    在这里插入图片描述
    输入姓名,用户名,和邮箱即可注册添加新用户。

    添加团队

    用户添加好之后,就是将用户添加到团队中,GitLab中默认会有一个名为GitLab Instance的团队,你也可以添加自己的团队,这里我添加了一个名为ai_edu的团队。并在团队中添加了两个成员。
    在这里插入图片描述
    选中要添加成员的团队,在右侧会出现一个添加Add user(s) to the group的栏目。再此栏目中所有用户并添加到团队中。用户的角色有游客,测试人员,开发人员,管理者,拥有者等几个不同的角色。
    在这里插入图片描述

    新建远程仓库

    说完了用户和团队的设置后,现在就进入了重点了,如何新建一个远程仓库。同样也是比较方便。操作步骤是:Project->Your projects->New project
    在这里插入图片描述
    在这里插入图片描述
    这里新建了一个名为git_test的远程仓库,仓库的所有这是属于ai_edu团队。
    在这里插入图片描述

    这里仓库的权限等级有三个等级,分别是:Private(只有你团队的人才能拉取和推送代码),Internal(除了黑名单之外的用户可以拉取和推送代码)。Public (所有的用户都可以拉取)。

    SSH key的配置(生成公钥和私钥)

    为啥要配置SSH key呢?这是因为GitLab与你的电脑是通过SSH协议来通信的。说白了,如果你没有配置SSH key的话,则你不能推送代码到远程库。这里首先在你本地生成公钥和私钥文件,然后把公钥文件的内容复制到GitLab上。

    1. 配置用户名
    git config --global user.name “username”
    
    1. 配置邮箱
     git config --global user.email  jayxiang31@gmail.com
    

    jayxiang31@gmail.com替换成你实际的邮箱地址。不需要加单引号。
    4. 生成公钥和私钥

    ssh-keygen -C 'you email jayxiang31@gmail.com' -t rsa
    

    如果简单些的话可以直接填写ssh-keygen 命令。邮箱地址填写前面设置的邮箱地址。有提示的话一直按Enter键。正确执行后会输入如下信息
    在这里插入图片描述

    2 找到公钥文件id_rsa.pub,复制公钥内容到GitLab
    在这里插入图片描述

    6. 分支管理

    创建与合并分支

    分支的概念:分支就是每次提交创建的点所连接成的时间线。这条时间线就是一个分支,默认的话只有一个主分支master分支。HEAD严格来说不是指向提交,而是指向master,master才是指向提交,HEAD指向的就是当前分支。
    一开始的时候,master分支就是一条线,Git用master指向最新的提交,再用HEAD指向master,就能够确定当前的分支以及当前分支的提交点。
    每次提交,master分支都会向前进移动一步,这样随着你不断提交,master分支的线也会越来越长。其结构如下图所示:
    在这里插入图片描述

    1. 创建dev分支

    当我们新创建一个分支dev时,Git会创建一个指针dev指向master分支当前的提交点。当切换到dev分支后,HEAD指针会指向dev。也就是说HEAD始终是指向当前分支的

    git checkout -b dev
    

    git checkout 加上-b参数表示创建并切换到dev分支上,相当于下面两条命令。

    $ git branch dev
    $ git checkout dev
    

    执行该上面的命令之后的git的提交时间线如下图所示:
    在这里插入图片描述
    当在dev分支上提交代码(未改变master分支)之后,dev分支会不断的向后推进。而master指针的指向则不会变。
    在这里插入图片描述
    git checkout命令是一个比较特殊的命令,传入不同的参数会有截然不同的效果。例如:git checkout -- file 命令,表示的意思是撤销file文件中所有的修改。所以Git还提供了git switch命令用于创建和切换分支。

    ## 创建并切换到新的dev分支
    git switch -c dev
    ## 切换到已有的master分支
    git switch master
    

    2. 查看所有分支

    分支创建好之后,可以通过git branch命令进行查看。

    3. 分支合并

    当团队成员在dev分支上开发完毕之后,就可以将dev分支上的内容合并到master分支上,合并分支的原理就是将master指针指向dev的当前提交。Git合并分支只是改了下指针,工作区的内容没有改变。
    在这里插入图片描述

    其合并的命令分两步,第一步是切换到master分支,第二步是合并dev分支

    #切换到master分支
    git checkout master
    #合并dev分支
    git merge dev
    
    1. 删除dev分支
      现在dev分支的内容也合并到了master分支上了,可以将dev分支删除了。Git删除dev分支其实就是删除dev指针。删除之后又只剩下master分支了。需要注意的是必须要先切换到master分支上再进行删除dev分支的操作。删除dev分支的命令如下:
    git branch -d dev
    

    解决冲突

    在团队协作过程中,难免会碰到各种修改冲突。那么该如何解决这些冲突呢? 例如:你和你同事分别修改了readme.txt文件,那么当你们同时提交时就会出现冲突。又或者在你在master分支和feature1分支上分别修改了readme.txt文件。那么当你合并feature1分支到master分支时就会出现冲突。举个栗子吧:

    1. 在feature1分支上给readme.txt文件中加上了文本处理冲突。然后提交到feature1分支。
    2. 切换到master分支,给readme.txt文件中加上文本
    冲突处理
    master有冲突
    

    然后提交到master分支上。
    3. 将feature1分支合并到master分支,此时就会出现合并冲突。如下图所示:

    冲突之后,Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容。如下图所示:
    处理冲突的方式就是编辑冲突内容。然后重新提交。

    $ git add README.md
    $ git commit -m "解决冲突"
    

    比较差异

    1. 比较两个提交之间的差异 git diff 36e4fd7 b55da38
      在这里插入图片描述
    2. 比较工作区与仓库区的不同,HEAD表示最新的那次提交 git diff HEAD

    分支管理策略

    通常情况下,Git在合并分支时,会使用Fast forward模式。但是,这种模式下,删除分支后,会丢掉分支信息。如下图所示,删除dev分支之后,分支的信息也就就丢失了

    在这里插入图片描述
    如果要强制禁用Fast forward模式,Git会在merge时生成一个新的commit。当删除分支时就不会丢失分支信息。其命令是
    git merge --no-ff -m "merge with no-ff" dev
    准备合并dev分支,其中--no-ff参数,表示禁用Fast forward,因为本次合并要创建一个新的commit,所以加上-m参数。把commit描述写进去。

    Bug分支

    当你接到一个修复代号为01的bug的任务时,很自然地,你会创建一个分支issue-01来修复它,但是,如果这是你正在dev分支上进行的工作还没有提交,提交吧,可是你在dev上的工作只进行了一般,还没法提交,预计完成还需1天的时间。但是,现在必须要在两个小时内修复代号01的bug。这时候该怎么办呢?你不是期望有一个功能可以隐藏你当前在dev上未提交的工作,然后,切换到issue-01分支修改bug呢。
    通过stash功能可以满足你的愿望,将当前工作现场隐藏起来。如下图所示:执行git stash命令之后,新建的hello.html文件就从工作区中消失了。
    在这里插入图片描述

    保存工作现场

    git stash
    

    git stash命令可以将当前未提交的工作隐藏起来。让你的工作区变的干净清爽。

    查看工作现场

    git stash list 可以查看当前仓库所有已经保存的工作现场。

    git stash list
    

    恢复工作现场

    现在代号为01的bug已经修复好了,你可以继续切换到dev分支上进行开发了。那么这时候你需要做的第一件事就是恢复之前保存的工作现场。恢复工作现场的命令是:

    git stash apply
    

    删除工作现场

    通过git stash apply 命令可以恢复工作现场。但是,恢复之后工作现场还在。那么这时候我们还需要一个命令来删除工作现场。其命令是:

    git stash drop
    

    恢复并删除工作现场

    恢复工作现场一条命令,删除工作现场又是一条命令。未免有点繁琐了吧。有没有将两者合二为一的命令呢?答案是有的:通过下面的命令就可以实现:

    git stash pop
    

    在master分支上修复了bug后,我们想一想,dev分支是早期从master分支分出来的,所以,这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug?重复操作一次,提交不就行了?这种方法也不是不行,如果该BUG涉及的修改过多,这样的方式就显得有点捉襟见肘了。那么我们能不能把修改BUG做的提交复制到当前的dev分支呢?答案是有的:

    合并某一次的提交

    git cherry-pick  821ea4d
    

    通过git cherry-pick 命令可以将单个的提交复制到当前分支。可以通过 git log 查看提交的提交的版本号。

    feature分支

    添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。
    前面介绍可以通过git branch -d branchname 命令删除分支。但是,如果被删除的分支还没有合并到主分支的话,用该命令删除的话分支的话,Git会抛出一个错误提示并不能删除该分支。如下:要删除一个名为feature-01的分支。但是该分支还没有被merge。这时候就需要强制删除分支的命令了。

    git branch -D feature-01
    

    其中feature-01为待删除的分支名。其实就是将-d参数换成-D参数。

    远程仓库(多人协作)

    前面说了那么多,好像都是一个人在本地操作,没有涉及到多人协作的情况。这在团队开发中肯定是不可能的啦,因为我们是一个team。那么多人协作的情况涉及哪些操作呢?

    本地仓库关联远程仓库

    git remote add origin http://192.168.40.138/ai-edu/git-demo.git
    

    或者,推荐使用下面这种,因为前面配置了SSH公钥和私钥

    git remote add origin git@gitee.com:jayxiang31/python_learn.git
    

    第一次先拉取远程库中的README.md和.gitignore等文件

    git pull --rebase origin master
    

    克隆远程仓库

    前面第三章已经搭好了私有的Git仓库管理器GitLab。同时也创建了一个名为git_test的仓库。现在要做的就是将远程仓库克隆下来。克隆的命令是git clone

    git clone http://192.168.40.138/ai-edu/git_test.git
    

    其中http://192.168.40.138/ai-edu/git_test.git 是远程仓库的地址。
    当然也可以在IDEA上直接通过图形界面操作,还省去了导入项目的过程。其操作步骤是:

    1. 选中File->New->Project from Version Control->Git。如下图所示:
      在这里插入图片描述
    2. 在URL中填入远程仓库的地址,点击Clone按钮。如下图所示:
      在这里插入图片描述
      需要注意的是默认情况下只会克隆master分支,其他的分支不会被克隆下来。其他的分支需要通过git pull命令拉取,后面会详细介绍。

    删除远程Git仓库

     git remote rm origin
    

    查看远程分支

    通过git remote命令可以查看远程仓库,origin表示远程主机。
    通过git remote -v 命令可以查看远程仓库详细的信息,包括远程仓库的地址。

    $ git remote -v
    origin  http://192.168.40.138/ai-edu/git_test.git (fetch)
    origin  http://192.168.40.138/ai-edu/git_test.git (push)
    

    上面显示了可以抓取和推送的origin的地址。如果没有推送权限,就看不到push的地址。

    推送分支

    现在将远程仓库克隆下来了,那么该如何将当前分支上所有的本地提交推送到远程库呢?答案是通过git push命令,其语法结构是git push <remote branch> <local branch> 其中<remote branch>表示远程分支名,<local branch>表示本地分支名。

    git push origin master
    

    该语句表示将本地的master分支推送到远程的origin分支上。在实际应用中会在git push命令后面加上-u参数,就像git push -u origin master这样。这是因为如果当前分支与多个主机存在追踪关系,则可以使用 -u 参数指定一个默认主机,这样后面就可以不加任何参数使用git push。那么哪些分支该与远程分支保持一致呢?一般认为:

    1. master 分支是主分支,需要时时与远程同步
    2. dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步
    3. bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
    4. feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
      说白了就是需要团队协作的分支一定要推送到远程库,否则则不需要。
      在这里插入图片描述

    创建远程分支

    通过git push命令还能创建远程分支。

    git push origin dev
    

    假设你本地已经有了dev分支。通过上面的命令可以将dev分支推送到远程库,并创建远程的dev分支。

    拉取分支

    通过git pull命令可以拉取远程仓库的数据和分支信息。假设如下这个场景:你同事在他本地创建了一个dev分支,并提交到了远程库。同时你也在本地创建了一个dev库,当你push时会推送失败。结果如下图所示:

    因为你同事的最新提交和你试图推送的的提交有冲突。解决的办法就是根据Git的提示,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突后,在推送。

    $ git pull
    There is no tracking information for the current branch.
    Please specify which branch you want to merge with.
    See git-pull(1) for details.
    
        git pull <remote> <branch>
    
    If you wish to set tracking information for this branch you can do so with:
    
        git branch --set-upstream-to=origin/<branch> dev
    

    git pull也失败了。原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:

    关联本地分支和远程分支

    $ git branch --set-upstream-to=origin/dev dev
    Branch 'dev' set up to track remote branch 'dev' from 'origin'.
    

    关联好本地分支和远程分支之后,在pull就能成功了。这回git pull成功,但是合并有冲突,需要手动解决,解决的方式也是在本地手动处理冲突文件,解决后,提交,在push。

    删除远程分支

    通过

    git push origin :dev
    

    命令可以删除远程dev分支。但是这时候本地的dev分支还是存在的。所以还需要通过git branch -d dev删除本地的dev分支。

    查看分支

    通过git branch可以查看本地分支
    通过git branch -a 可以查看本地分支和远程分支。
    在这里插入图片描述

    版本回退

    在实际开发中我们经常会碰到这样一个场景,比如:你误提交了一段有问题的代码,导致其他同事更新代码之后项目启动不了,这时候该怎么办呢?我们首先想到的就是将版本回退。回退到之前那个没有问题的版本。

    1. 通过git log 命令找到当前的仓库所有的提交日志。然后,找到你需要回退到的版本。如下图所示:
    2. 回退到上一个版本:git reset HEAD
    3. 回退到指定版本:git reset commitId 其中commitId是指定版本的版本号,比如这里将版本信息回退到b50c9bdcbf9641d33e4b531bd96dc1f27d4bf602 这个版本。那么命令就是:
    git reset b50c9bdcbf9641d33e4b531bd96dc1f27d4bf602
    

    回退之后,再次通过git log查看,则最新的提交日志已经变成了hello 提交这个版本了。
    当然,通过IDEA来回退则更加的简单。直接在Version Control->Log 在待回退到的版本上右键,选中Reset Current Branch to Here 即可。
    在这里插入图片描述
    其实回退操作的本质,就是将HEAD指针的指向要回退的那个版本上。

    将多次提交合并成一次提交

    在实际开发中我们经常需要进行代码Review。如果同一个功能点分了很多次提交话,那么在进行代码Review时则会非常的不方便。这时候就需要将多次提交合并成一次提交。具体的步骤是:

    1. 通过git switch <branchname>命令切换到需要合并提交的代码的分支,比如:git switch test
    2. 查看需要合并的提交,如下有三次提交需要合并
      在这里插入图片描述
    3. 通过rebase命令修改提交指令,这里git rebase -i HEAD~3 表示查看最近的三次提交命令,合并几次则需要将对应的数字改成几。
    git rebase -i HEAD~3
    

    执行该命令之后会打开提交指令的日志文件,这里只保留第一次的提交,将另外的两次提交改成 s
    在这里插入图片描述
    保存之后会进入另外一个文件,该文件无需修改,直接输入:q! 命令退出即可。操作之后我们可以看到之前的三次提交记录变成了一次提交记录。
    在这里插入图片描述
    4. 如何要把这次提交合并到其他分支只需要切换到目标分支,执行如下命令;

    git cherry-pick <commitid>
    

    分支重命名

    git branch -m oldname newname
    

    7. 标签管理

    标签管理比较简单,再此只是简单描述一下。

    #创建标签 v1.0
    git tag v1.0
    #查看标签
    git tag
    #删除标签v1.0
    git tag -d v0.1
    #推送标签
    git push origin --tags
    #删除远程标签
    git push origin :refs/tags/v1.0
    

    在这里插入图片描述

    总结

    一万六千多字,我写的累,你们看的也累!!!文中奉上几张美女照片给各位读者大大解解乏。我真真正正的肝了两天了。现在终于肝完了。希望对读者朋友们有所帮助。
    看文字实在是太累了。下面就用一张图来做一个总结吧。
    在这里插入图片描述
    这张图清晰的表明了Git的基本流程。

    Python知识图谱

    为了更好帮助更多的小伙伴对Python从入门到精通,我从CSDN官方那边搞来了一套 《Python全栈知识图谱》,尺寸 870mm x 560mm,展开后有一张办公桌大小,也可以折叠成一本书的尺寸,有兴趣的小伙伴可以了解一下------扫描下图中的二维码即可购买。

    在这里插入图片描述
    我本人也已经用上了,感觉非常好用。图谱桌上放,知识心中留
    在这里插入图片描述

    我是码农飞哥,再次感谢您读完本文

    展开全文
  • Git怎样做分支管理

    千次阅读 2021-04-26 10:49:47
    前言概述Git的基本使用方法使用Git管理项目的方式主分支支持分支总结图 总结 前言 记得刚工作的时候根本不知道什么是版本管理工具,有一次和别人聊天,人家问你们公司代码用什么版本管理工具?我说啥是版本...

    前言

    记得刚工作的时候根本不知道什么是版本管理工具,有一次和别人聊天,人家问你们公司代码用什么版本管理工具?我说啥是版本管理工具,我们一般用U盘拷贝,然后人家就顾左右而言他了。后来我知道了有个东西叫SVN,后来又知道了还有个东西叫Git。所以说刚毕业的同学一定要优先进入专业的大公司,就像年轻时候应该去大城市闯两年一样,眼界以及你遇到的牛人会大大加快你以后成功的进程。

    概述

    本文主要是介绍一种在具体实践中使用Git来管理项目开发的一种成功的方式,其实主要思想来源于这篇文章 A successful Git branching model,网上大部分教程都是致敬这篇文章。

    Git的基本使用方法

    关于git的基本教程,强烈建议阅读廖雪峰老师的Git教程,对初学者非常友好。

    使用Git管理项目的方式

    在实际开发中如何使用Git没有一个标准答案,使用方式也是各式各样,很多基本上都是把Git当SVN来用。下面介绍的是一种经过实践的运行比较良好的管理方式。

    主分支

    实际开发中,一个仓库(通常只放一个项目)主要存在两条主分支:masterdevelop分支。这个两个分支的生命周期是整个项目周期。就是说,自创建出来就不会删除,会随着项目的不断开发不断的往里面添加代码。master分支是创建git仓库时自动生成的,随即我们就会从master分支创建develop分支,如下图所示。
    这里写图片描述

    • master:这个分支最为稳定,这个分支代表项目处于可发布的状态。

      例如王二狗向master分支合并了代码,那就意味着王二狗完成了此项目的一个待发布的版本,项目经理可以认为,此项目已经准备好发布新版本了。所以master分支不是随随便便就可以签入代码的地方,只有计划发布的版本功能在develop分支上全部完成,而且测试没有问题了才会合并到master上。

    • develop:作为开发的分支,平行于master分支。

      例如王二狗要开发一个注册功能,那么他就会从develop分支上创建一个feature分支 fb-register(后面讲),在fb-register分支上将注册功能完成后,将代码合并到develop分支上。这个fb-register就完成了它的使命,可以删除了。项目经理看王二狗效率很高啊,于是:“二狗你顺带把登录功能也做了吧”。二狗心中暗暗骂道:日了个狗的,但是任务还的正常做,二狗就会重复上面的步骤:从develop分支上新创建一个名为fb-login的分支,喝杯咖啡继续开发,1个小时后登录功能写好了,二狗又会将这个分支的代码合并回develop分支后将其删除。

    通过以上分析可以发现,我们可以使用Git hook 脚本自动发布发布新的版本,具体就是每当有代码从develop分支合并到master分支的时候,脚本就会自动触发,编译发布新的版本。

    支持分支

    这些分支都是为了程序员协同开发,以及应对项目的各种需求而存在的。这些分支都是为了解决某一个具体的问题而设立,当这个问题解决后,代码会合并回主分支develop或者master后删除,一般我们会人为分出三种分支。

    • Feature branches:这种分支和我们程序员日常开发最为密切,称作功能分支。

      必须从develop分支创建,完成后合并回develop分支

      如下图所示。
      这里写图片描述
      具体事例可以参考上面王二狗完成登录注册功能时的做法。

    • Release branches:这个分支用来分布新版本。

      develop分支创建,完成后合并回developmaster分支。

      这个分支上可以做一些非常小的bug修复,当然,你也可以禁止在这个分支做任何bug的修复工作,而只做版本发布的相关操作,例如设置版本号等操作,那样的话那些发现的小bug就必须放到下一个版本修复了。如果在这个分支上发现了大bug,那么也绝对不能在这个分支上改,需要Featrue分支上改,走正常的流程。

      实例:王二狗开发完了登录注册功能后决定发一个版本V0.1,那么他先从develop分支上创建一个Release 分支release-v0.1,然后二狗在这个分支上把版本号等做了修改。正准备编译发布了,项目经理说:“二狗啊,你那个登录框好像向右偏移量1个像素,你可以调一下吗?”二狗心中有暗暗骂道:日了个狗,但是。。。你们懂得,功能还的正常改。不过二狗发现这个bug特别小,对项目其他部分不造成不可预知的问题,所以直接在release分支上改了,然后愉快的发布了版本1.0.版本上线后,二狗将这个分支分别合并回了developmaster分支,然后删除了这个分支。

    • Hotfix branches:这个分支主要为修复线上特别紧急的bug准备的。

      必须从master分支创建,完成后合并回developmaster分支。

      如下图所示:
      这里写图片描述
      这个分支主要是解决线上版本的紧急bug修复的,例如突然版本V0.1上有一个致命bug,必须修复。那么我们就可以从master 分支上发布这个版本那个时间点 例如 tag v0.1(一般代码发布后会及时在master上打tag),来创建一个 hotfix-v0.1.1的分支,然后在这个分支上改bug,然后发布新的版本。最后将代码合并回developmaster分支。

    实例:某天夜里二狗正在和女朋友嘿咻呢,突然项目经理打来电话:“二狗啊,线上出了个大问题,大量用户无法登录,客服电话已经被打爆了,你紧急处理一下”。二狗心中默默骂道:日了个狗,然后就爬起来去改代码了。二狗先找到master分支上tag v0.1 的地方,然后新建了hotfix-v0.1.1 分支,默默的修bug去了。经过一个多小时的奋战,终于修复了,然后二狗改了版本号,发布了新版本。二狗将这个分支分别合并回了developmaster分支后删除了这个分支。终于搞定了,回头看看床上的女票已经进入了梦乡,二狗贼心不死,上前挑逗,此刻女票将满腹怨气集于一点,使出凌空一脚将其登于床下,随后甩一枕于二狗,二狗会意,趋客厅,抱枕卧于沙发。。。

    总结图

    上面的讲解最后汇成一张图
    这里写图片描述

    参考文章:A successful Git branching model

    展开全文
  • git-flow分支管理: master: 主分支,主要用来版本发布。 hotfix:线上 bug 紧急修复用到的临时分支。这个分支用来修复主线master的BUG release(预发布分支):release 分支可以认为是 master 分支的未测试版。...

    git-flow分支管理:

    在这里插入图片描述
    master: 主分支,主要用来版本发布。
    hotfix:线上 bug 紧急修复用到的临时分支。这个分支用来修复主线master的BUG
    release(预发布分支):release 分支可以认为是 master 分支的未测试版。比如说某一期的功能全部开发完成,那么就将 develop 分支合并到 release 分支,测试没有问题并且到了发布日期就合并到 master 分支,进行发布。
    develop(相当于release的预分支):日常开发分支,该分支正常保存了开发的最新代码。
    feature:具体的功能开发分支,只与 develop 分支交互。
    个人总结
    优点:
    1、经过多次实践,并行特性开发良好。
    2、适合大型项目开发,对小中型项目而言,过于繁杂,降低敏捷性。
    3、公司协同性比较高的话适合使用,或者公司有专门的git管理部门统一管理分支。
    缺点:
    1、从项目开始到上线过程中需要开的新分支过多不易维护,而且多分支容易出错。
    2、对于测试来说增加工作量,develop一套分支代码会同时承载两个环境,一个dev环境供开发使用,一个test环境供测试使用。
    所以测试过程先是开发人员在feature分支自测,然后是测试人员在dev环境测试,之后是在release环境还要测试,最后才能合到master上线。
    当hotfix分支合并入到release分支的时候,release分支必须得再次验证,纵使release上的功能全都验证通过。(繁琐的自测和测试人员的重复测试流程,测试人员比较少或者有其他项目需要测试)拖长项目的迭代周期。
    3、对于项目经理而言,管理这些分支需要消耗比较多的精力,需要根据不同情况选择性的去拉取或者删除不同的分支,不仅在feature分支合并代码到dev时候,如果有并行诉求需及时判断并行中哪条是需要延时合入的,这在敏捷开发或者快速迭代过程中会有工作负担。
    而且在release分支上上行合并和下行合并时也会有问题,这里开发人员可以在release上进行修改代码。针对线上bug根据紧急程度由经理决定决定是否使用hotfix分支。
    4、分支越多,生命周期越短,这种出错的概率就越大。merge代码总是痛苦和易错的。在软件开发的世界里,如果一件事很痛苦,那就频繁地去做它。feature branch这个实践本身阻碍了频繁的merge: 因为不同feature branch只能从master或develop分支pull代码,而在较长周期的开发完成后才被merge回master。
    也就是说相对不同的feature branch,develop上的代码永远是过时的。如果feature开发的平均时间是一个月,feature A所基于的代码可能在一个月前已经被feature B所修改掉了,这一个月来一直是基于错误的代码进行开发,而直到feature branch B被merge回develop才能获得反馈,到最后merge的成本是非常高的。
    5、git-flow大量的合并冲突和对集成测试不友好。
    Aone-flow分支管理:
    它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点,同时规避掉 GitFlow 的那些繁文缛节。
    AoneFlow 只使用三种分支类型:master分支、feature分支、release分支,以及三条基本规则
    规则一(开始工作前,从主干创建特性分支)
    AoneFlow 的特性分支基本借鉴 GitFlow,没有什么特别之处。每当开始一件新的工作项(比如新的功能或是待解决的问题)的时候,从代表最新已发布版本的主干上创建一个通常以feature/前缀命名的特性分支,然后在这个分支上提交代码修改。也就是说,每个工作项(可以是一个人完成,或是多个人协作完成)对应一个特性分支,所有的修改都不允许直接提交到主干
    在这里插入图片描述

    规则二(通过合并特性分支,形成发布分支)
    AoneFlow 的发布分支设计十分巧妙,可谓整个体系的精髓。GitFlow 先将已经完成的特性分支合并回公共主线(即开发分支),然后从公共主线拉出发布分支。TrunkBased 同样是等所有需要的特性都在主干分支上开发完成,然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是,从主干上拉出一条新分支,将所有本次要集成或发布的特性分支依次合并过去,从而得到发布分支。发布分支通常以release/前缀命名。
    在这里插入图片描述
    规则三,发布到线上正式环境后,合并相应的发布分支到主干,在主干添加标签,同时删除该发布分支关联的特性分支。
    在这里插入图片描述
    当一条发布分支上的流水线完成了一次线上正式环境的部署,就意味着相应的功能真正的发布了,此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支,还应该清理掉已经上线部分特性分支。与 GitFlow 相似,主干分支上的最新版本始终与线上版本一致,如果要回溯历史版本,只需在主干分支上找到相应的版本标签即可。

    除了基本规则,还有一些实际操作中不成文的技巧。比如上线后的 Hotfix,正常的处理方法应该是,创建一条新的发布分支,对应线上环境(相当于 Hotfix 分支),同时为这个分支创建临时流水线,以保障必要的发布前检查和冒烟测试能够自动执行。但其实还有一种简便方法是,将线上正式环境对应的发布分支上关联的特性分支全部清退掉,在这个发布分支上直接进行修改,改完利用现成的流水线自动发布。如果非得修一个历史版本的 Bug 怎么办呢?那就老老实实的在主干分支找到版本标签位置,然后从那个位置创建 Hotfix 分支吧,不过由于阿里的产品大多是线上 SaaS 业务,这样的场景并不多见。

    正是这些简单的规则,组成了 AoneFlow 独树一帜的核心套路。

    个人总结:
    规则易懂,三条规则。
    它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点,同时规避掉 GitFlow 的那些繁文缛节。
    AoneFlow 只使用三种分支类型:master分支、feature分支、release分支,以及三条基本规则。
    一个主干分支+N个特性分支+N个发布分支
    相对git-flow而言的优势:
    1、AoneFlow 的发布分支是相对固定的,因此相比 GitFlow 更易于进行持续集成。
    2、经过阿里团队长期实践,稳定性很高。项目管理相比却更加容易和高效,去除一些繁琐步骤。
    3、每次有新需求时,从当前主干分支拉取一个特性分支。多个特性分支可同步开发,到发布时间节点时,根据不同的环境合并不同的分支。
    4、对于维护不同环境和不同版本的情况下非常适用,不会产生多余的分支,主干分支与线上环境保持一致。
    使用Aone-flow最好有良好的代码规范和配套的工具,比如:用于线上发布的代码,不可以使用包含“SNAPSHOT 版本”(即未正式发布版本)的依赖包,从而确保每次构建出的产物都是一致的等等细节需要关注。工具考虑的话可以了解一下阿里的云效。
    总体而言,Aone-flow相对于不同项目的管理而言,相比git-flow我觉得更加高效。分支方面可由相应组长或者项目经理进行管理,工作量也不算大。

    展开全文
  • 2、feature1 分支操作、 ( 1 ) 创建 feature1 分支 ( 2 ) 修改 feature1 分支 ( 3 ) 提交 feature1 分支 ( 4 ) 推送 feature1 分支 3、master 分支操作、 ( 1 ) 切换 master 分支 ( 2 ) 修改 master 分支 ( 3 ) 提交...
  • Git 代码分支管理 / 版本管理

    千次阅读 2019-09-08 19:16:06
    Git 代码分支管理 / 版本管理 在使用 Git 时,基本不可能只有一个分支。 即使只有一个人发开,也会考虑代码的安全而分多个分支。多人协同开发时,可能每个人在不同的分支开发,也可能不同团队在不同的分支开发,...
  • Git 分支管理 项目开发过程中不同的开发场景需要在不同的分支上实现,比如: 不同环境的分支:dev/qa/prod/test 等 不同版本的分支 …… 下面介绍分支的创建、合并分支、合并某一次提交等命令 一、创建分支 1、...
  • 1、避免编译不通过的代码 合入开发分支,导致其他开发人员获取到编译失败代码。 2、避免本地代码规范检查不完整,将 有缺陷的代码合入开发分支。 方案图示: 方案实施操作手册: 1、开发人员角色设置为 ...
  • Git flow分支管理策略

    千次阅读 2019-06-12 14:58:28
    文章目录Git flow分支管理策略Git flow分支管理策略[1] Master和Develop分支[2] Feature分支[3] Release分支[4] Hotfix分支参考文档 Git flow分支管理策略 Git flow分支管理策略 ​ Git flow分支管理策略是一种Git...
  • 代码分支管理规范

    千次阅读 2019-01-09 13:07:15
    代码分支管理规范:(主要基于GIT,但SVN也可借鉴)   核心思想: 控制代码提交权限,保证主分支和tag分支都是经过测试验证的,保证测试分支不被随意更改。 另外支持对提交的代码进行审查。 支持多...
  • git分支管理规范和gitee上分支开发

    千次阅读 2019-05-11 22:53:06
    初始化仓库 git init 初始化master ...创建开发分支 git branch develop git checkout develop 开发一个功能 vim dev1.txt git add . git commit -m "完成dev功能的开发" 开发新特性1 git branc...
  • jenkins分支管理

    千次阅读 2019-07-30 20:05:26
    jenkins分支管理 一般项目默认是选定一个分支的,但是如果有多个分支就要设置多个项目这样很麻烦 前提准备 jenkins上有个Git Parameter插件可以用来分支构建 下载完插件后准备项目  码云设置双分支 master...
  • GitLab分支管理规范

    千次阅读 2019-02-11 09:21:56
    本规范用于描述日常研发流程中关于GitLab上代码分支使用的规则,大家共同严格遵守规范,避免出现分支管理混乱现象,保证日常的发版上线工作顺利进行。Workspace:工作区,平时我们写代码的地方。Index:暂存区,写完...
  • 代码分支管理

    千次阅读 2018-08-16 16:24:13
    没有一个好点的版本控制和管理是个很头疼的事情; 举个栗子:你正在做新项目新需求的开发,但是现在有个紧急的Bug需要修改,老板说今天修改完成晚上给测试,第二天紧急更新APP,现在的新需求还未开发完成不一起...
  • git的分支管理(详细版)

    万次阅读 多人点赞 2020-12-21 16:55:09
    git的分支管理 分支之间彼此互不干扰,各自完成各自的工作和内容,最后再 合并到总分支(原分支) 上,安全、不影响其他分支工作 查看当前工作在那个分支 git branch # 返回 # * master master分支 从项目创建之初...
  • git分支管理规范

    千次阅读 2020-05-21 17:42:49
    分支种类 主分支(master) 开发分支(develop) 功能分支(feature) 修复分支(hotfix) 预发布分支(release) 分支描述 Master:主分支,创建 Repository 时默认会生成一个 master 分支。通常情况下 master...
  • git bug分支管理

    千次阅读 2020-06-16 11:16:28
    有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。 当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一...
  • 学习阿里的分支管理模式

    千次阅读 2019-06-21 17:13:40
    对于公司的分支管理,只是觉得很乱,但怎么改善也没啥好想法。 今天看到了阿里的林帆同学的博客,总结的挺好的。摘抄一下。 文中所有图片,都是来自林帆同学的博客,因为微信不让引用图片,所以拷贝过来的,请见谅。...
  • 说到分支管理模式,我们最耳熟能详的莫过于 TrunkBased 和 GitFlow。TrunkBased 模式 是持续集成思想所崇尚的工作方式,它由单个主干分支和许多发布分支组成,每个发布分支在特定版本的提交点上从主干创建出来,用来...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 305,140
精华内容 122,056
关键字:

分支管理

友情链接: DynamicLayoutTest.rar