gitflow分支管理模型

2024-06-19 13:18
文章标签 模型 管理 分支 gitflow

本文主要是介绍gitflow分支管理模型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

http://www.berlinix.com/it/gitflow.php


http://www.berlinix.com/it/gitflow.php



http://www.berlinix.com/it/git.php

http://www.berlinix.com/it/git.php



gitflow分支管理模型

gitflow的分支类型：

  • master分支（1个）
  • develop分支（1个）
  • feature分支。同时存在多个。
  • release分支。同一时间只有1个，生命周期很短，只是为了发布。
  • hotfix分支。同一时间只有1个。生命周期较短，用了修复bug或小粒度修改发布。

在这个模型中，master和develop都具有象征意义。master分支上的代码总是稳定的（stable build），随时可以发布出去。develop上的代码总是从feature上合并过来的，可以进行Nightly Builds，但不直接在develop上进行开发。当develop上的feature足够多以至于可以进行新版本的发布时，可以创建release分支。

release分支基于develop，进行很简单的修改后就被合并到master，并打上tag，表示可以发布了。紧接着release将被合并到develop；此时develop可能往前跑了一段，出现合并冲突，需要手工解决冲突后再次合并。这步完成后就删除release分支。

当从已发布版本中发现bug要修复时，就应用到hotfix分支了。hotfix基于master分支，完成bug修复或紧急修改后，要merge回master，打上一个新的tag，并merge回develop，删除hotfix分支。

由此可见release和hotfix的生命周期都较短，master/develop虽然总是存在但却不常使用。

以上就是gitflow的基本概念了。下面是nvie（gitflow的提出者，一个荷兰人！） A successful Git branching model（发布于2010年月5日）一文的笔记。

从右看起：

  • 时间轴。
  • feature（玫红）。主要是自己玩了，差不多的时候要合并回develop去。从不与master交互。
  • develop（黄色）。主要是和feature以及release交互。
  • release（绿色）。总是基于develop，最后又合并回develop。当然对应的tag跑到master这边去了。
  • hotfix（红色）。总是基于master，并最后合并到master和develop。
  • master（蓝色）。没有什么东西，仅是一些关联的tag，因从不在master上开发。

接下来nvie说道自己喜爱git，因git改变了人们对合并/分支（merge/branches）的看法。从集中式的代码管理工具过来的人感到释放了（beware of merge conflicts, they bite you，注意合并冲突，它们会跳出来咬你！）。

gitflow实例

安装gitflow：

$ git clone --recursive git://github.com/nvie/gitflow.git
$ cd gitflow/
$ sudo make install
$ ls /usr/local/bin/git-flow
/usr/local/bin/git-flow

到项目根目录下执行gitflow，因为之前修改没有commit，所以gitflow初始化失败：

$ git flow init
fatal: Working tree contains unstaged changes. Aborting.

commit后再次进行gitflow初始化：

$ git commit -a -m "update Bash"
[master 8f5b874] update Bash4 files changed, 71 insertions(+), 5 deletions(-)[bailing@zhuji zhuji]$ git flow initWhich branch should be used for bringing forth production releases?- master
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? []

一路回车下来，各个分支名都按默认的设置。最后，当前分支已经被切换到了develop：

$ git branch
* developmaster

建立一个新的feature。git flow新建了功能分支feature/blog_builder，并在develop的基础上checkout了新分支：

$ git flow feature start blog_builder
$ git branchdevelop
* feature/blog_buildermaster

开发完成后执行如下命令：

$ git flow feature finish blog_builder
Summary of actions:
- The feature branch 'feature/blog_builder' was merged into 'develop'
- Feature branch 'feature/blog_builder' has been removed
- You are now on branch 'develop'

正如这条命令的总结所言，git flow为我们做了3件事：

  • 把feature/blog_builder合并到了develop。
  • 删除了feature/blog_builder分支。
  • 切换回develop分支。

接下来发布一个正常的版本：

$ git flow release start v0.5

一旦需要发布的版本确认无误可以发布后，执行命令：

$ git flow release finish v0.5
summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master'
- The release was tagged 'v0.5'
- Release branch has been back-merged into 'develop'
- Release branch 'release/v0.5' has been deleted

