✅作者简介：大家好,我是Philosophy7？让我们一起共同进步吧！🏆 📃个人主页：Philosophy7的csdn博客
👑哲学语录: 承认自己的无知，乃是开启智慧的大门
💖如果觉得博主的文章还不错的话，请点赞👍+收藏⭐️+留言📝支持一下博主哦🤞

一、Git概述

Git 是一个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种项目。 Git 易于学习，占地面积小，性能极快。 它具有廉价的本地库，方便的暂存区域和多个工作 流分支等特性。其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具。

1.1什么是版本控制?

版本控制是一种记录文件内容变化，以便将来查阅特定版本修订情况的系统。 版本控制其实最重要的是可以记录文件修改历史记录，从而让用户能够查看历史版本， 方便版本切换。

举个例子:假设您参加了一项比赛，比赛的已经接近了尾声，需要您去做项目总结的时候，这个时候就有人会去审核您的内容，他会特地的找茬挑刺，说您XXX内容不好，亦或是怎么越改越差，甚至您改到最后都不知道这份文件最初的模样是什么样子的了，于是版本控制就起了作用，你修改一次，备份一个副本，这样你就可以审视哪些内容是不好的(也就是挑刺的那个13提出来的)，最后特殊问题，具体分析。

1.2为什么需要版本控制?

三个臭皮匠顶个诸葛亮，也就是从个人开发过渡到团队协作开发。

有了版本控制后，团队之间的协作会更加的融洽，且能互相看到对方所编写的代码，能够即使指出问题，并且并解决掉，很大程度上解决了团队之间协作的问题。

若没有版本控制的话，那么大家都是各写各的代码，到时候歧义连连，互相打架，这就很不利于团队之间的发展了。

常见的版本控制工具:Git、SVN、CVS等等

1.3集中式版本控制和分布式的区别?

集中式版本控制

集中化的版本控制系统诸如 CVS、SVN 等，都有一个单一的集中管理的服务器，保存 所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或 者提交更新。多年以来，这已成为版本控制系统的标准做法。

这种做法带来了许多好处，每个人都可以在一定程度上看到项目中的其他人正在做些什 么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统，要 远比在各个客户端上维护本地数据库来得轻松容易。

但是这有一个很明显的弊端，那就是单点故障，一旦服务器宕机，挂掉了那么所有人也就无法提交代码进行更新了，也就意味着无法团队协作工作了。

分布式版本控制

Git、Mercurial、Bazaar、Darcs…

Git就是一种分布式版本控制，客户端提取的不是最新版本的文本快照，而是把代码仓库完整地镜像下来这样任何一处协同工作用的文件发生故障，事后都可以用 其他客户端的本地仓库进行恢复。

分布式的版本控制解决了集中式版本系统的缺陷:

1. 服务器断网或宕机的情况下也能进行开发(因为版本控制是在本地进行的)
2. 每个客户端保存的也都是完整的项目

1.4 Git和代码托管中心

代码托管中心是基于网络服务器的远程代码仓库，一般我们简单称为远程库。

局域网为例的GitLab

互联网为例的国内Gitee(码云)、国外GitHub

二、Git常用的命令

2.1 创建Git版本控制

Git的创始人就是Linux的创始人Linus Torvalds，因此Git除了独特的命令，Linux的命令都可以在这里使用。

①设置用户签名

基本语法:

• git config --global user.name 用户名
• git config --global user.email 邮箱

签名的作用:区分不同操作者的身份。Git 首次安装必须设置一下用户签名，否则无法提交代码。

注意：这里设置用户签名和将来登录 GitHub（或其他代码托管中心）的账号没有任何关系。

②初始化本地库

基本语法:

• git init 只需要执行一次 这里我已经执行过了

看到.git的文件 就可以证明初始化成功

③查看本地库状态

基本语法:

• git status

首次查看本地库状态，可以看出在该分支上并没有任何文件。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xsyoMgPb-1662881503516)(C:\Users\hasee\Pictures\Git\查看状态.png)]

新增文件操作

vim hello.txt
#i 进入编辑模式
hello world
#wq保存并退出

再次查看本地库状态（检测到未追踪的文件）

④添加暂缓区

基本语法:

• git add 文件名称

查看状态(检测到暂存区有新文件)

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   hello.txt

⑤提交本地库

将暂缓区的文件提交到本地库

基本语法:

• git commit -m "日志信息" 文件名

#没有文件需要提交
hasee@hasee MINGW64 /f/Git-space/git-demo (master)
$ git status
On branch master
nothing to commit, working tree clean

下一段实操案例:

#1.修改文件
vim hello.txt
hello world 1111 #追加内容

#2.查看状态(检测到工作区有文件被修改)
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: hello.txt

