| 命令 | 作用 |
|---|---|
| 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了。
