Git的基本使用

前言 ：为什么使用Git

Git是一个分布式 版本控制工具。
Git ⽐其他版本控制系统设计得优秀，因为 Git 跟踪并管理的是修改，⽽⾮⽂件。

Git基本操作

1. 初始化

### 安装Git
	###Ubuntu
	### -y: 自动回答yes
	sudo apt-get -y install git 
	###CentOS
	sudo yum -y install git
### 创建Git本地仓库，初始化后该文件夹下会出现一个.git 目录
    git init
### 配置Git
    #### global 是全局配置，否则只在本仓库生效
    git config [--global] user.name "xxx"
    git config [--global] user.email "xxx@xx.com"
    ### 查看配置
    git config -l
    ### 删除配置
    git  config [--global] --unset user.name

2. Git分区

• Workspace: 工作区，就是在电脑里能看到的目录;
• Index/Stage: 暂存区，存放在.git/index中;
• Repository: 版本库(本地仓库)，即工作区的隐藏目录.git;
• Remote: 远程仓库;

3. 认识.git目录

通过tree命令查看.git文件

主要认识几个重要的文件：

• index： 暂存区，add后的内容暂存在此处;
• HEAD ：指向当前分支的指针;
• Objects ：存储每次commit的commit ID （git cat-file -p commitID 查看）;
• Refs：存储各分支/标签的引用，即最新的commit id;

4. git基本操作

### 将file文件添加到暂存区
git add file
### 将暂存区的文件上传到版本库
git commit -m "commit file"
### 将工作区中所有已跟踪文件的修改等操作添加到暂存区并提交
git commit -a -m "add and commit"
### 查看历史提交记录，--pretty=oneline，将每次提交信息放在一行显示
git log --pretty=oneline

### 查看状态
git status 

### 起别名
git config --global alias.st status
### 起完别名后，就可以使用别名来下命令
git st

git中常见的四种状态：

###版本回退
git reset [ --soft | --mixed | --hard ] [HEAD]

git reset 命令会将版本库回退到指定版本，工作区和暂存区是否回退由参数决定：

• --mixed: 默认选项，将暂存区退回到指定版本，工作区不变；
• --soft: 暂存区和工作区都不会退；
• --hard: 暂存区和工作区都要回退；

之前讲到，HEAD是指向当前分支的指针，而当前分支中存储的是最新的commit ID，所以此处的HEAD选项就是一个commit ID；
当然，想要记住这个ID似乎不太可能，或者每次查询都比较麻烦，git为我们提供了更加便捷的选项：

• HEAD表示当前版本；
• HEAD^表示上一个版本；
• HEAD^^表示上上一个版本；
• 以此类推…

也可以用~数字表示：

• HEAD~1 上一个版本；
• HEAD~2 上上一个版本；
• 以此类推…

思考一个问题，假如你回退到上一个版本之后，后悔了，此时怎么做：首先，这个便捷的选项无法使用了，其次，我们需要想办法找到commit ID，此时我们想到用git log来找到这个ID，但实际并不可以（可以自行尝试），那怎么解决呢，使用git reflog命令可以查看到所有HEAD的移动记录。

git reflog ###记录本地的每一次命令

这件事的解释如下：

在版本回退之后，master中最新的commit ID成为了version2 的ID，指针被移向的旧的提交，新的提交不能追踪。而使用git reflog可以查看到所有HEAD的移动记录。

此处前面黄色的字符串，是commitID的部分，也可以用于版本回退。

git reset --hard la3a288
### 千万不能使用 checkout 切换，这会造成分离头指针的问题，下面细说（埋个伏笔）
git checkout la3a288

版本回退常见的三种情况如下 ：

### 假如你做了一部分工作，没有add，发现不合适，如何做？
	## 这种情况你当然可以找一下差异，然后自己改，但如果你的工作量比较大，那似乎会很麻烦
	git diff file ## 显示暂存区和工作区的差异
	git diff HEAD -- file ##查看版本库和⼯作区⽂件的区别
	## 更便捷的方式
	git checkout -- file ###让⼯作区的⽂件回到最近⼀次  add  或  commit  时的状态
### 假如你add你的工作到暂存区了，但还没有commit到版本库，发现不合适，想要回退，怎么做？
git reset --mixed HEAD text.txt
### 假如你的工作以及add并且commit了，如何回退？
git reset --hard HEAD^

关于版本回退的问题，就先讲到这里。接下来看如何删除文件：

说到删除，大家可能会想到在Linux上直接rm file不就可以了吗，但是这只能删除掉工作区的文件，如果我们想要删除暂存区和版本库里的文件，该怎么做呢？

### 删除文件
### 将文件从工作区和暂存区删除
git rm file
### 删除掉工作区和暂存区的文件后，提交修改，同步版本库即可
git commit -m "delete file"

那不小心删错了怎么办，当然可以进行版本回退了，请兄弟们自己试验一下。

Git分支管理

1. 基本操作

###查看分支
git branch
git branch -r # 查看远程分支
git branch -a # 查看所有分支
###创建分支
git branch dev
### 切换分支
git checkout dev
###新建并切换分支
git checkout -b dev