#3.将修改的文件再次添加到暂缓区
git add hello.txt
warning: LF will be replaced by CRLF in hello.txt.
The file will have its original line endings in your working 
directory.

#4.查看状态(修改的文件已被提交到暂缓区
git status
On branch master
Changes to be committed:
 (use "git reset HEAD <file>..." to unstage)
 modified: hello.txt

2.2 版本相关操作

基本语法:

• git reflog 查看版本信息
• git log 查看版本详细信
• git reset --hard 版本号 切换版本

#实操
git reflog #查看历史版本记录
3edd753 HEAD@{1}: commit: seconed time #3edd753 唯一版本标识号 
a6e4928 (HEAD -> master) HEAD@{2}: commit (initial): This is my first commit file

#2.切换版本号
git reset --hard a6e4928
HEAD is now at a6e4928 This is my first commit file #HEAD指向a6e4928，提交信息--;

#3.再次查看版本信息 已移动至a6e4928该版本
git reflog
a6e4928 (HEAD -> master) HEAD@{0}: reset: moving to a6e4928 #重点看这
3edd753 HEAD@{1}: commit: seconed time
a6e4928 (HEAD -> master) HEAD@{2}: commit (initial): This is my first commit file

#4.可以查看该版本的文件有何不同
cat hello.txt #1.0版本

Git切换版本，底层其实就是移动head指针，简单描述: head --> master --> first

三、分支

3.1 什么是分支?

在版本控制过程中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独 分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是 一个单独的副本。（分支底层其实也是指针的引用）

3.2 分支的好处?

同时并行推进多个功能开发，提高开发效率。 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

3.3分支的操作

案例实操

1) 查看分支

基本命令:

• git branch -v

$ git branch -v
* master 087a1a7 my third commit （*代表当前所在的分区）

2) 创建分支

基本命令:

• git branch 分支名
  

hasee@hasee MINGW64 /f/Git-space/git-demo (master)
$ git branch demoBranch #创建分支

hasee@hasee MINGW64 /f/Git-space/git-demo (master)
$ git branch -v #查看分支
  demoBranch a6e4928 This is my first commit file #刚创建的分支 并将主分支master的内容复制了一份
* master     a6e4928 This is my first commit file

3) 修改分支

#在master分支下操作
vim hello.txt
#2.提交暂缓区
git add hello.txt
#3.提交本地库
git commit -m "GG" hello.txt
#4.查看分支
git branch -v
#运行结果
  demoBranch a6e4928 This is my first commit file #没有改变
* master     4a8df47 GG #当前master分支已更新为最新一次提交的版本
#查看master分支的文件
cat hello.txt

3.4分支的合并

基本语法:

• git merge 分支名称

实操:在master分支上合并demoBranch

hasee@hasee MINGW64 /f/Git-space/git-demo (demoBranch)
$ git checkout master  #切换分支
Switched to branch 'master'

hasee@hasee MINGW64 /f/Git-space/git-demo (master)
$ cat hello.txt #首先查看master分支下的文件内容
hello world
hello 0914

hasee@hasee MINGW64 /f/Git-space/git-demo (master)
$ git merge demoBranch  #在Master分支下进行分支合并
Auto-merging hello.txt
CONFLICT (content): Merge conflict in hello.txt #此时产生合并冲突
Automatic merge failed; fix conflicts and then commit the result.

hasee@hasee MINGW64 /f/Git-space/git-demo (master|MERGING)
$ cat hello.txt
hello world
<<<<<<< HEAD
hello 0914
=======
hello I'am demoBranch
>>>>>>> demoBranch

冲突产生:形式上分支后跟MERGING，其原因是合并分支时，两个分支在同一个文件的同一个位置有两个完全不相同的修改，也就是内容，Git无法决定。必须人为确定

首先，进行查看状态，可以看到文件有两处修改

hasee@hasee MINGW64 /f/Git-space/git-demo (master|MERGING)
$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   hello.txt

no changes added to commit (use "git add" and/or "git commit -a")

解决冲突问题:编辑有冲突的符号，删除特殊符号，决定要修改的内容。

特殊符号：<<<<<<< HEAD 当前分支的代码 ======= 合并过来的代码 >>>>>>> demoBranch

hello world
hello 0914
hello I'am demoBranch

#2.添加暂缓区
git add hello.txt

#3.提交本地库 --发现后面 MERGING 消失，变为正常
git commit -m 'merge demoBranch'

小结

master、hot-fix 其实都是指向具体版本记录的指针。当前所在的分支，其实是由 HEAD 决定的。所以创建分支的本质就是多创建一个指针。 HEAD 如果指向 master，那么我们现在就在 master 分支上。 HEAD 如果执行 hotfix，那么我们现在就在 hotfix 分支上,所以切换分支的本质就是移动 HEAD 指针。