Git工作流模式及命令的使用讲解

目录
  • Git的工作方式
    • 集中式工作流
    • 功能分支工作流
    • Gitflow工作流
      • 维护分支
      • 工作流程
    • Forking工作流
  • Pull Request

Git的工作方式

分为集中式工作流、功能分支工作流、Gitflow工作流和Forking,其中集中式工作流和功能分支工作流是已经使用过的,Gitflow和Forking两种工作流暂时没有使用过。

集中式工作流

一个远程仓库,一个主分支master,团队每个成员都有一个本地仓库,在本地仓库中进行代码的编辑、暂存和提交工作:

git add <some file> 或 git add .>
//`some file`代表要暂存的文件,`.`代表工作目录下的所有文件
gie commit -m "一些描述"
//提交文,描述指的是本次提交修改了什么功能或者修改了什么bug,方便以后的查看
git push -u origin master
//-u选项设置本地分支去跟踪远程对应的分支。设置好跟踪的分支后,就可以使用git push命令省去指定推送分支的参数
//发布本地仓库到远程的中央仓库中,origin是远程仓库名,master是参数告诉Git的分支,master代表主分支,当然分支可以不是主分支

注意:在一种情况下push命令会出错,即如果小明第一次发布代码到远程仓库,此时小红在 本地开发自己的功能,那么在小红push自己的本地库到远程的时候会报错,原因是小红的本地库和远程库有分歧,需要先pull远程库到本地,与本地库合并之后再push到远程库。

功能分支工作流

在集中式工作流的基础上,为各个新功能分配一个专门的分支来开发,即在master主分支外在创建一个分支,程序员开发的新功能全部push到此分支上,等到功能成熟的时候再把此分支合并到主分支master上

git checkout -b newbranch master
//checkout代表创建切换带新分支newbranch
//-b代表如果新分支不存在则会创建一个新分支
//最后的master代表新分支是基于主分支创建的

新分支创建之后,对其的编辑、暂存和提交工作与之前一样,对其push的命令变为

git push origin newbranch

等到新功能完善之后,通过以下命令:

git checkout mastergit pullgit pull origin newbranchgit push

首先git checkout master切换到主分支,然后执行git pull把本地仓库的主分支上传到远程库,再执行git pull origin newbranch保证合并newbranch分支和已经和远程一致的本地master分支,你可以使用简单git merge newbranch命令,但前面的命令可以保证总是最新的新功能分支。 最后把更新的master分支重新push到远程库。

Gitflow工作流

Gitflow工作流没有用超出功能分支工作流的概念和命令,而是为不同的分支分配一个很明确的角色,并定义分支之间如何和什么时候进行交互。
除了有master主分支(用于存储正式发布的历史)外,还有一个作为功能集成分支的develop分支。当初始化完成后,某个程序员想要开发一个性能,并不是直接从master分支上拉出新分支,而是使用develop分支作为父分支,当新功能完成后,再合并会父分支,新功能的提交并不与master分支直接交互。

一旦develop分支上有了做一次发布(或者说快到了既定的发布日)的足够功能,就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环,所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了,发布分支合并到master分支并分配一个版本号打好Tag。 另外,这些从新建发布分支以来的做的修改要合并回develop分支。

维护分支

维护分支或说是热修复(hotfix)分支用于生成快速给产品发布版本(production releases)打补丁,这是唯一可以直接从master分支fork出来的分支。 修复完成,修改应该马上合并回master分支和develop分支(当前的发布分支),master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支,让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。

工作流程

为master分支配套一个develop分支

git branch develop
git push -u origin develop

以后这个分支将会包含了项目的全部历史,而master分支将只包含了部分历史。其它开发者这时应该克隆中央仓库,建好develop分支的跟踪分支:

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

现在每个开发都有了这些历史分支的本地拷贝。
小红和小明开团队成员始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于master分支,而是应该基于develop分支:

git checkout -b some-feature develop

他们用老套路添加提交到各自功能分支上:编辑、暂存、提交:

git status
git add <some-file>
git commit

添加了提交后,功能OK了之后,如果团队使用Pull Requests,这时候可以发起一个用于合并到develop分支。 否则她可以直接合并到她本地的develop分支后push到中央仓库:

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令在合并功能前确保develop分支是最新的。注意,功能决不应该直接合并到master分支。 冲突解决方法和集中式工作流一样。

Forking工作流

分布式工作流,充分利用了Git在分支和克隆上的优势,既可以管理大团队的开发者(developer)和接受不信任贡献者(contributor)的提交。这种工作流使得每个开发者都有一个服务端仓库(此仓库只有自己可以push,但是所有人都可以pull修改),每个程序员都push代码到自己的服务端仓库,但不能push到正式仓库,只有项目维护者才能push到正式仓库,这样项目维护者可以接受任何开发者的提交,但无需给他正式代码库的写权限。
这种工作流适合网上开源社区的开源项目,大家统一对项目做贡献,但是有一个人或一个团队作为开发者来管理项目,所有的贡献者的代码由开发者审核,其功能完善之后再由开发者push到正式仓库中。

