Git 梳理

之前一直都是自己一个人操作 Git，会的也就是那几个命令。马上要去实习了，所以打算将 Git 重新学习并且复盘下，尤其是分支那块的知识
链接：
https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
https://medium.com/@steveamaza/how-to-write-a-proper-git-commit-message-e028865e5791
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
https://juejin.cn/post/6844903890295455751

使用前配置

签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到，以此确认本次提交是谁做的。Git 首次安装必须设置一下用户签名，否则无法提交代码。这里设置用户签名和将来登录 GitHub(或其他代码托管中心)的账号没有任何关系。 全局配置一般在 ~/.gitconfig 中 git config --global，针对特定项目，一般在 .git/config 文件中 git config --local

• git config --global user.name 提交人姓名
• git config --global user.email 提交人邮箱
• 查看 git 配置信息：git config --list

撤销

• 文件修改只存在工作区，还没有被添加到暂存区：git checkout <file> 或者 git restore <file>
• 文件修改已被添加到暂存区，若想从暂存区回到工作区的状态：git reset HEAD <file> 或者 git restore --staged <file>, 之后若想继续撤销工作区的修改，执行 git checkout <file> 或者 git restore <file> 即可
• 将文件从暂存区删除：git rm --cached 文件 要注意这边虽然从暂存区中删除了，但是工作目录中还是存在的

版本

HEAD 指针指向哪个版本，当前文件就处于这个版本的状态

• git reflog 查看版本信息
• git log 查看版本详细信息

版本穿梭(回滚)

Git 切换版本，底层其实是移动的 HEAD 指针。假设有 v1,v2,v3三次commit记录，想从当前的v3回滚到v2，则使用git reset --hard v2版本号。注意回滚之后，如果使用git log 查看的话，v3版本记录是看不见得，如果想从v2再变为v3，可以使用git reflog查看到v3的版本号，再使用git reset --hard v3版本号

• git reset --hard 版本号
• git reset --hard HEAD^ 回退一次
• git reset --hard HEAD^^ 回退两次

回滚至之前版本

git log
git reset --hard 版本号

回滚至之后版本

git reflog
git reset --hard 版本号

远程仓库

• 查看远程分支：git branch -a
• 查看当前本地仓库对应的远程仓库：git remote show 一般会显示 origin
• 查看当前本地仓库对应的远程仓库的详细信息：git remote show origin
• 若在远程新建分支之后，本地在没有 git fetch 的情况下，直接 git checkout 分支名 是会报错没有被跟踪的，一般情况下，在远程新建分之后，本地想要拉取，需要执行 git fetch 后 再执行 git checkout -b 分支名 origin/分支名
• 若是在直接新clone的仓库下切换远程存在分支，那么不需要 git fetch , 因为此刻，本地仓库与远程是同步的，git fetch 一般用于 mentor 在远程库中新建分支，因为此刻你本地代码肯定是老早clone好的
• 在本地新建分支后，若想推送到远程，第一次push的时候不要直接git push origin 分支名，这样貌似不会直接与远程该分支建立连接，需要使用 git push --set-upstream origin 分支名 ，在 vscode 中 直接选中 push 不要选择push to

git stash

在切换分支之前，必须要将当前分支上所有的改动进行提交才能够切换分支，但更多时候是当前分支上还没有开发好，不想commit，但不得不切换到其他分支上改 bug。在 git 中，可以暂时提取分支上所有的改动并存储，让开发人员得到一个干净的工作副本，临时转向其他工作。

• 存储临时改动：git stash
• 恢复改动：git stash pop 该命令会将 stash 版本删除掉， git stash apply 会保存

差异对比

• git diff 比较暂存区与工作区
• git diff --cached 比较版本区与暂存区

冲突

冲突产生的原因：合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改，Git 无法替我们决定使用哪一个，必须人为决定新代码内容。合并分支只会修改合并的分支，也就是 master 分支，不会修改 dev 分支上的内容

1. <<<<<<< HEAD 与 ======= 之间是当前master分支的代码，======= 与 >>>>>>> dev 之间是 dev 分支的代码

<<<<<<< HEAD
hello git! master test
hello git!
=======
hello git!
hello git! dev test 
>>>>>>> dev

2. 产生冲突后，需要人为手动修改冲突，将自己需要的代码保存下来，如下

hello git! master test
hello git! dev test 

3. 手动解决冲突后，还需要将文件添加到暂存区并且提交到本地库，走 add commit 的流程

git rebase

注意事项

• 不要对master分支执行rebase，会引起很多问题
• 一般来说，执行rebase的分支都是自己的本地分支，没有推送到远程版本库
• 不要在与别人共享的分支上执行 rebase 操作，rebase操作都是在本地与别人没有共享的分支上执行的
• rebase 合并的时候不要把已经提交到远程库的记录合并，要合并那些没有提交到远程库的记录
• 在 rebase 之后 再进行 merge 命令 就相当于是 fast-forword 操作了

应用场景

将多个记录合并为一个记录
git rebase -i HEAD~3 从当前 HEAD 指针所指位置找最近的3条记录进行合并
将分叉记录归并为一条

• 使用merge的时候，是切换到master分支上，执行git merge dev，但是使用rebase的时候，如果想将dev上的提交到master上，要先切回到dev分支，执行git rebase master，之后再切回master分支，执行git merge dev
  拉取远程产生分叉
  git pull origin dev 变成 git fetch origin dev; get rebase origin/dev
• checkout到test分支上之后执行git rebase dev，是以dev为基准，将test分支上的提交合并到dev分支上

零散知识点

• push 和 pull 的时候都需要指定分支，没有指定的情况是 该分支 已经默认与远程分支进行关联了
• 第一次 git clone 只会显示 master 分支上的内容，其他分支其实也被克隆下来了，只是没有显示。如果想获取到其他分支，可以先用 git branch -a 查看远程所有分支，然后用 git checkout 分支名 就可以获取到相应的分支 ，远程仓库若有这个分支会自动追踪
• 修改最新commit的message：git commit --amend
• git cherry-pick 一般应用于本地分支上

规范

• git commit -m "Git commit message here"：commit message 首字母要大写，限制 50 个单词之内，不要用句号结束，独占一行，如需要进一步解释，则用空行分开摘要和正文，正文每行不超过 72 个单词，主要解释这次 commit 解决什么问题，说明代码变动的动机，以及与以前行为的对比，使用祈使语句，即现在时。