注意release/v0.5被合并到了master和develop分支，并打了个v0.5的tag，然后被删除，最后切换回了develop分支：

$ git branch
* developmaster

发布时只需将tag为v0.5的版本checkout出来部署即可：

$ git tag
v0.5

当上线后发现v0.5的bug，可以进行hotfix：

$ git flow hotfix start v0.5.1

此时gitflow从master分支上拉出一个hotfix/v0.5.1的分支，接下来在新分支上修改bug。最后执行命令：

$ git flow hotfix finish v0.5.1

这样hotfix/v0.5.1被merge到master/develop分支，打好v0.5.1这个tag，删除这个分支，切换回develop分支。

之后又是新一次的轮回，启动正常的feature开发。









-----------------------------




Git（the stupid content tracker）是一个源自Linux内核项目的源码管理工具。和传统的CVS、SVN不同，git是一个分布式源码管理工具。

Git命令简单说明
git init初始化一个本地的代码仓库。
git clone从远程复制一个代码仓库。
git configgit选项设置。
git add添加文件/目录。
git commit提交修改。
git status显示工作目录的状态以及缓冲区内的快照。
git log已提交快照的日志。
git branch创建分支。
git checkout迁出/拉出/切换到一个分支。
git merge合并分支。
git revert撤销commit快照。
git reset撤销本地工作目录的修改。
git clean删除代码仓库以外的文件。
git remote管理远程git。
git fetch从远程获取分支。
git pull从远程获取分支。
git push把代码推到远程分支。

基本概念

文件状态

Git仓库中的文件有几种状态：

  • untracked - 还没添加到仓库中。
  • unmodified - 自上次提交以来，文件未曾修改过。
  • modified - 文件修改了还没提交。
  • staged - 文件提交到了暂存区中。一旦执行git commit就会转换为unmodified状态。
Git文件状态

Git暂存区（Staged Area）的意思是：你把一个文件托付给Git跟踪（git add），然后又修改了它，此时这个文件就位于暂存区了。暂存区内的文件几乎只做一件事：等待你执行git commit，把它提交。

快照（snapshot）

Git与其他版本控制系统的区别在于：Git只关心文件是否变化，而不关心文件内容的变化。大多数版本控制系统都会忠实地记录版本间的文件差异（diff），但Git不关心这些具体差异（哪一行有什么变动），Git只关心哪些文件修改了哪些没有修改，修改了的文件直接复制形成新的blob（这就是所谓的快照snapshot）。当你需要切换到或拉出一个分支时，Git就直接加载当时的文件快照即可，这就是Git快的原因。说起来，这也是用空间换取时间的经典案例。

从这个角度看，Git更像是一个小型文件系统，并在这个系统上提供一系列的工具来辅助开发。

Git的地理观

Git是一个分布式的版本控制系统，因此没有所谓的中心。粗略来看Git可分为本地库（local repository）和远程库（remote repository），细致地看可分为以下几个部分：

  • Working Directory - 工作目录。Git仓库位于工作目录之下，工作目录下的文件有加入Git仓库（tracked）和没加入Git仓库（untracked）的区别。
  • Stage Area - 暂存区。如上所述，已加入Git仓库并被修改（尚未提交）的文件。
  • Local Repository - 本地仓库。
  • Remote Repository - 远程仓库。

文件通常是：加入Git仓库（git add）-> 修改后即位于暂存区 -> 提交到本地库（git commit） -> 推送到远程库（git push）。

origin/master

这里主要笔记一些在Git上下文中经常遇见的术语。origin/master指远程仓库origin的master分支。

远程仓库/分支

这样的形式。虽然Git是分布式的系统，但通常把git clone的源头叫做origin，origin也被视为中心仓库（Central Repository）。

git入门

创建目录，并用git init初始化：

$ mkdir learn-git && cd learn-git
$ git init
Initialized empty Git repository in /tmp/learn-git/.git/

从git init输出可知，git创建了一个名为.git的隐藏目录。

创建一个文件，并用git add添加到仓库，用git commit提交：