之前讲过HEAD指向当前分支，当前分支中存储的是该分支上的最新提交的commitID，实际是这么一个模型：

接下来我们切换到dev分支，进行一些修改，然后提交，在切换回master分支，发现我们所做的修改不见了,怎么解释？

当切换回master分支后，HEAD指向了master，master指向了还未做修改的版本，故而不能看到修改。如果就想在master分支上看到这个修改，那就要合并分支。

### 合并分支
### fast-forward
git merge dev
### no fast-forward
git merge --no-ff -m"merge with no-ff" dev

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，优点是合并速度快，只需要更改master的指向，缺点是不能记录分支的合并情况。

那如果是这种情况，dev分支上做了一些修改，master分支上也做了一些修改，出现了冲突，该如何解决：

实际上这需要你手动解决，在合并（使用git merge dev命令）时，git会将冲突信息写入有冲突的文件，然后我们手动修改文件内容直到满意为止，然后一定要记住要再次提交。之后就不需要再次merge了，因为我们要求的master分支的内容已经与dev分支的内容合并了（实际是我们手动合并的）。

###合并冲突，手动修改，再次add，commit
##### 一顿修改猛如虎
vi test.txt
git add test.txt
git commit -m"merge ReadMe"

修改完成后的情况：

##查看合并情况
git log --graph --pretty=oneline --abbrev-commit

###删除分支
git branch -d dev

假如我们在dev分支上开发过程中，发现master分支有bug，且急需修改，怎么做？
在这里补充一句，工作区和暂存区是公共的(对所有分支都一样)，只有提交到版本库，才会有区别。

那如果我直接切回到master，实际上工作区还是开发dev分支的代码，那么我们要将当前代码提交吗，其实也不是不行，但是你的版本库中有一个节点就成了一个残次品，git为我们提供了更好的方式，使用git stash储藏代码：

###将当前工作区的信息储藏
git stash
### 查看stash列表
git stash list
###取出存储的代码，同时清除stash列表里的记录
git stash pop
## 恢复存储的代码，但不更改stash列表
git stash apply stash@{0}
## 删除stash列表的内容
git stash drop

2. Git分支设计规范

⾔归正传，对于开发⼈员来说，在系统开发过程中最常⽤的⼏个环境必须要了解⼀下：

1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误报告和测试⼯具，是最基础的环境。
2. 测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境。
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。
   这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。⼀张图总结：
   

有了环境的概念，再来看分支（Git Flow模型）：

• master分支作为稳定的唯一代码库，不允许在master上修改代码；master上的代码一般由合并release分支得到，所有在master分⽀的推送应该打标签（tag）做记录，⽅便追溯；
• release分支主要⽤于提交给测试⼈员进⾏功能测试，基于develop分支创建，命名规则: release/version_publishtime；
• develop 为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。一般由feature分支合并；
• feature 分⽀通常为新功能或新特性开发分⽀，基于develop分支创建，命名规则： feature/user_createtime_feature。新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀。⼀旦该需求发布上线，便将其删除；
• hotfix 分⽀用于修复紧急bug，基于master创建，命名规则: hotfix/user_createtime_hotfix 。当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便将其删除。

总结一下：

Git 标签管理

Git 中的标签是一个指向特定提交的引用（指针），用于标记项目的重要节点（如版本发布）。个人理解：简单来说就是给提交的commit ID起了个别名，便于你寻找这个commit版本，这样理解也就能理解为啥会引起分离头指针问题了（个人理解，不喜勿喷~）。

1. Git标签的使用

标签的操作与分支的操作基本一致：

### 创建标签
	### 轻量标签v1.0
	git tag v1.0
	### 附注标签v1.0
	git tag -a v1.0 -m "v1.0版本"
	
###查看所有标签
git tag

###查看v1.0标签详细信息
git show v1.0

###删除标签v1.0
git tag -d v1.0

### 删除远程标签v1.0
git push origin --delete v1.0

###切换到标签v1.0
git checkout v1.0

###推送标签v1.0到远程仓库
git push origin v1.0

###推送所有标签
git push origin --tags

2. 标签使用规范

• 使用附注标签：附注标签包含更多信息，适合用于版本发布;
• 遵循语义化版本号：使用 v1.0.0、v2.1.3 等语义化版本号命名标签;
• 及时推送标签：创建标签后，及时推送到远程仓库，以便团队共享;
• 不要修改标签：标签应保持不可变性，避免修改已发布的标签;

3. Git标签与分支的区别

分离头指针问题

在Git中，分离头指针 (Detached HEAD) 是指 HEAD 指针直接指向某个提交而不是分支（正常情况下应该是HEAD指向分支，分支指向提交）。常见的情况有三种：

###切换到某个提交
git checkout <commitID>
###切换到某个标签
git checkout <tag-name>
###切换到远程分支
git checkout origin/<branch-name>

为什么切换到标签会引起这个问题？
还是这样想，起了个别名吗，实际上还是commitID。
为什么切换到远程分支也会引起这个问题？
其实远程分支与本地分支不同，它存储在本地的是远程仓库中分支的快照（也就是一次提交），所以本质和切换到某个提交引起的问题是一样的。

