Git Workflow简介

1. Git WorkFlow介绍

Git Flow是构建在Git之上的一个组织软件开发活动的模型,是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。

2010年5月,在一篇名为“一种成功的Git分支模型”的博文中,@nvie介绍了一种在Git之上的软件开发模型。通过利用Git创建和管理分支的能力,为每个分支设定具有特定的含义名称,并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离。这种软件开发的活动模型被nwie称为“Git Flow”。

一般而言,软件开发模型有常见的瀑布模型、迭代开发模型、以及最近出现的敏捷开发模型等不同的模型。每种模型有各自应用场景。Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题。因此,Git flow可以很好的于各种现有开发模型相结合使用。

image

2. Git VS SVN

SVNGit
分布式管理集中式管理
元数据存储文件存储
offline logonline log
有本地分支无本地分支
没有全局版本号有全局版本号
内容完整性(SHA-1)N/A
github,gitlab等配套N/A

3.分支

3.1 历史分支(Master , Develop)

Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史,而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。
历史分支

3.2 功能分支(Feature)

每个新功能位于一个自己的分支,这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支,而是使用develop分支作为父分支。当新功能完成时,合并回develop分支。 新功能提交应该从不直接与master分支交互。

功能分支

3.3 发布分支(Release)

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

使用一个用于发布准备的专门分支,使得一个团队可以在完善当前的发布版本的同时,另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段(比如,可以很轻松地说,『这周我们要做准备发布版本4.0』,并且在仓库的目录结构中可以实际看到)。

发布分支

3.4 维护分支(Hotfix)

维护分支或说是热修复(hotfix)分支用于生成快速给产品发布版(production releases)打补丁,这是唯一可以直接从master分支fork出来的分支。 修复完成,修改应该马上合并回master分支和develop分支(当前的发布分支),master分支应该用新的版本号打好Tag。

为Bug修复使用专门分支,让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。

维护分支

4. 实践

  • 初始化
git flow init
  • 开发一个功能
git flow feature start <your feature>
git flow feature finish <your feature>
  • 完成开发一个功能
git flow feature publish <name>
git flow feature pull <remote> <name>
  • 发布版本
git flow release start <release> 
git flow release finish <release>
  • 修补bug
git flow hotfix start <release> 
git flow hotfix finish <release>

5.常用命令

创建分支: git branch mybranch
切换分支: git checkout mybranch
创建并切换分支: git checkout -b mybranch
更新master主线上的东西到该分支上:git rebase master
切换到master分支:git checkout master
更新mybranch分支上的东西到master上:git rebase mybranch
提交:git commit -a
对最近一次commit的进行修改:git commit -a –amend
commit之后,如果想撤销最近一次提交(即退回到上一次版本)并本地保留代码:git reset HEAD^
合并分支:(merge from) git checkout master
$ git merge mybranch (merge from mybranch)
删除分支: git branch -d mybranch
强制删除分支: git branch -D mybranch
列出所有分支: git branch
查看各个分支最后一次提交: git branch -v
查看哪些分支合并入当前分支: git branch –merged
查看哪些分支未合并入当前分支: git branch –no-merged
更新远程库到本地: git fetch origin
推送分支: git push origin mybranch
取远程分支合并到本地: git merge origin/mybranch
取远程分支并分化一个新分支: git checkout -b mybranch origin/mybranch

6. 学习资料推荐

  1. Git的资料整理
  2. Pro Git book
  3. 猴子都能懂的Git入门系列
Git workflow 是指在使用 Git 版本控制时,团队协作开发时所采用的工作流程。常见的 Git workflow 包括集中式工作流、功能分支工作流、Gitflow 工作流、Forking 工作流等。 1. 集中式工作流(Centralized Workflow):团队成员直接在主分支(通常是 master 或 main)上进行开发,每个开发者都有自己的本地分支,完成开发后将本地分支合并到主分支中。 2. 功能分支工作流(Feature Branch Workflow):每个功能或任务都在独立的分支上进行开发,开发完成后合并到主分支。这种工作流程使得团队成员可以并行开发多个功能,减少代码冲突。 3. Gitflow 工作流:Gitflow 是一种在功能分支工作流基础上扩展出的工作流程,主要区别是引入了额外的分支来管理特性开发、发布和维护等不同阶段。它包括主分支(master 或 main)、开发分支(develop)、特性分支(feature)、发布分支(release)、修复分支(hotfix)等。 4. Forking 工作流:适用于开源项目,每个贡献者通过 Fork 项目得到自己的独立仓库,在自己的仓库中进行开发,然后通过 Pull Request 将修改提交给原项目。原项目的维护者可以审查和合并这些提交。 这些只是一些常见的 Git workflow,实际上还有很多其他的变种和组合。选择适合团队的工作流程取决于项目的规模、团队的协作方式和开发流程等因素。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值