$ echo "hello git" > README.txt
$ git add .
$ git commit -m "readme file"
[master (root-commit) cd27ac1] readme file1 file changed, 1 insertion(+)create mode 100644 README.txt

接下来对已提交文件做一些修改，并新添加一个文件：

$ echo "learn files here" >> README.txt
$ cp ~/.vimrc .

用git diff查看文件差异（每次commit前应该先diff对比差异详情）：

$ git diff
diff --git a/README.txt b/README.txt
index 8d0e412..0219596 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1,2 @@hello git
+learn files here

差异对比可以用git diff --cached保存下来（如此差异则不输出到屏幕）。

用git status查看git仓库状态：

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   README.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .vimrc
no changes added to commit (use "git add" and/or "git commit -a")

这里显示README.txt被修改了，而.vimrc则等待添加。接下来，我们将.vimrc添加到git仓库中，且将所有修改一并提交（git commit -a）：

$ git commit -a -m "update readme && add vimrc"
[master f6162f0] update readme && add vimrc2 files changed, 123 insertions(+)create mode 100755 .vimrc

git log输出git日志，包括提交编号（如"f6162f04170e3665bc03744e43f764c903e4e38d"这样的字串）、提交者、提交日期和提交日志。

git log的其他输出：

$ git log -p                    # 详细日志，并输出到分页程序
$ git log --stat --summary

美化git log输出

$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --

修改全局配置：

$ git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --"
$ git lg

管理分支

创建一个分支：

$ git branch exp

查看当前git仓库的所有分支：

$ git branchexp
* master

切换到exp分支：

$ git checkout exp
Switched to branch 'exp'

修改文件，并提交：

$ echo "start branch: exp" >> README.txt 
$ git commit -a -m "modified readme in exp branch"
[exp 2e825a4] modified readme in exp branch1 file changed, 1 insertion(+)

切换回master分支：

$ git checkout master
Switched to branch 'master'

在master分支检查文件，可见exp分支的修改并没影响到master分支（注意，在exp分支的修改都已提交；如果没有提交，则切换回master分支会看到文件已变）。接下来我们制造一个冲突：

$ echo "return branch: master" >> README.txt                    
$ git commit -a -m "modified readme in master branch"
[master 8dd9fb2] modified readme in master branch1 file changed, 1 insertion(+)

用git merge exp合并分支：

$ git merge exp
Auto-merging README.txt
CONFLICT (content): Merge conflict in README.txt
Automatic merge failed; fix conflicts and then commit the result.

从git输出可见，git尝试自动合并但失败了，因此提示需要解决冲突再提交

用git diff查看差异，且差异文件被修改：

$ git diff
...
$ cat README.txt 
hello git
learn files here
<<<<<<< HEAD
return branch: master
=======
start branch: exp
>>>>>>> exp

手工解决冲突并再次提交：

(edit file)
$ git commit -a -m "do merge"

接下来，可以删除exp分支：

$ git branch -d exp
Deleted branch exp (was 2e825a4).

git branch -d删除分支时会检查分支是否完全合并到主干，如果不是，则会删除失败，并提示需要合并：

$ git branch exp                        # 建立exp分支
$ git checkout exp                      # 切换到exp分支
$ echo "exp again" >> README.txt        # 修改并提交
$ git commit -a -m "exp again"
[exp 868e68c] exp again1 file changed, 1 insertion(+)
$ git checkout master                   # 切换回master
Switched to branch 'master'
$ git branch -d exp                     # 删除失败
error: The branch 'exp' is not fully merged.
If you are sure you want to delete it, run 'git branch -D exp'.

可以用git branch -D exp忽略修改，完全删除分支：

$ git branch -D exp
Deleted branch exp (was 868e68c).

查看远端git

基础命令是：git remote show, git remote show X。

$ git remote show
origin
web

查看GitHub默认设置的origin

$ git remote show origin
* remote originFetch URL: git@github.com:berlinix/blog.gitPush  URL: git@github.com:berlinix/blog.gitHEAD branch: masterRemote branch:master trackedLocal branch configured for 'git pull':master merges with remote masterLocal ref configured for 'git push':master pushes to master (fast-forwardable)

git命令快查

以下列出一些常用的git命令