图解一下：

1. 分离头指针问题的风险

当出现这种状态，git首先会给你一些提示，告诉你处于分离头指针状态。

如果你没了解过这种问题，并忽视了git的提示，继续工作，可能会导致你的提交丢失：即如果在分离头指针状态下创建了提交，但没有将其与分支关联，这些提交可能会被 Git 的垃圾回收机制删除（好吧，这意味着你白干了）。也许你可以通过commitID找到这个提交，并且merge到master分支（我试了下，真可以，但是不建议，如果被GC了，就真白干了）。

2. 分离头指针问题的补救办法（正规办法）

那确实你已经在这里做了许多工作，恍然发现不对劲，怎么办：
这时候你可以创建一个新的分支并切换过去，这时分离头指针状态结束（不会被GC了），你可以提交到这个分支上，来保留你这些修改。

git checkout -b new-branch
git add .
git commit -m "modify test.txt"

远程操作

Git是一个分布式的版本控制工具，每台电脑上都有自己的版本库，这极大程度上提高了他的稳定性（避免了由于一台机器的问题，造成版本库的损坏）。但是不同人员之间想要相互同步版本库还是会有些麻烦（如果人比较多的话，你需要给每个人同步一份），所以git中往往也有一台电脑充当“中央服务器”，大家只需要将自己的修改同步到这台电脑上，然后需要的人员自行取用即可。Github/Gitee就是一个统一托管代码的工具，只需要注册一个账号，就可以获得Git远程仓库。
关于Gitee/Github工具的注册，大家可以自行学习。下面我以Gitee为例，继续讲述一些远程仓库的功能。

1. 基本操作

### 使用HTTPS的方式克隆远程仓库
git clone https://gitee.com/da-gong-uuc/java_data-structure.git

### 使用SSH的方式克隆远程仓库
git clone git@gitee.com:da-gong-uuc/java_data-structure.git

使用SSH方式克隆仓库，需要在本地生成一对公钥和私钥，将公钥填写到Gitee中。

### 生成公私钥
### -t rsa 使用rsa 算法 -C 添加注释
ssh-keygen -t rsa -C "xxxxxxx@xx.com" ##输入自己的邮箱
### 一路默认即可

结束之后可以在用户主目录中（注意是主目录，不是当前目录）找到.ssh文件夹，里面有id_rsa和id_rsa.pub两个文件，其中id_rsa.pub就是公钥，将里面的内容填写到Gitee（设置——>SSH公钥）中，就可以使用ssh方式克隆远程仓库了。

如果是多人协作，只要将每个人电脑上的Key都添加到GitHub/Gitee中，就可以往其中推送了。
如果是想在开源项目上做贡献，则需先下载仓库到本地修改，然后推送到自己的远程仓库，在推送给开源仓库的管理员，供其审核，审核通过才可以。

本地 clone 成功远程仓库后，我们便可以向仓库中提交内容：

###推送修改到远程仓库
	## 格式
	git push <远程主机名> <本地分⽀名>:<远程分⽀名>
	# 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
	git push <远程主机名> <本地分⽀名>
	
	## 例子：将本地的master分支推送到远程仓库中的master分支
	git push origin master

这⾥由于我们使⽤的是 SSH 协议，是不⽤每⼀次推送都输⼊密码的，⽅便了我们的推送操作。如果你使⽤的是 HTTPS 协议，有个麻烦的地⽅就是每次推送都必须输⼊⼝令。

###拉取远程仓库
	## 格式
	git pull <远程主机名> <远程分⽀名>:<本地分⽀名>
	# 如果远程分⽀是与当前分⽀合并，则冒号后⾯的部分可以省略。
	git pull <远程主机名> <远程分⽀名>
	
	## 例子：将远程仓库的master分支拉取到本地
	git pull origin master

2. 配置Git

我们可以在本地新建一个.gitignore文件，然后把想要忽略的文件名（可以使用通配符）填进去，上传到Gitee上（或者在创建仓库的时候配置）。Git就会自动忽略这些文件了。
假如我的gitignore文件中添加了这些内容，然后push到远程仓库，git显示所有内容已经推送到远程，也就是自动忽略了我们新建的my.so 和 my.ini文件。

*.ini
*.so
### ！表示排除,即不忽略这个文件
!.gitignore

3. 多人协作

关于如何多人共用一个仓库，首先在Gitee中邀请你的队友进来，如图。

简单的远程操作就不再赘述，主要讲两个场景：

• 如果出现代码冲突，怎么解决？
  如果出现冲突，在push的时候会失败，此时我们需要将远程代码pull下来，这时git会将冲突信息写入发生冲突的文件中，此时我们手动修改，再次提交，重新推送即可。
• 如何将自己在dev分支上的代码推送到远程仓库的master上？
  1. 首先在本地切换到master分支，pull一下，保证本地master是最新内容；
  2. 切换至dev分支，合并master分支（尽量不在master分支上解决冲突）；
  3. 切换至master分支，合并dev分支；
  4. 将master分支推送至远端。