全局设置
用户名和邮箱

git config --global user.name "xxx" //设置用户名为xxx
git config --global user.email "xxx" //设置邮箱为xxx

克隆远程仓库

git clone <仓库名> // 克隆远程分支时，只会克隆master分支，其余分支需要单独检出

初始化仓库

git init

把工作区的文件添加到暂存区

git add . // 添加所有的文件到暂存区
git add <文件名> // 添加当前文件到暂存区

把暂存区中的文件提交到本地仓库

git commit -m"初始化项目" //把所有的文件都提交到本地仓库,并带上描述信息

查看当前分支的状态

git status // 会有一些提示，根据提示可做下一步的操作

分支
检查本地分支

git branch

检查远程分支

git branch -r

检查本地和远程分支

git branch -a

创建分支，并切换

git switch -c dev //创建并切换到dev分支
// 如果已存在该分支，则报错 fatal: A branch named 'dev' already exists.

切换本地分支

git switch dev //切换到dev分支

检出远程分支

git checkout -b dev origin/dev //检出远程的dev分支到本地新创建的分支dev

删除本地分支

git branch -d dev //删除本地dev分支
git branch -D dev //强制删除本地dev分支（当分支没有被合并使用的时候）

远程分支与本地分支关联

git remote add origin <远程分支的名称>
// 如果报错 fatal: remote origin already exists.
git remote rm origin // 那么需要先删除与origin的远程库的关系

远程分支与本地分支关联

git branch --set-upstream-to <本地分支的名称> origin/<远程分支的名称>

查看提交历史

git log
q // 退出查看

HEAD介绍

我们首先看一下 “HEAD”。HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见。

撤销变更
在 Git 里撤销变更的方法很多。和提交一样，撤销变更由底层部分（暂存区的独立文件或者片段）和上层部分（变更到底是通过哪种方式被撤销的）组成。我们这个应用主要关注的是后者。

主要有两种方法用来撤销变更 —— 一是 git reset，还有就是 git revert。接下来咱们逐个进行讲解。

git reset（用于本地撤销）
git reset HEAD^
git reset HEAD~1

数据从暂存区中 变更到了工作区 代码还是存在的

git revert（用于远程撤销）
git revert HEAD //它会创建一个新的提交，为当前提交的上一个提交信息

最后提交并push远程即可
文件从暂存区回退到工作区

git restore --staged . // 所有文件都退回到工作区

git restore --staged <文件名> // 当前文件退回到工作区

文件从工作区删除

git restore . // 撤销所有文件的修改
git restore <文件名> // 撤销当前文件的修改

移动提交记录

git cherry-pick
git cherry-pick <提交号> //可以是多个提交号

如果你想将一些提交复制到当前所在的位置（HEAD）下面的话， cherry-pick 是最直接的方式了，通常用于bug分支合并到其他分支中（还需要先提交原有分支，而后解决冲突即可）

git rebase

假设一个master（C1）分支中创建了一个dev分支，进行开发，开发到一半的时候，发现线上有一个bug，于是我们就切换到了master分支下面去创建一个bug分支，进行修复bug,最后合并到的master分支（此时为C2），而后切换到dev分支，并使用git cherry-pick <提交号> 修复bug。
当我们在dev分支上把功能开发好了以后，想要把代码合并到master的时候。我们发现并没有和平常一样那么的顺利。为啥呢？因为此时dev分支不是从C2中创建出来的，而是从C1中创建出来的。master分支已经向前进了一步。此时就需要合并，解决冲突，在进行提交

然而先在dev分支上先使用 git rebase master,即拉取master上最新的分支，解决冲突，而后添加到暂存区，而后在执行，git rebase --continue（如果有冲突的话，需要执行该代码） ，push到远程此时在切换到master分支上，再进行合并分支的时候，就不会出现问题。

dev分支中：

git rebase master

//有冲突，解决---start
git add .
git rebase --continue
//有冲突，解决---end

git push origin dev

切换到master分支
git switch master

//合并dev分支到master
git merge dev

git push origin master

远程拉取

git pull // 切换到当前分支下，简写
git pull origin master --allow-unrelated-histories //拉区不下来的时候，强制合并

提交分支到远程

git push origin master // 提交master分支到远程

注意:需要先切到当前分支中

git push // 此命令也可以提交分支，当然最好还是强调一下需要提交到那个分支，一旦分支比较多的话，万一当前分支并不想提交，而你却使用了这个命令，就提交上去了，指定提交的分支，可以避免这些问题：
修改提交描述信息

git commit --amend

输入 i 进入输入模式
修改要修改的描述信息
按下ESC
输入 :wq 回车退出保存修改

储藏代码

应用场景：

在上面介绍的git rebase例子中，有一步的做法有些不合理，当我在dev分支中开发的时候，线上发现一个bug,那么需要从master分支中切出一个bug分支，在 dev分支切换到master分支的时候，此时dev分支是否需要提交？显然是不应该提交的，因为dev分支我才进行了一半，那要怎么办，我既想保留dev中的代码，又不想提交代码生成提交记录。有一个命令可以做到，即 git stash，余下流程还是按照之前的走

git stash //作用：可以把当前工作现场储藏起来，此时再去查看工作树，发现它是干净的，这样你就可以愉快的解决bug了
git stash list // 查看所有储藏的代码列表记录，
git stash apply stash@{0} // 恢复想要恢复的储藏代码，一般都是列表中的第一条数据，stash@{0}可选择填写需要的记录