Pull Request

Pull Request是一个为讨论提交功能的专门论坛,是一个友好的web界面(在个人github项目中也有这样一个选项),大家在其中做一些Code Review的工作,把结果反馈到Pull Request中,还可以在其中push新的提交微调功能,等到讨论结束后醒目维护者合并所有的功能到官方仓库中,关闭Pull Request。

发起一个Pull Request,就是要请求另一个开发者来pull自己仓库的一个分支到它的仓库中,因此需要提供四个信息:源仓库、源分支、目的仓库、目的分支。

Pull Request可以用于上述除了集中式工作流的其他三种工作流,因为其要求要么分支不同,要么仓库不同,而集中式工作流只有一个仓库,一个master分支。

例:

在功能分支工作流中使用Pull Request

功能分支工作流只有一个公开的仓库,所以Pull Request的目的仓库和源仓库总是同一个。 通常开发者会指定他的功能分支作为源分支,master分支作为目的分支。

收到Pull Request后,项目维护者要决定如何做。如果功能没问题,就简单地合并到master分支,关闭Pull Request。但如果提交的变更有问题,他可以在Pull Request中反馈。之后新加的提交也会评论之后接着显示出来。

在功能还没有完全开发完的时候,也可能发起一个Pull Request。 比如开发者在实现某个需求时碰到了麻烦,他可以发一个包含正在进行中工作的Pull Request。 其它的开发者可以在Pull Request提供建议,或者甚至直接添加提交来解决问题。

参考:http://shouce.jb51.net/gitbook/Distributed-Git/Distributed-Workflows.html

以上就是Git工作流模式及命令的使用讲解的详细内容,更多关于Git的工作流模式命令使用的资料请关注我们其它相关文章!

(0)

