版本控制工具——Git

---

前言

Git相关知识我是看的B站GeekHour老师的视频学的，亲测是我个人觉得讲得最能听懂的一位！推荐推荐（其他老师也都很厉害，是我太菜），以下是做的学习笔记
GeekHour老师的一小时Git教程链接

一、版本库

版本库（仓库）简称Repo，可以理解为一个目录，这个目录下所有文件都可以被git管理起来，每个文件的修改、删除、添加等操作，git都能够跟踪到，以便任何时候都可以追踪历史或者还原到之前的某个版本
创建仓库的两种方式：
git init：在电脑本地创建仓库
git clone：从github这种远程服务器上克隆一个已经存在的仓库

二、git的工作区域和文件状态

git的本地数据分为三个区域：工作区（实际操作的本地工作目录）、暂存区（用于保存即将提交到git仓库的修改内容）和本地仓库（git存储代码和版本信息的主要位置）

三、添加和提交文件

git init：创建仓库

git status：查看仓库状态

git add：添加到暂存区，如：
git add file1.txt
git add *.txt 将当前文件夹下所有txt格式的文件都添加到暂存区
git add . 将当前文件夹下的所有文件都添加到暂存区

git commit：提交到仓库 （git commit -m"第二次提交"）
【注】不加-m的话就会进入图形界面来进行提交
git log 查看仓库提交记录（git log --oneline可查看简洁的提交记录）

四、回退版本：git reset --模式 版本号

选择soft、hard、mixed三种模式，决定了在回退版本后，工作区和暂存区的内容是否会被清空:

	工作区	暂存区
git reset --soft	不会清空	不会清空
git reset --hard	会清空	会清空
git reset --mixed	不会清空	会清空

【注1】就算回退到原始版本了，也可以通过 git reflog命令查看各个版本号，再通过git reset来回到新版本号就行了
【注2】git reset --模式 HEAD^ 表示快捷地回退到上一个版本号

五、查看差异：git diff

查看工作区、暂存区、本地仓库之间的差异：
git diff:查看工作区与暂存区的差异，显示发生更改的文件以及更改的详细信息，没有返回内容就说明没有差异
git diff HEAD：比较工作区和库之间的差异
git diff CACHED：比较暂存区和库之间的差异
查看不同版本之间的差异：
git diff 版本号1 版本号2
git diff HEAD~ HEAD（或者git diff HEAD^ HEAD ）:直接比较最新版本和上一个版本
git diff HEAD~2 HEAD：直接比较最新版本和上两个版本
git diff HEAD~ HEAD file1.txt：比较最新版本和上一个版本中file1.txt的差异
也可查看不同分支之间的差异

六、从版本库中删除文件

方式一：直接删除文件后提交
首先在本地工作区删除文件，再在暂存区中删除（使用的是add：git add .），再提交
方式二：git rm
在工作区、暂存区同时删除了

git rm file2.txt

【注1】一定要记得删除后要提交，库中的文件才会删除
【注2】git rm --cached file.txt就只会在版本库中将其删除

七、.gitignore：git中的特殊文件

让我们忽略掉一些不该被添加到版本库中的文件
一般会忽略掉 系统或软件自动生成的文件；编译产生的中间文件和结果文件；运行时生成日志文件、缓存文件、临时文件；涉及身份、密码、口令、秘钥等敏感信息文件

举例：将access.log这个文件忽略掉：

echo access.log>.gitignore

【注】.gitignore生效有个前提：这个文件不能是已经被添加到版本库中的文件，要想忽略它就必须先从库中删除

八、Git、GitHub跟Sourcetree的关系

Git是基础的版本控制工具；GitHub是基于Git构建的线上社区和仓库托管平台，让开发者能够相互协作和分享；而Sourcetree则是为了简化和提升Git操作体验的图形化客户端工具

九、Github基础使用

生成SSH KEY
克隆仓库：git clone github上的仓库名
在本地库中更新文件，使用git push推送更新的内容
拉取更新内容：git pull

十、关联本地仓库和远程仓库

本地已经有了一个仓库，怎么放到远程仓库：
cd到该仓库地址下
依次复制粘贴运行github上提示的代码：

git remote add origin git@github.com:geekhall-laoyang/first-repo.git
git branch -M main
git push -u origin main

十一、分支简介

多个开发人员可以在自己的分支上进行开发工作，最后再合并到主线上，或者建立一个问题修复的分支来处理一些bug和缺陷，这样就可以让主线代码仓库始终处于一个稳定状态，让每个人员可以独立地开发和测试
git branch ：查看当前处于哪个分支上，并且一共有哪些分支
git branch 分支名 ： 可以创建一个分支，但此时还没有切换到该分支上
git switch 分支名 ：可以切换到该分支上
git merge 分支名 ：切换到main分支上后，使用该命令可以将指定的分支合并到main上
git branch -d 分支名 ： 删除已经合并到main上的某个指定分支
git branch -D 分支名 ：强制删除某个指定的分支，就算它没有合并到main也可以删除

十二、解决冲突

如果两个分支有重复内容的话（两个分支修改了同一个文件的同一行代码），git就不知道该保留哪个分支的修改内容了，也就产生了冲突，就需要手动去解决

十三、rebase和回退

rebase：变基
git rebase 分支名
什么情况下使用rebase：一般来说，如果只是想把两个分支合并起来而不关心提交历史，那就使用merge，如果确定只有自己一个人在这个分支上进行开发，且希望提交历史更直观明了一些就使用rebase
1、merge要先切换到main分支上再执行merge操作，而rebase可以在任意分支上执行
2、merge优点：不会破坏原分支的提交历史，方便回溯和查看；merge缺点：会产生额外的提交节点，分支图比较复杂
3、rebase优点：不会新增额外的提交记录，会形成线性历史，比较直观干净；rebase缺点：会改变提交历史，改变了当前分支的节点，避免在共享分支时使用（一般不会在公共的分支上执行rebase操作）

回退：
将某个已删除的指定分支恢复到某个指定提交时间点的状态：git checkout -b 分支名 提交id
（将仓库恢复到指定提交时间点的状态使用上述的reset）

十四、分支管理和工作流模型

1、常见的工作流模型：
GitFlow模型：

GitHubFlow模型：

2、分支的命名规范
推荐使用带有意义的描述性名称来命名分支
版本发布分支/Tag示例：v1.0.0
功能分支示例：feature-login-page
修复分支示例：hotfix-#issueid-desc

3、分支管理
定期合并已经成功验证的分支，即使删除已经合并的分支，保持合适的分支数量，并为分支设置合适的管理权限