命令	作用
git init	在某目录（不一定是空目录）中初始化一个空的Git仓库(empty Git repository)
git add	添加文件到暂存区
git commit -m "注释"	将暂存区里的改动给提交到本地的版本库
git status	查看最后一次git commit之后文件又有哪些新的改动
git diff	查看具体改动的细节
git log	查看历次commit，不会显示因reset而被抹掉的commit
git reflog	查看历次commit，包括因reset而被抹掉的commit，所以通常只在打算reset到更加新的commit的时候才用
git reset --hard HEAD^	属于回退操作： 立即回退到上1个commit
git reset --hard HEAD~1	属于回退操作： 同上
git reset --hard 109534a	属于回退操作： 立即还原到HEAD以109534a开头的commit
git checkout -- xxx.txt	属于回退操作： 在没有add文件之前，打算回退对文件的修改，但是编辑器又关掉了，无法Ctrl+Z，此时可以用checkout，原理是从最后一个commit中找到这的文件，然后还原
git reset HEAD xxx.txt	属于回退操作： 类似上一条，在add文件之后，打算回退对文件的修改，就先用这条命令，然后再用git checkout -- xxx.txt。git reset HEAD xxx.txt是git add xxx.txt的反操作。可见，git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。
git rm	删除一个工作区内的文件，跟平常利用IDE或者操作系统删除文件是一样的效果，通常没必要用这个命令
git remote add origin git@github.com:michaelliao/learngit.git	将远程仓库添加到本地，远程仓库默认叫origin
git push -u origin master	先在远程仓库建立叫master的分支，然后提交代码到远程仓库的master分支，这个带-u的命令通常只需最早的时候执行一次
git push origin master	常用命令，将当前本地分支推送到远程origin仓库的master分支，如果远程的仓库正好叫origin，且分支正好是master，则通常origin master可以省略
git push origin dev	类似上条，远程分支叫dev
git clone git@github.com:michaelliao/gitskills.git	克隆一个远程库到本地
git branch dev	创建dev分支，此时，比如当前分支是master分支，那么dev分支与master分支同时指向了最新的那个commit
git branch -d dev	删除dev分支
git checkout dev	切换到dev分支，这一步属于危险操作，因为会覆盖工作区，也会清空暂存区，所以请先确保工作区的文件都已经add，暂存区的文件都已经commit
git checkout -b dev	创建dev并立即切换到dev分支，等于2条命令的合并：git branch dev（创建分支）和git checkout dev（切换分支）
git branch	查看所有分支概况
git merge dev	将dev合并到当前分支上
git stash	将没有add的所有代码全部储存到某个栈，然后将工作区恢复到上一次add之前的状态，这个功能用于：1、手头工作没完成，线上出了bug，所以你需要工作区回退到线上版本，然后改bug，然后立即提交，然后继续你手头工作，这时候用stash可以储存你的手头工作，等bug修复了，再用git stash apply还原手头工作。2、你想尝试一种编程思路，但是不确定是否可行，这时候你可以储存你的代码，然后继续尝试，半个小时之后你可能发现确实行不通，那么立即用git stash apply还原。
git stash apply	将stash储存的最新的那个状态还原出来
git stash apply stash@{0}	将stash储存的编号为0的状态还原出来
git stash drop	删掉最新的那个状态
git stash pop	将stash储存的状态还原出来同时删掉这个状态
git stash list	所有stash过的状态列表
git branch -D <name>	强制删除未被合并的分支
git remote	查看远程仓库的名称，远程库默认名称就是origin
git remote -v	同上，只是更详细
git tag v1.0	给当前最新的commit打一个标签叫做v1.0
git log --pretty=oneline --abbrev-commit	查看历史所有commit跟标签的对应关系
git tag v0.9 f52c633	从上句命令的结果中查出历史的某个commit，然后给它打标签
git tag	列出所有标签，按照字母顺序排列
git show v0.9	查看该标签的具体信息
git tag -a v0.1 -m "version 0.1 released" 1094adb	给1094adb打标签且加注释
git tag -d v0.1	删除标签

名词	解释
origin	远程仓库的默认名称
工作区（Working Directory）	程序员在电脑里能看到的目录
版本库（Repository）	.git目录
暂存区（stage或者叫index）	只用来暂存git add的文件，一旦commit，就清空暂存区
分支（branch）	一个工程可以有不同的分支，以便于多人协同工作
master分支	git工程初始化之后默认生成的第一个分支
HEAD	一个指针，用于指向某个分支，而该分支指向的commit是确定的，所以你可以说HEAD是指向分支的，也可以说是指向commit的。
提交（commit）	提交跟分支的关系是，提交是基于时间轴的，分支是提交身上挂着的一个标签，一个提交可以有多个分支标签，一个提交可以既属于master分支，也属于dev分支，还属于其他xxx分支。现在，把所有带有dev分支标签的提交高亮，串起来，就形成了dev分支概念。同样的代码commit到不同分支，就等于多个分支都指向这个commit
快进模式（Fast forward模式）	默认的合并方式，将落后的那个分支快进到领先的那个分支上，无论当前分支是领先的还是落后的分支，不产生新的commit
git merge --no-ff -m "注释" dev	禁用快进模式的合并方式，效果是，dev分支不做任何改变，新建一个commit，最后让当前分支（比如master分支）指向这个commit，这个commit就是合并的结果。跟FF模式的区别在于产生新的commit

解决合并冲突

2个分支的文件发生冲突的时候，VS Code会给你4个选择，选择其一之后，保存文件，然后git add 该文件，然后commit，这时候再合并就没问题了。

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

git-br-policy

哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程同步；

• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

当你修改的文件有其他人也在修改，且他比你先推送到远程，怎么办？

等你推送的时候会发生：

$ git push origin dev
To github.com:michaelliao/learngit.git
 ! [rejected]        dev -> dev (non-fast-forward)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

意思是，你需要先把别人的新文件拉取下来，然后在你电脑里合并，然后才能推送。做法：先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送。

第一步，如果你的本地分支跟远程分支没有建立链接，则先建立链接：

git branch --set-upstream-to=origin/dev dev

origin/dev是远程分支，最后的dev是本地分支。

第二步，git pull。然后必然会提示文件冲突，git会自动尝试合并，不过大部分时候是失败的，需要人脑合并。通常VS Code会给出便捷的合并提示。

第三步，git commit -m "fix env conflict"以及git push origin dev，就OK了。