相关推荐

  • Git工作流演示及三种工作方式

    目录 集中式工作流(不常用) Forking 工作流(偶尔使用) GitFlow 工作流(最流行) Git工作流演示 集中式工作流(不常用) 集中式工作流像SVN一样,以中央仓库作为项目所有修改的单点实体.所有修改都提交到 Master分支上.这种方式与 SVN 的主要区别就是开发人员有本地库,但是Git 很多特性并没有用到. Forking 工作流(偶尔使用) Forking 工作流是在 GitFlow 基础上,充分利用了 Git 的 Fork 和 pull request 的功能以达到代码审

  • SVN与Git版本控制的优缺点差异全面分析

    目录 一.集中式vs分布式 1.Subversion属于集中式的版本控制系统 Subversion的特点概括起来主要由以下几条: 2.Git属于分布式的版本控制系统 Git具有以下特点: 二.版本库与工作区 1.SVN的版本库和工作区是分离的 2 .Git 的版本库和工作区如影随形 三.全局版本号和全球版本号 1. SVN与Git版本号比较 四.部分检出 1. SVN的部分检出 2. Git的检出 五.更新和提交 1.更新操作 2.SVN中的commit命令 3.Git中的暂存区域(stage)

  • Git在项目协作开发中所解决问题

    目录 1.Git的历史 Tips: 2.Git的特点 3.Git在项目协作开发中所解决的问题 1.Git的历史 Git是目前世界上最先进的分布式版本控制系统,开源.免费. Git 是 Linus (林纳斯)为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件. Tips: Linus在1991年创建Linux,现在已经成为最大的服务器系统软件了. Linux的壮大是靠全世界热心的志愿者: 在2002年以前,世界各地的志愿者把源代码文件发给Linus,然后由Linus本人通过手工方

  • git基础之各版本控制系统介绍

    目录 1.什么是版本控制系统 2.我们为什么要用版本控制 3.版本管理系统的演变 (1)本地版本控制系统 (2)集中化版本控制系统 (3)分布式版本控制系统 1.什么是版本控制系统 版本控制是一种记录一个或若干个文件内容变化,以便将来查阅特定版本修订情况的系统.版本控制系统不仅可以应用于软件源代码的文本文件,而且可以对任何类型的文件进行版本控制. 有了它你就可以将某个文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状态,你可以比较不同版本文件的变化细节,查出最后是谁修改了哪个地方.也

  • Git工作流模式及命令的使用讲解

    目录 Git的工作方式 集中式工作流 功能分支工作流 Gitflow工作流 维护分支 工作流程 Forking工作流 Pull Request Git的工作方式 分为集中式工作流.功能分支工作流.Gitflow工作流和Forking,其中集中式工作流和功能分支工作流是已经使用过的,Gitflow和Forking两种工作流暂时没有使用过. 集中式工作流 一个远程仓库,一个主分支master,团队每个成员都有一个本地仓库,在本地仓库中进行代码的编辑.暂存和提交工作: git add <some fi

  • 详解MySQL中EXPLAIN解释命令及用法讲解

    1,情景描述:同事教我在mysql中用explain,于是查看了一番返回内容的含义 2,现就有用处的内容做如下记录: 1,explain显示了mysql如何使用索引来处理select语句以及连接表.可以帮助选择更好的索引和写出更优化的查询语句. 使用方法,在select语句前加上explain就可以了: explain select count(DISTINCT uc_userid) as user_login from user_char_daily_gameapp_11 where uc_d

  • Python socket套接字实现C/S模式远程命令执行功能案例

    本文实例讲述了Python socket套接字实现C/S模式远程命令执行功能.分享给大家供大家参考,具体如下: 一. 前言 要求: 使用python的socket套接字编写服务器/客户机模式的远程命令执行脚本. serverCmd.py 远程机器上用来执行客户端发送命令的脚本 clientCmd.py 本地机器上,向远程服务器发送命令的脚本 servers.txt  本地机器上,存放所有的远程服务器IP地址文件(仅支持第一个IP) 发送:cmd [command]形式消息,让远程主机执行命令(本

  • 详解Linux中退出编辑模式的命令

    vim 有三种模式,注意:这三种模式有很多不同的叫法,我这里是按照鸟哥的linux书中的叫法. 一般指令模式.编辑模式.指令列命令模式 1.vim 文件名      进入一般模式: 2.按 i 进行编辑   进入编辑模式 :(或者I, o, O, a, A, r, R) 3.编辑结束,按ESC 键 跳到一般模式模式: 4.按:     进入指令列命令模式 : 进入指令列模式后的明林如下 1.保存不退出: :w 保存文件但不退出vi 编辑 :w! 强制保存,不退出vi 编辑 :w file 将修改

  • git 使用及常用命令

    git在团队项目中的使用流程 1.首先从一个git远程仓库中clone项目到本地 git clone 仓库地址 2.创建开发分支 一般我们写代码不会在master分支上面写,而是新建一个分支 git checkout -b test 3.在test分支上面进行代码修改,比如完成某一项功能的开发 4.修改完之后提交代码到test分支 git add . git commit -m "your comment" 5.review代码(非必需) 在test分支上面开发完某一个功能之后,建议自

  • Java使用Lettuce客户端在Redis在主从复制模式下命令执行的操作

    1 redis主从复制的概念 多机环境下,一个redis服务接收写命令,当自身数据与状态发生变化,将其复制到一个或多个redis.这种模式称为主从复制.在redis中通过命令salveof命令让执行该命令的redis复制另一个redis数据与状态.我们将主服务器称为master,从服务器称为slave. 主从复制保证了网络异常正常时,网络断开重的情况下将数据复制.网络正常时master会通过发送命令保持对slave更新,更新包括客户端的写入,key的过期或被逐出等网络异常,master与slav

  • 让DOSBox启动后自动执行命令的方法讲解

    使用DOSBox,可以在win下模拟DOS,自些好玩的工作.例如,学习8086汇编. 每次启动DOSBox后,都要挂载.转盘符.遇上调试的程序老死,就不好玩了. 可以想想办法,让这些固定"套路"自动化. 注意到DOSBox初启时,有一个窗口,如下显示: 就这个文件,掌管DOSBox启动后执行的命令. 找到这个文件. 用记事本就可以编辑. 拉到最下面,找到[autoexec]部分,补充命令如下: 然后重启DOSBox就行了. 截屏?不给. 自己做吧! 总结 以上就是这篇文章的全部内容了,

  • Redis中scan命令的深入讲解

    前言 熟悉Redis的人都知道,它是单线程的.因此在使用一些时间复杂度为O(N)的命令时要非常谨慎.可能一不小心就会阻塞进程,导致Redis出现卡顿. 有时,我们需要针对符合条件的一部分命令进行操作,比如删除以test_开头的key.那么怎么获取到这些key呢?在Redis2.8版本之前,我们可以使用keys命令按照正则匹配得到我们需要的key.但是这个命令有两个缺点: 没有limit,我们只能一次性获取所有符合条件的key,如果结果有上百万条,那么等待你的就是"无穷无尽"的字符串输出

  • C语言之预处理命令的深入讲解

    c提供的预处理功能有: 宏定义 文件包含 条件编译 为了与其她c语句区分,命令经常以符号"#"开头. 宏定义 #define 标识符 字符串 可以避免反复输入字符串,后面不加:宏定义在默认时的有效范围是全部.也可以用#undef终止宏定义区域. 不含参数 宏展开带入程序 含参数 #include<stdio.h> #define PI 3.1415 #define S(r) PI*r*r int main() { int a; float area; scanf("

随机推荐