玩转微服务-基础篇-Git

Elcker

已于 2023-11-13 15:21:41 修改

阅读量350

点赞数

分类专栏：玩转微服务文章标签：微服务 git 架构

于 2023-11-13 15:18:28 首次发布

本文链接：https://blog.csdn.net/sxlesq/article/details/134378140

版权

玩转微服务专栏收录该内容

12 篇文章 1 订阅

订阅专栏

第一节 Git简介

Git是一款分布式源代码管理工具(版本控制工具) 。

Git得其数据更像是一系列微型文件系统的快照。使用Git，每次提交或保存项目状态时，Git基本上都会记录当时所有文件的外观，并存储对该快照的引用。为了提高效率，如果文件没有改变，Git不会再次存储文件，只是指向它已存储的上一个相同文件的链接。Git认为它的数据更像是一个快照流，会将数据作为项目的快照存储一段时间。可以有效、高速地处理从很小到非常大的项目版本管理。也是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。

1. 数据库介绍

Git中的大多数操作只需要本地文件和资源来运行 - 通常不需要来自网络上另一台计算机的信息。当您在Git中执行操作时，几乎所有操作都只将数据添加到Git数据库。很难让系统做任何不可撤销的事情或者以任何方式擦除数据。与任何VCS一样，您可能会丢失或搞乱尚未提交的更改，但在将快照提交到Git之后，很难丢失，尤其是在您经常将数据库推送到另一个存储库时。

2. 作用

当你需要做一个大工程的时候，文件的管理无疑是非常庞大的工作，因为你需要不断的修改更新文件内容，同时可能还要保留旧版本保证可以复原，这样就需要备份多个版本的文件。

并且在大多数情况下一个工程需要在多数人来共同维护，那么这种情况下不同人之间修改内容的合并也是非常麻烦的，这时使用git就可以很轻松的解决这些问题。

3. 集中式和分布式

集中式版本控制系统：版本库集中存放在中央服务器。最大的毛病就是必须联网才能工作。

分布式版本控制系统：没有“中央服务器”，每个人的电脑上都是一个完整的版本库。你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

在这里插入图片描述

第二节环境搭建

下载地址：Git (git-scm.com)

环境配置：本地path中，添加git的安装目标地址，使其可以再全局中使用。

第三节 Git的工作机制

简介

在这里插入图片描述

1、工作区：存放代码的地方

2、暂存区（stage 或 index）：临时存储，将工作区的代码让git知道，通过git add将代码放到暂存区

3、本地库：将暂存区的代码提交到本地库，就会生成对应的历史版本，这个代码就无法删除

4、远程库：将本地库的代码推送到远程库

流程示意

在这里插入图片描述

图中左侧为工作区，右侧为版本库。在版本库中标记为 “index” 的区域是暂存区（stage/index），标记为 “master” 的是 master 分支所代表的目录树。
图中我们可以看出此时 “HEAD” 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
图中的 objects 标识的区域为 Git 的对象库，实际位于 “.git/objects” 目录下，里面包含了创建的各种对象及内容。
当对工作区修改（或新增）的文件执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。
当执行 git reset HEAD 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。
当执行 git rm --cached 命令时，会直接从暂存区删除文件，工作区则不做出改变。
当执行 git checkout . 或者 git checkout – 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区中的改动。
当执行 git checkout HEAD . 或者 git checkout HEAD 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

工作流图

在这里插入图片描述

第四节 Git命令

一. 基础命令

git --version 查看系统的git版本；

git help 查看git的帮助命令

请添加图片描述

二. 全局配置

git config --global user.name   用户名
git config --global user.email  设置用户邮箱
git config --global credential.helper cache    开启密码缓存功能：
git config --global credential.helper 'cache --timeout=3600'   开启后Git会在明文形式下缓存密码。缓存的时间默认为15分钟，可以通过以下命令修改缓存时间
// 存储密码到文件
git config --global credential.helper store
git config --global credential.helper 'store --file ~/.git-credentials'   设置密码文件路径
//  以上命令将密码保存到~/.git-credentials文件中。注意，密码保存在明文文件中，需要注意保护文件。