命令说明
基础操作
git init初始化git仓库
git add X添加X文件/路径到git仓库
git commit -m "COMMENTS"提交更新
分支管理
git branch X创建一个名为X的分支
git checkout X切换到X分支
git merge X自动合并X分支
git branch -d X删除X分支，需要先merge
git branch -D X强制删除X分支，忽略其修改，无须先merge
与远程git交互
git remote show显示远程git仓库
git remote show X显示远程git一个名为X的仓库
git push origin master更新提交到GitHub

Git日常问题

撤销commit

刚与master合并并提交后就后悔了现在要做的是撤销commit（revoke/undo merge/commit）。

查看当前所在分支：

$ git branchbs3
* coindevmaster

查看日志：

$ git log --oneline
9b7ba39 merged with master
73a66e8 update FAQ

用以下2个命令来撤销提交（把COMMIT_SHA替换为实际的SHA值；把HEAD~N中的N替换为一个数字，表示回退几步）：

$ git reset --hard COMMIT_SHA
$ git reset --hard HEAD~N

例如回退到合并前：

$ git reset --hard 73a66e8
HEAD is now at 73a66e8 update FAQ

回退后发现不对，因为现在这个commit还是在master中的（在merge之前master已经走的太远），赶紧再次reset到merge时的状态：

$ git reset --hard 9b7ba39
HEAD is now at 9b7ba39 merged with master

如此一来就是就是merge后commit之前的状态。接下来就是要完成undo merge（已经undo commit了）：

$ git revert -m 1 9b7ba39

这下就彻底回到merge前了，以防万一再次检查：

$ git diff --name-status master..coin

看起来没什么问题了，检查下日志：

$ git log --oneline
2691516 Revert "merged with master"
9b7ba39 merged with master
73a66e8 update FAQ

用git找回已删除文件

首先找到与目标文件相关的最后一次commit。如果目标文件没有出现在HEAD commit中，那么在这次commit时，文件就被删除了：

$ git rev-list -n 1 HEAD -- htdocs/myfile.php
1e8182f58dc038c8e6bc2025e8430f463d372030

接下来就是恢复工作了：

$ git checkout 1e8182f58dc038c8e6bc2025e8430f463d372030^ -- htdocs/myfile.php

合并分支的部分文件

有时候只想合并分支里的部分文件，而不是整个分支，可以用这个命令：

git checkout BRANCH FILE ...

例如，从test_branch分支中合并file_modified文件：

$ git checkout test_branch file_modified

参考Git Tip: How to "Merge" Specific Files from Another Branch。





这篇关于gitflow分支管理模型的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1075140。

相关文章

大模型研发全揭秘：客服工单数据标注的完整攻略

大模型研发全揭秘：客服工单数据标注的完整攻略

在人工智能（AI）领域，数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者，掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中，工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注，不仅能够帮助提升客服自动化系统的智能化水平，还能优化客户服务流程，提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行
阅读更多...
Andrej Karpathy最新采访：认知核心模型10亿参数就够了，AI会打破教育不公的僵局

Andrej Karpathy最新采访：认知核心模型10亿参数就够了，AI会打破教育不公的僵局

夕小瑶科技说 原创  作者 | 海野 AI圈子的红人，AI大神Andrej Karpathy，曾是OpenAI联合创始人之一，特斯拉AI总监。上一次的动态是官宣创办一家名为 Eureka Labs 的人工智能+教育公司 ，宣布将长期致力于AI原生教育。 近日，Andrej Karpathy接受了No Priors（投资博客）的采访，与硅谷知名投资人 Sara Guo 和 Elad G
阅读更多...
综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

LntonAIServer视频质量诊断功能中的抖动检测是一个专门针对视频稳定性进行分析的功能。抖动通常是指视频帧之间的不必要运动，这种运动可能是由于摄像机的移动、传输中的错误或编解码问题导致的。抖动检测对于确保视频内容的平滑性和观看体验至关重要。 优势 1. 提高图像质量 - 清晰度提升：减少抖动，提高图像的清晰度和细节表现力，使得监控画面更加真实可信。 - 细节增强：在低光条件下，抖
阅读更多...
Retrieval-based-Voice-Conversion-WebUI模型构建指南

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI（简称 RVC）模型是一个基于 VITS（Variational Inference with adversarial learning for end-to-end Text-to-Speech）的简单易用的语音转换框架。 具有以下特点 简单易用：RVC 模型通过简单易用的网页界面，使得用户无需深入了
阅读更多...
透彻！驯服大型语言模型（LLMs）的五种方法，及具体方法选择思路

