廖雪峰教程笔记，原文链接：https://www.liaoxuefeng.com/wiki/896043488029600
开始！
git只能管理文本文件,不要用txt文本编辑器编辑文件
初始化一个文件夹为git库，可以管理这个库了
git init
添加建到 git 库
git add <file> # 把文件添加到仓库
git commit -m <message> # 把文件提交到仓库
查看git状态
git status
查看具体改动
git diff
查看已提交的记录
git log
git log --pretty=oneline # 简化输出
版本切换，回退
HEAD:当前版本
HEAD^:上一个版本
HEAD^^:上上一个版本
HEAD~100:往上100个版本(写100个^,不可行)
git reset --hard commit_id
git reset --hard HEAD^ # 回退到上一个版本
git reset --hard 1000a # 切换到1000a id的版本
回退同步远程：
git push -f origin dev
查看操作记录，可以查找回退前，未来的版本
git reflog
每次修改，如果不用git add到暂存区，那就不会加入到commit中,commit 只提交add到暂存区的修改。
Git跟踪并管理的是修改，而非文件。
git diff HEAD -- re.txt # 查看工作区和版本库文件的区别
status中：Untracked files 没有被追踪的文件，说明没有 add。
放弃工作区的修改：
git checkout -- re.txt # discard changes 放弃工作区的修改
命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt自修改后已经添加到暂存区，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。
放弃暂存区的内容，返回到工作区：
git reset HEAD <file>
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。
删除文件，文件就从版本库中被删除：
先手动删除文件，然后使用git rm
rm aaa.py
git add aaa.py
git commit -m 'rm aaa.py'
git rm aaa.py
git commit -m 'rm aaa.py'
从版本库中恢复：git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
注意：从来没有被添加到版本库就被删除的文件，是无法恢复的！
小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
git checkout -- aaa.py
远程仓库
创建ssh 密钥：
ssh-keygen -t rsa -C "youremail@example.com"
将 id_rsa.pub 添加到 GitHub SSH Key 中，这样就建立好了 ssh 方式提交拉取数据的基础。
ssh 确保：只有自己能 push ，别人只能看（公开库）
建立ssh连接：
git remote add origin git@github.com:用户名/仓库名.git
# 连接名称为 ：origin。这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
将本地已有的库推送到远程库：
git push -u origin master
# 将本地的 master分支 推送到 远程的 master分支，第一次推送master分支的所有内容。
# 由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
从现在起，只要本地作了提交，就可以通过命令：
git push origin master
把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！
SSH警告
当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：
The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?
这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。
Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
这个警告只会出现一次，后面的操作就不会有任何警告了。
如果你实在担心有人冒充GitHub服务器，输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。
删除远程库连接
如果添加连接地址错误，需要删除这个远程库的连接
查看远程连接：
git remote -v
删除 origin 连接：
git remote rm origin
克隆远程库
git clone git@github.com:michaelliao/gitskills.git
还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。ssh协议速度最快。
分支管理
创建并切换到 dev分支
git checkout -b dev # -b参数表示创建并切换
相当于：
git branch dev # 创建分支
git checkout dev # 切换分支
查看分支：
git branch # git branch命令会列出所有分支，当前分支前面会标一个*号。
合并分支：
# 切换到分支 master分支上，将 f_wl分支 合并到 master分支
git checkout master
git merge f_wl
删除分支：
git branch -d f_wl
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
switch
切换分支：git checkout <branch>，和撤销修改：git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。
实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：
创建并切换到新的dev分支，可以使用：
$ git switch -c dev
直接切换到已有的master分支，可以使用：
$ git switch master
使用新的git switch命令，比git checkout要更容易理解。
创建分支
# 基于dev创建的分支f_wl2
AzureAD+WangLin@LAPTOP-LWANG1 MINGW64 ~/Desktop/gitclone/gittest (dev)
$ git switch -c f_wl2
# 文件和dev是一样的
AzureAD+WangLin@LAPTOP-LWANG1 MINGW64 ~/Desktop/gitclone/gittest (f_wl2)
$ ls
dev_aaa.py dev_bbb.py gittest1.py
AzureAD+WangLin@LAPTOP-LWANG1 MINGW64 ~/Desktop/gitclone/gittest (dev)
$ ls
dev_aaa.py dev_bbb.py gittest1.py
# 基于master创建的分支f_wl_master
AzureAD+WangLin@LAPTOP-LWANG1 MINGW64 ~/Desktop/gitclone/gittest (master)
$ git branch f_wl_master
# 文件和master是一样的
AzureAD+WangLin@LAPTOP-LWANG1 MINGW64 ~/Desktop/gitclone/gittest (f_wl_master)
$ ls
gittest1.py
AzureAD+WangLin@LAPTOP-LWANG1 MINGW64 ~/Desktop/gitclone/gittest (master)
$ ls
gittest1.py
结论：创建分支时，要注意当前是那个分支，即基于哪个分支创建新的分支。即复制当前分支为新的分支。
解决冲突
当合并分支时，出现冲突，打开冲突文件，可以发现：
<<<<<<< HEAD
master冲突
=======
合并冲突
>>>>>>> f_wl_master
合并失败：readme.txt 有冲突，需要打开该文件解决。
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，修改需要保留那个部分
master冲突 # 保留了当前分支的这一条内容，舍弃‘合并冲突’这条 f_wl_master 的内容
再次add，commit
$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed
查看分支合并情况：
git log --graph --pretty=oneline --abbrev-commit # q 退出
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图。
Fast forward 合并 与 --no--ff
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息，看不出来时什么分支合并的，也没有记录，相当于一条分支。
强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息，能够看到时什么分支，有记录。
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
--no--ff 合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。记录本次合并。
合并后，我们用git log看看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在自己的分支上，比如 ：f_wl 。f_wl 分支是不稳定的，到某个时候，比如1.0版本发布时，再把f_wl分支合并到master上，在master分支发布1.0版本；
dev 分支可以作为测试分支。
测试时，将 开发分支 f_wl 合并到 dev分支
测试完成后，发布新版本，将 开发分支 f_wl 合并到 master分支
或者 dev当作工共的开发分支。
干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
Bug分支
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？如果不提交就不能切换分支。
可以：
$ git stash # 把当前工作现场“储藏”起来，等以后恢复现场后继续工作
修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：
太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！
$ git switch dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
$ git stash list # 查看stash的改动
stash@{0}: WIP on dev: f52c633 add merge
恢复改动，有两个办法：
1 用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
git stash apply # 恢复最新的，或指定 stash@{0}；但是恢复后，stash内容并不删除
git stash drop # 删除最新的，或指定 stash@{0}
2 用git stash pop，恢复的同时把stash内容也删了：
$ git stash pop # 恢复并删除最新的，或指定 stash@{0}
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
$ git stash apply stash@{0}
在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？
有木有更简单的方法？
有！
同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
将这次改动给 dev 分支 也改一遍
Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
开发分支feature
开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。
多人协作及远程分支
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
查看远程库的信息
$ git remote
origin
git remote -v显示更详细的信息
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支
git push origin f_wl
拉取分支
git pull
在本地创建和远程分支对应的分支
git checkout -b f_wl origin/f_wl # 本地和远程分支的名称最好一致
建立本地分支和远程分支的关联
git branch --set-upstream f_wl origin/f_wl
因此，多人协作的工作模式通常是这样：
- 首先，可以试图用
git push origin <branch-name>推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
变基
git rebase
标签管理
发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。
标签是commit的一个对应，可以方便的记录版本。
切换到分支
敲命令git tag <name>就可以打一个新标签，默认为HEAD
$ git tag v1.0
可以用命令git tag查看所有标签：
$ git tag
v1.0
指定标签到某个版本
git log --pretty=oneline --abbrev-commit # 查看版本
git tag v0.2 f73hfu3 # 对 f73hfu3 版本号 标签为 v0.2
注意，标签不是按时间顺序列出，而是按字母排序的。
查看标签信息
git show <tagname>
创建带有说明的标签，用-a指定标签名，-m指定说明文字：
$ git tag -a v0.1 -m "version 0.1 released" 1094adb
用命令git show <tagname>可以看到说明文字
注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。
删除标签
git tag -d v0.1
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
推送某个标签到远程
git push origin <tagname>
一次性推送全部尚未推送到远程的本地标签
git push origin --tags
删除远程标签,麻烦一点，先从本地删除：
git tag -d v0.9
然后，从远程删除。删除命令也是push：
git push origin :refs/tags/v0.9
查看远程分支
git branch -r
忽略特殊文件
在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
如果你想添加一个文件，添加不了。原因是这个文件被.gitignore忽略了。
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.
强制添加文件：
git add -f App.class
查看是.gitignore的那条规则，阻止了添加文件
git check-ignore -v App.class
还有些时候，当我们编写了规则排除了部分文件时：
# 排除所有.开头的隐藏文件:
.*
# 排除所有.class文件:
*.class
但是我们发现.*这个规则把.gitignore也排除了，并且App.class需要被添加到版本库，但是被*.class规则排除了。
虽然可以用git add -f强制添加进去，但有强迫症的童鞋还是希望不要破坏.gitignore规则，这个时候，可以添加两条例外规则：
# 排除所有.开头的隐藏文件:
.*
# 排除所有.class文件:
*.class
# 不排除.gitignore和App.class:
!.gitignore
!App.class
把指定文件排除在.gitignore规则外的写法就是!+文件名，所以，只需把例外文件添加进去即可。
小结
- 忽略某些文件时，需要编写
.gitignore； .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
配置别名
如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。
$ git config --global alias.st status
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
$ git ci -m "bala bala bala..."
--global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。
配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。
在撤销修改一节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名：
$ git config --global alias.unstage 'reset HEAD'
配置一个git last，让其显示最后一次提交信息：
$ git config --global alias.last 'log -1'
甚至还有人丧心病狂地把lg配置成了：
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
配置文件
每个仓库的Git配置文件都放在.git/config文件中：
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = git@github.com:michaelliao/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[alias]
last = log -1
删除别名：
别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com
配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。
小结
给Git配置好别名，就可以输入命令时偷个懒。我们鼓励偷懒。
搭建git服务器
在远程仓库一节中，我们讲了远程仓库实际上和本地仓库没啥不同，纯粹为了7x24小时开机并交换大家的修改。
GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器作为私有仓库使用。
搭建Git服务器需要准备一台运行Linux的机器，强烈推荐用Ubuntu或Debian，这样，通过几条简单的apt命令就可以完成安装。
假设你已经有sudo权限的用户账号，下面，正式开始安装。
第一步，安装git：
$ sudo apt-get install git
第二步，创建一个git用户，用来运行git服务：
$ sudo adduser git
第三步，创建证书登录：
收集所有需要登录的用户的公钥，就是他们自己的id_rsa.pub文件，把所有公钥导入到/home/git/.ssh/authorized_keys文件里，一行一个。
第四步，初始化Git仓库：
先选定一个目录作为Git仓库，假定是/srv/sample.git，在/srv目录下输入命令：
$ sudo git init --bare sample.git
Git就会创建一个裸仓库，裸仓库没有工作区，因为服务器上的Git仓库纯粹是为了共享，所以不让用户直接登录到服务器上去改工作区，并且服务器上的Git仓库通常都以.git结尾。然后，把owner改为git：
$ sudo chown -R git:git sample.git
第五步，禁用shell登录：
出于安全考虑，第二步创建的git用户不允许登录shell，这可以通过编辑/etc/passwd文件完成。找到类似下面的一行：
git:x:1001:1001:,,,:/home/git:/bin/bash
改为：
git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
这样，git用户可以正常通过ssh使用git，但无法登录shell，因为我们为git用户指定的git-shell每次一登录就自动退出。
第六步，克隆远程仓库：
现在，可以通过git clone命令克隆远程仓库了，在各自的电脑上运行：
$ git clone git@server:/srv/sample.git
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.
剩下的推送就简单了。
管理公钥
如果团队很小，把每个人的公钥收集起来放到服务器的/home/git/.ssh/authorized_keys文件里就是可行的。如果团队有几百号人，就没法这么玩了，这时，可以用Gitosis来管理公钥。
这里我们不介绍怎么玩Gitosis了，几百号人的团队基本都在500强了，相信找个高水平的Linux管理员问题不大。
管理权限
有很多不但视源代码如生命，而且视员工为窃贼的公司，会在版本控制系统里设置一套完善的权限控制，每个人是否有读写权限会精确到每个分支甚至每个目录下。因为Git是为Linux源代码托管而开发的，所以Git也继承了开源社区的精神，不支持权限控制。不过，因为Git支持钩子（hook），所以，可以在服务器端编写一系列脚本来控制提交等操作，达到权限控制的目的。Gitolite就是这个工具。
这里我们也不介绍Gitolite了，不要把有限的生命浪费到权限斗争中。