三.仓库操作

1. 创建仓库

git init  创建仓库
git status 查看项目仓库状态
git clone <url> 克隆远程仓库
     git clone https://username:password@github.com/user/repo.git   // 带用户信息访问，密码不能包含@符号

2. 查看日志

git reflog                      查看本地工作区中的历史记录
git log                        查看提交历史记录
git log --pretty=oneline       显示单行

3. 分支管理

git branch                查看已经创建的分支
    git branch  -v
    git branch -av
git branch 分支名          创建分支
git checkout 分支名        切换分支
git branch -d 分支名       删除分支
git merge 分支名称         合并指定的分支到当前分支
git checkout 分支名称      切换分支
git checkout -b 分支名称   创建新分支并切换

4. 文件操作

git add .                          添加所有位处理的文件到暂存区
git add 文件名称                    添加指定的文件到暂存区
git commit -m                      提交的信息内容
git commit -m “日志信息” 文件名      按照文件的 
git diff                           可以对比两个版本的差异
git diff 文件..                     本地工作区和暂存区的diff信息：git diff 或者 git diff file
git diff --cached                  暂存区和版本库的diff信息（使用git add 将工作区修改保存到了暂存区后）
git diff commit1 commit2 或 git diff branch1 branch2
                                   版本库中不同commit、分支的diff信息（使用git commit 将暂存区修改提交到了版本库） 
分支Diff
git diff branch1 branch2 --stat //--stat参数，显示两分支简单diff信息
git diff branch1 branch2 //显示两分支详细的diff信息
git diff branch1 branch2 path //显示两分支指定路径下文件的详细diff信息
git diff branch1 branch2 file_name(带路径) //显示两分支指定文件的详细diff信息

5. 版本管理

git remote add                  添加远程仓库
git push                        推送本地内容到远程仓库
git remote set-url              修改本地指向的远程仓库地址
git fetch                       刷新服务器与本地状态，并以远程更新
git pull                        获取远程数据的变更  pull一般是的当前分支
git remote [-v]                 查看远程仓库信息
git brache --set-upstream <lname> origin/<rname>  建立本地分支和远程分支的关联
git push origin -delete 分支名称  删除远程分支

6. 标签管理

git tag -a <tagname> -m <commd> <commit_id> 创建标签
git tag                                     所有标签    
git show <tagname> xxx                      指定标签
git tag -d <tagname>                        删除本地标签
// 删除远程仓库
git push origin :refs/tags/<tagname>       
git push origin --delete <tagname>    
git push origin :<tagname>
// 推送标签到远程
git push origin <tagname> 推送单个标签到远程
git push origin -tags 推送所有未推送的标签到远程

7. 暂存修改

git stash --help 查看修改的命令

git stash              进行储藏
git stash -m "xxxxx"   储藏添加信息
git stash list         查看储藏
git stash apply <index>       应用储藏，
git stash pop          应用最近一次储藏\
git stash drop <index> 删除应用的储藏
git stash clear

对特定范围文件进行储藏
git stash [-u|--include-untracked]：对未追踪文件也进行储藏
git stash [-S|--staged]: 只对暂存区文件进行储藏
git stash [-a|--all]: 对所有文件进行储藏

第五节 Git的工作流

一. 简介

Gitflow是一个Git自带的Git工作流，它最初是一种用于管理Git分支的破坏性和新颖的策略。是现代连续软件开发和DevOps实践的最佳实践。Giflow是另一种Git分支模型，它涉及到特征分支和多个主分支的使用。最早由文森特·德里森在nvie首次出版并广受欢迎。与传统的开发相比，Giflow拥有众多、寿命更长的分支和更大的提交。在此模型下，开发人员创建一个功能分支，并延迟将其合并到主干分支，直到功能完成。这些长期存在的功能分支需要更多的协作才能合并，并且偏离主干分支的风险更高。

二. 常用的分支管理