透彻！驯服大型语言模型（LLMs）的五种方法，及具体方法选择思路

引言 随着时间的发展，大型语言模型不再停留在演示阶段而是逐步面向生产系统的应用，随着人们期望的不断增加，目标也发生了巨大的变化。在短短的几个月的时间里，人们对大模型的认识已经从对其zero-shot能力感到惊讶，转变为考虑改进模型质量、提高模型可用性。 「大语言模型(LLMs)其实就是利用高容量的模型架构（例如Transformer）对海量的、多种多样的数据分布进行建模得到，它包含了大量的先验
阅读更多...
图神经网络模型介绍（1）

图神经网络模型介绍（1）

我们将图神经网络分为基于谱域的模型和基于空域的模型，并按照发展顺序详解每个类别中的重要模型。 1.1基于谱域的图神经网络         谱域上的图卷积在图学习迈向深度学习的发展历程中起到了关键的作用。本节主要介绍三个具有代表性的谱域图神经网络：谱图卷积网络、切比雪夫网络和图卷积网络。 （1）谱图卷积网络 卷积定理：函数卷积的傅里叶变换是函数傅里叶变换的乘积，即F{f*g}
阅读更多...
秋招最新大模型算法面试，熬夜都要肝完它

秋招最新大模型算法面试，熬夜都要肝完它

💥大家在面试大模型LLM这个板块的时候，不知道面试完会不会复盘、总结，做笔记的习惯，这份大模型算法岗面试八股笔记也帮助不少人拿到过offer ✨对于面试大模型算法工程师会有一定的帮助，都附有完整答案，熬夜也要看完，祝大家一臂之力 这份《大模型算法工程师面试题》已经上传CSDN，还有完整版的大模型 AI 学习资料，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费
阅读更多...
【生成模型系列（初级）】嵌入（Embedding）方程——自然语言处理的数学灵魂【通俗理解】

【生成模型系列（初级）】嵌入（Embedding）方程——自然语言处理的数学灵魂【通俗理解】

【通俗理解】嵌入（Embedding）方程——自然语言处理的数学灵魂 关键词提炼 #嵌入方程 #自然语言处理 #词向量 #机器学习 #神经网络 #向量空间模型 #Siri #Google翻译 #AlexNet 第一节：嵌入方程的类比与核心概念【尽可能通俗】 嵌入方程可以被看作是自然语言处理中的“翻译机”，它将文本中的单词或短语转换成计算机能够理解的数学形式，即向量。 正如翻译机将一种语言
阅读更多...
软考系统规划与管理师考试证书含金量高吗？

软考系统规划与管理师考试证书含金量高吗？

2024年软考系统规划与管理师考试报名时间节点： 报名时间：2024年上半年软考将于3月中旬陆续开始报名 考试时间：上半年5月25日到28日，下半年11月9日到12日 分数线：所有科目成绩均须达到45分以上（包括45分）方可通过考试 成绩查询：可在“中国计算机技术职业资格网”上查询软考成绩 出成绩时间：预计在11月左右 证书领取时间：一般在考试成绩公布后3~4个月，各地领取时间有所不同
阅读更多...
安全管理体系化的智慧油站开源了。

安全管理体系化的智慧油站开源了。

AI视频监控平台简介 AI视频监控平台是一款功能强大且简单易用的实时算法视频监控系统。它的愿景是最底层打通各大芯片厂商相互间的壁垒，省去繁琐重复的适配流程，实现芯片、算法、应用的全流程组合，从而大大减少企业级应用约95%的开发成本。用户只需在界面上进行简单的操作，就可以实现全视频的接入及布控。摄像头管理模块用于多种终端设备、智能设备的接入及管理。平台支持包括摄像头等终端感知设备接入，为整个平台提
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2