Git---版本控制（代码管理）系统

最新推荐文章于 2025-10-10 09:45:49 发布

原创最新推荐文章于 2025-10-10 09:45:49 发布 · 439 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#git #gitlab #运维

Git/Gitlab 版本控制（代码管理）系统专栏收录该内容

7 篇文章

订阅专栏

本文详细介绍了Git的部署、工作区、暂存区、master分支及其相互关系，并讲解了Git的基础命令、HEAD指针、分支管理和标签操作。通过实例展示了如何创建、切换、合并分支，以及如何使用标签来标记版本。内容涵盖了Git的基础知识和常用操作，是学习Git的实用指南。

Git版本控制（代码管理）系统

一、部署Git

1. 基础环境

yum install git

yum install dh-autoreconf curl-devel expat-devel gettext-devel openssl-devel perl-devel zlib-devel

yum install asciidoc xmlto docbook2X

解压，编译安装

tar -xf git-2.9.5.tar.xz -C /usr/local
cd /usr/locat/git-2.9.5
make && make install

2. 创建版本库

选择一个合适的地方，创建一个空目录

cd /opt
mkdir test
cd test
git init # 初始化，把当前目录变为由 git 管理的版本库

在这里插入图片描述
可以看到在当前目录下会创建一个隐藏的文件夹 .git
轻易不用动它里面的任何文件，因为这个目录是 Git 来跟踪和管理版本库用的，假如你搞坏了，Git 仓库就会被破坏。

.git 目录就是 Git 的版本库

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支 master(通常称为主分支)，以及指向 master 的一个指针叫HEAD。

3. 工作区、暂存区和 master 分支

Git 和 SVN 不同之一，就是有 工作区、暂存区的概念
* 工作区： 用来平时的开发、编辑文件之用，在你创建的仓库目录下，就是工作区
* 暂存区： 用来暂时存放准备提交到仓库的文档的地方，在 .git 目录下。
* master 分支： 真正用来存放和发布已经完成的代码文件的地方，在 .git 目录下。

三者关系
最初文件在工作区
在这里插入图片描述
git add readme.txt 后，文件被添加到暂存区，此时工作区的文件和暂存区的文件一致。

git commit -m “new file readme.txt” 后，在暂存区的所有文件和目录都将后被提交（移动）到分支 master。

而此时，工作区的文件会和当前分支 master 的文件一致，而暂存区没有任何文件，是清洁的。

可以多次添加，一次提交。

二、Git仓库

1. 基础命令

git add . #将当前目录下所有修改的文件提交到暂存区

git commit -m "add a.txt" #提交版本到仓库
# git commit 的 -m 参数后面跟的是关于这次提交版本的描述信息。

git status #查看仓库最新变化和状态

git reset --hard +回退的版本号  #回退版本

git log --graph --oneline --decorate --all  #查看目前的提交版本状态

git  tag    # 查看当前版本库的所有标签

# 给当前分支所在的提交点 打标签
git tag  标签名称
git tag  v1.0


# 给历史提交点打标签
git tag 标签名称  commit id

git tag 2.0   23fe3456

# 利用 标签切换 版本号

git  reset --hard  标签名称

git  reset --hard   2.0

# 删除标签
git tag  -d 标签名

2. HEAD 指针

HEAD 指向哪个版本，当前就是哪个版本；当你来回切换版本的时候，Git 只是把 HEAD 指向你要切换的版本，顺便把工作区的文件更新一下,见下图：

处于最新提交后的指针指向：
在这里插入图片描述
版本回退后的指针指向

3. 分支与标签

（1）分支创建与合并

在版本回退里，你已经知道，每次提交，Git 都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在 Git 里，这个分支叫主分支，即master 分支。HEAD 严格来说不是指向提交，而是指向 master， master 才是指向提交的，所以，HEAD 指向的就是当前分支。

一开始的时候，master 分支是一条线，Git 用 master 指向最新的提交点，再用HEAD 指向 master，就能确定当前分支，以及当前分支的提交点：
在这里插入图片描述
每次提交，master 分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长

当我们创建新的分支，例如 bac 时，Git 会新建一个指针叫 bac，指向 master 相同的提交点，再把HEAD指向 bac，就表示当前分支在 bac 上：
在这里插入图片描述
Git创建一个分支很快，因为此时，只是增加一个 bac 指针，然后改改 HEAD 的指向即可，工作区的文件都没有任何变化！
从现在开始，对工作区的修改和提交就是针对 bac 分支了，比如新提交一次后，bac 指针往前移动一步，而master 指针不变，HEAD 指针同样不变：
在这里插入图片描述
假如我们在 bac 上的工作完成了，就可以把 bac 合并到 master 上。Git 怎么合并呢？很简单，先切换到 master 分支，此时 HEAD 指针就会指向 master 指针，之后就是直接把master 指向 bac 的当前提交点，就完成了合并：
在这里插入图片描述
所以Git合并分支也很快！就改改指针，工作区内容也不需要变！
合并完分支后，你觉得 bac 分支没什么用了，甚至可以删除 bac 分支。删除 bac 分支就是把 bac 指针给删掉，删掉后，我们就剩下了一条 master 分支：
在这里插入图片描述

（2）分支操作

git branch #查看所在分支和所有分支 *表示所在分支

git checkout dev #切换到dev分支

git merge dev #合并dev分支到当前分支

git branch -d <name>   #删除分支

在这里插入图片描述
（）

（3）分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：
在这里插入图片描述
Git 流程图

（4）标签操作

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

git tag  #查看当前版本库的所有标签

git tag v1.0 #给当前分支所在的提交点打标签

git tag 标签名 commit +id #给历史提交点打标签

git reset --hard v4.0 #利用标签切换版本v4.0

git tag -d +标签名  #删除标签

git show +标签名 #查看标签信息

注意：标签不是按时间顺序列出，而是按字母排序的

查看历史版本

[root@ela1 test]# git log --pretty=oneline --abbrev-commit
cb2b581 create a b.txt file
fa9422f add 4 to a.txt
25b16e6 add 3 to a.txt
15da855 add 2 to a.txt
7947f08 add a.txt