系统学习git
有价值的参考文章：
https://blog.csdn.net/TZyybhs/article/details/109744961
https://blog.csdn.net/stone_yw/article/details/80795669
指针的类型：
- 分支指针
- 历史版本指针
冲突的类型：
不同分支的合并时出现冲突
远程仓库和本地仓库的冲突
设置本地名称和邮箱：
git config --global user.name 名称
git config --global user.email 邮箱
这个名称和邮箱跟github之类的远程仓库的名称和邮箱没有任何关系，这里的名称和邮箱只是记录历史版本是谁提交的
查看状态：
git status
查看暂存区、已修改、未跟踪（新增）的文件，
从图片中也可以看到一些相应的操作，比如取消暂存
image.png
对于vscode来说，点击分支图标可以直接看到git status
image.png
从图中可以看到可以通过点击相应的按钮来进行相应的操作
查看引用日志：
git reflog
image.png
从图中可以看到提交日志，以及HEAD指向的分支
git log 查看详细的引用日志
image.png
版本穿梭（修改历史版本指针的指向）
git reset --hard 7df5f95
git reset --hard HEAD^^ (有几个^就表示前几个版本)
分支的概念：
在版本控制过程中，同时推进多个任务，开发者可以为每个任务创建单独的分支。使用分支意味着开发者可以把自己的工作从开发主线上分离出来，开发自己分支的同时，不会影响主线分支的线上运行。
image.png
分支的好处：
- 同时并行推进多个功能的开发，提高开发效率
- 各个分支在开发过程中，如果某一分支开发失败或存在缺陷，不会影响其他分支。
分支的操作：
查看分支：git branch
image.png
查看远程分支：git branch -r
image.png
查看本地和远程分支：git branch -a (红色的是远程分支副本，注意是副本，想要更新远程副本就要用git fetch或git pull)
image.png
添加分支：git branch hot-fix
需要考虑的问题：
如果远程仓库已有相同名字的分支会发生什么情况？
可能相当于远程分支跟本地分支发生冲突，最好在本地新建分支之前检查远程是否已存在相应的分支
从哪个分支的哪个历史版本复制出来作为新分支的起点？
新建分支是将当前所在的历史版本作为新分支的起点，下面我们会看到分支和历史版本是有关联的，切换分支之前必须提交历史版本以保存在该分支上的改动，而切换到目标分支后，历史版本也就自动穿梭到目标分支最后一次提交的历史版本上面。
切换分支：git checkout 分支名
创建并切换分支：git checkout -b 分支名
[图片上传中...(image.png-195075-1649628009104-0)]
切换分支会将当前工作目录切换至目标分支最后提交的历史版本
如果在当前分支做了一部分工作，但是还没达到一个历史版本的工作量，
此时想要切换到另一个分支去工作（比如被紧急调到bug修复分支），则会报错：
image.png
只能提交当前分支的工作量 ，才能切换到别的分支，当在别的分支完成后想要切换回当前分支，则可以接着当前分支部分完成的工作量作为起点，因为上次切换分支之前已被git要求必须提交部分完成的工作。还有一种方法是使用git stash 和git stash pop命令将当前的工作区和暂存区保存起来，到时候再恢复（pop）回来。
既然切换分支之前，必须提交历史记录（除非什么也没改动），所以切换分支的时候，也git也就自动将历史版本指针指向目标分支最后一次提交的历史版本上面
分支合并：
把指定的分支合并到当前分支：
git merge 被合并到当前未知的分支名称
image.png
将B分支合并到A分支，是不是可以当作A分支做了一部分改动再提交历史版本？
不是，因为合并新的分支并不会产生新的历史版本
删除分支：git branch -d 被删除的分支名
image.png
常见场景：
一、要开发一个新功能，结果开发到一半，主分支发现bug需要紧急修复，修复并测试后需要切换回来继续开发。
- 首先在开发新功能的分支（以下简称dev分支）上执行 git stash 以保存当前工作区和暂存区的工作
- 切换至主分支（以下简称main分支）上执行 git branch fix 创建bug修复分支，并切换至该分支
- 在 fix 分支上修复bug并提交，切换回 main 分支
- main 分支 合并 fix 分支，至此 bug 已被修复
- 返回 dev 分支并执行 git stash pop 弹出上次因紧急修复bug而保存的工作
- 先在 dev 分支上面修复bug，然后继续 dev 的开发，直至完成并提交历史版本
- 切换至 main 分支，并合并 dev 分支，此时发现合并冲突，仔细一看是之前在 fix 分支上修复 bug 的方式和在 dev 开发分支时修改 bug 的方式不一样（如果修复的方式完全一样，尤其要注意换行引起的差异，是不会导致合并冲突的）
- 在 main 分支上解决冲突， 并一定要提交历史版本
为了减少使用stash时的意外，尽量养成以下习惯：
- 在使用stage前，先使用 git stash list 大概看一下已有的 stash
- stage 尽量配合save使用，以方便找回索引：git stage save 'xxx的暂存'
- 恢复 stash 时，尽量使用 apply，这样就不会在确保正确恢复 stash 之前丢失 stash 栈中的数据：git stash apply --index 1
分布式git
github添加成员
image.png
[图片上传中...(image.png-e05302-1649714906394-0)]
v2-af3bf6fee935820d481853e452ed2d55_720w.jpg
远程别名
查看远程别名： git remote -v
创建远程别名： git add remote 别名 git远程仓库链接, 例如：git remote add origin https://github.com/lanqiukun/tig.git
创建好之后：git remote -v 查看远程别名
image.png
推送
将本地的分支推送到远程对应的分支
git push 远程别名 分支名
更新远程仓库副本
git fetch
不给出具体的远程别名和分支名，则更新全部
image.png
git fetch 远程别名 分支名
合并远程分支到当前分支：
git merge remotes/origin/master
拉取并合并远程分支到当前分支（fetch + merge）
git pull 远程别名 分支名
跨团队分布式git
image.png
.gitignore规则
.gitignore只能忽略那些原来没有被 track 的文件，如果某些文件已经被纳入了版本管理中，则修改 .gitignore 是无效的。
解决方法是先把本地缓存删除，然后再提交: git rm --cached 不想要继续跟踪的文件
目录
/public/hot
前缀
haha*
后缀
.zip
/storage/.key
普通文件
.env
git tag:
1.显示所有的tag
git tag
2.查看某个版本系统的tag
git tag -l ' v1.0.*'
- 创建标签
第一种: git tag -a v1.0.0 -m '内容'
第二种: git tag v1.0.0
4.查看标签的详情
git show v1.0.0
得到以下输出：
commit a83516d0fb5da5fd5ad749733a160219b5a5ceac (tag: v1.0.0)
Author: Alfred Liu joemale@163.com
5.推送标签
git push origin v1.0.0
6.删除标签
删除本地标签
git tag -d v1.0.0
删除远程标签
git push origin :refs/tags/v1.0.0
完整的打tag
git add *
git commit -m 'v1.0.0'
git tag v1.0.0
git push
git push origin v1.0.0
