git分支管理及策略

Git 的默认分支就是 master。你所作的commit会在master分支上自动移动。 在多次提交操作之后,master分支指向最后那个commit object(提交对象链)。

Git 的 "master" 分支并特殊,跟其它分支没有区别。 之所以几乎每一个仓库都有 master 分支,是因为 git init 命令默认创建它。

但很多时候听别人说master分支,往往有一种 这个分支是稳定、无bug的分支。而develop往往预示这新功能,不稳定的分支。这和分支策略有关,但本质上这两个分支没区别。

一.分支管理

1.分支创建

通过git branch来查看和创建分支。

创建标签记在HEAD指针所指向的提交点创建tag(就是当前所在分支)

创建dev分支:git branch dev

此时有两个分支,一个是刚创建的分支dev 一个是默认分支master

分支切换到dev:git checkout dev

创建分支与切换分支同时完成:git checkout -b dev2

这时我们在dev2分支创建一个文件A.txt并且提交。我们发现在dev2分支可以看到这个文件,当我们切换会master时候无法看到这个文件。

2.分支删除

git branch -d dev2

强制删除git branch -D dev2

不能删除自己所在的分支

我们可以切换到master删除一个合并后的或者没有发生变化的分支

3.分支合并

git merge dev2

4.分支的本质

master指向的是提交

HEAD是指向当前的分支,当前在哪个分支就指向哪个分支

5.分支的冲突

两个分支修改同一文件时合并出现冲突

我们需要手工删除冲突的修改内容再合并

二.git stash

git stash

会先把修改的内容做保存然后我们就可以切换到其他的分支

git stash list

列出stash保存的所有修改

git stash pop

将stash过的修改恢复出来。通过pop取出最近的恢复并且删除stash中的修改

三.分支管理策略

(重要)

从上图可以看到主要包含下面几个分支:

master:git默认主分支(这里不作操作)。

stable:稳定分支,替代master,主要用来版本发布。

develop:日常开发分支,该分支正常保存了开发的最新代码。

feature:具体的功能开发分支,只与 develop 分支交互。

release:release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成,那么就将 develop 分支合并到 release分支,测试没有问题并且到了发布日期就合并到 stable分支,进行发布。

bugfix:线上 bug 修复分支。

1.主分支

因为master分支我们不作操作,所以针对stable和develop这两个主分支来讲解。

stable分支:用来发布,管理着多个稳定的版本。

develop分支:就是我们日常开发的分支。

使用这两个分支就具有了最简单的开发模式:develop 分支用来开发功能,开发完成并且测试没有问题后,则将 develop 分支的代码合并到 stable分支并发布。

2.辅助分支

通过这些分支,我们可以做到:团队成员之间并行开发,增加新功能更加容易,可以同时进行开发和版本发布、线上bug修复等

2.1Feature分支

Feature 分支用来开发具体的功能,一般基于develop分支,最后完成功能后再合并到develop分支。

比如,目前我们针对develop分支来做功能开发,在开发的过程中会有紧急需求需要开发,且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发,发布并进行测试,完成之后再合并到develop分支上。

2.2release分支

release分支作为预发布分支,release 分支从 develop 分支 fork 出来,最终会合并到 develop 分支和 stable 分支,合并到 stable分支上就是可以发布的代码了。

为什么我从develop分支fork出来,还要合并到develop分支中呢?因为我们在release分支上难免会有bug产生,修复bug也是在release分支上,所以必须要合并到develop分支。

2.3bugfix分支

bugfix 分支用来修复线上bug。当线上代码出现 bug 时,我们基于 stable 分支开一个bugfix分支,修复 bug之后再将 bugfix分支合并到stable分支并进行发布,同时develop 分支作为最新最全的代码分支,bugfix分支也需要合并到 develop 分支上去。

相关推荐
our_times6 小时前
# Git 高频命令实战指南:从日常开发到进阶协作
git
PBitW7 小时前
git 中容易遗忘的点 (二) ⚡⚡⚡
前端·git·面试
PBitW7 小时前
git 中容易遗忘的点 (三) 🚀🚀🚀
前端·git·面试
郑州光合科技余经理10 小时前
家政预约小程序后端源码深度剖析:支付回调实战
java·开发语言·前端·git·小程序·架构·php
北极糊的狐11 小时前
钉钉小程序 Git 版本管理完整流程
git·小程序·钉钉
Fzuim20 小时前
当 AI 也成为提交者:ThinkFlow 的 Git 提交规范,是怎么定的
git·agent·thinkflow
CodexDave1 天前
数据库连接池耗尽:排查顺序与三层兜底
服务器·前端·数据库·git·云原生·容器·kubernetes
乐观的Terry1 天前
5、发布系统-Git 集成
大数据·git·elasticsearch
不怕犯错,就怕不做1 天前
GIT的简单打patch应用format-patch and git am
linux·git·全文检索
Byron Loong1 天前
【Git】如何检查 Ubuntu 系统上 gitLab 是否开启
git·ubuntu·gitlab