分支名称	分支说明
Production/master	生产分支，即 Master分支。只能从其他分支合并，不能直接修改
Release	发布分支，基于 Develop 分支创建，待发布完成后合并到 Develop 和 Production 分支去
Develop	主开发分支，包含所有要发布到下一个 Release 的代码，该分支主要合并其他分支内容
Feature	新功能分支，基于 Develop 分支创建，开发新功能，待开发完毕合并至 Develop 分支
Hotfix	修复分支，基于 Production 分支创建，待修复完成后合并到 Develop 和 Production 分支去，同时在 Master 上打一个tag

三. 分支介绍

Git Flow的核心就是分支(Branch），通过在项目的不同阶段对分支的不同操作（包括但不限于创建、合并、变基等）来实现一个完整的高效率的工作流程。Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支包含主要分支和开发分支，用于组织与软件开发、部署相关的活动；辅助分支包含功能分支、预发分支、热修复分支以及其他自定义分支，是为了解决特定的问题而进行的各种开发活动。与主分支不同，这些分支总是有有限的生命时间，因为它们最终将被移除。

> 主分支：master分支、develop分支；辅助分支：feature分支、release分支、hotfix分支

master

主要分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，主要分支上的代码要被更新。同时，每一次更新，都需要在主要分支上打上对应的版本号。

任何人不允许在主要分支上进行代码的直接提交，只接受其他分支的合入。原则上主要分支上的代码必须是合并自经过多轮测试及已经发布一段时间且线上稳定的预发分支。

master分支只存放历史发布(release)版本的源代码。即用于存放对外发布的版本，任何时候在这个分支获取到的都是稳定的已发布的版本。各个版本通过tag来标记。上图里的v0.1和v0.2就是tag。

Develop

开发分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当开发分支到达一个稳定的点并准备好发布时，应该从该点拉取一个预发分支并附上发布版本号。也有人称开发分支为集成分支，因为会基于该分支和持续集成工具做自动化的构建。

开发分支接受其他辅助分支的合入，最常见的就是功能分支，开发一个新功能时拉取新的功能分支，开发完成后再并入开发分支。需要注意的是，合入开发的分支必须保证功能完整，不影响开发分支的正常运行。

develop分支则用来整合各个feature分支。开发中的版本的源代码存放在这里。即用于日常开发，存放最新的开发版。

功能分支（Feature）

功能分支一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。功能分支要求足够细粒度以避免成为长期存在的功能分支，应当小步合并而不是一次合并大量代码。

功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃。

每一个特性(feature)都必须在自己的分支里开发，feature分支派生自develop分支。

feature分支只存在于开发者本地，不能被提交到远程库。当feature开发完毕后，要合并回develop分支。feature分支永远不会和master分支打交道。

预发分支（Release）

预发分支一般命名为 Release/1.2（后面是版本号），该分支专为测试—发布新的版本而开辟，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。

预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署。

预发分支只能拉取自开发分支，合并回开发分支和主要分支。

release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。

我们用这个分支干所有和发布有关的事情，比如：

把这个分支打包给测试人员测试

在这个分支里修复bug

编写发布文档

所以，在这个分支里面绝对不会添加新的特性。

当和发布相关的工作都完成后，release分支合并回develop和master分支。

单独搞一个release分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。

热修复分支（Hotfix）

热修复分支一般命名为Hotfix/1.2.1（后面是版本号），当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的tag版本（比如1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责代码修复的人并行、独立的开展工作。

热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。

一个项目发布后或多或少肯定会有一些bug存在，而bug的修复工作并不适合在develop上做，这是因为

develop分支上包含还未验证过的feature

用户未必需要develop上的feature

develop还不能马上发布，而客户急需这个bug的修复。

这时就需要新建hotfix分支，hotfix分支派生自master分支，仅仅用于修复bug，当bug修复完毕后，马上回归到master分支，然后发布一个新版本，比如，v0.1.1。

同时hotfix也要合并回develop分支，这样develop分支就能享受到bug修复的好处了。