学习廖雪峰的Git教程所记的笔记，Git教程 - 廖雪峰的官方网站https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
Windows下Git教程
1. Git简介
1.1. Git的诞生
Linus创建了Linux，世界各地人把源代码diff给Linus，2002年前Linus手工合并代码。
2002年后，商业版本控制系统BitKeeper的东家BitMover公司，授权Linux社区免费使用。
2005年，开发Samba的Andrew试图破解BitKeeper的协议，被BitMover公司发现，要收回免费使用权。
Linus本可以道歉，然后管教弟兄们，嗯，这是不可能的。实际情况是：
Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linx系统的源码已经由Git管理了！
牛是怎么定义的呢？大家可以体会一下。
2008年，GitHub网站上线。
1.2. 集中式vs分布式
集中式，版本库是集中存放在中央服务器的，用自己电脑从中央服务器取得最新版本再干活。
干完活，再把自己的活推送给中央服务器。中央服务器好比图书馆，改书，先借，回家改，改完，再放回。
集中式必须联网才能工作。
集中式版本控制，中央服务器出问题了，所有人都没发干活了。
分布式，每个人的电脑上都是一个完整的版本库。
分布式版本控制系统安全性高。每个人电脑都有完整的版本库，一个人的没了，从其他人那复制。
分布式版本控制通常也有一台充当“中央服务器”的电脑，方便交换大家的修改。
还有强大的分支管理功能。
2.安装Git
在Windows上安装Git，在Windows上使用Git，可以从Git官网直接下载安装程序，然后按默认选项安装即可。
安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！
2.1.增加用户名和Email
安装好git后，分布式版本控制，机器自报家门，增加用户名和密码
git config --global user.name username
git config --global user.email xxxxxx@xx.com
查看仓库当前状态
git status
2.2.建文件夹。
mkdir learngit
cd learngit
pwd
2.3.把目录编程Git可以管理的仓库：
git init
查看目录下所有隐藏文件
ls -ah
3.创建版本库
3.1.把文件添加到仓库,可添加多个文件
git add readme.txt file1.txt file2.txt
3.2.把文件提交到仓库
git commit -m "wrote a readme file,add 3 files"
4.时光机穿梭
git add
git commit -m ""
git diff
git status
4.1.版本回退
git log 显示提交日志
git log --pretty=oneline 嫌输出信息太多,可以加上 --pretty=oneline参数
git reset --hard HEAD^
HEAD当前版本;
HEAD^上个版本;
HEAD^^上上个版本;
往上100个版本HEAD~100
cat readme.txt ;git bash里查看文件内容
git reflog ;查看历史命令
git reset --hard commit_id;
4.2.工作区和暂存区
工作区（Working Directory）：电脑里能看到的目录，如learngit就是一个工作区。
版本库（Respository）：工作区有一个隐藏目录.git,这个不算工作区，而是Git的版本库。
版本库里最重要的称为stage（或者叫index）的暂存区，
还有git自动创建的第一个分支master，以及指向master的指针HEAD。
4.3.管理修改
Git比其他版本控制系统设计的优秀，是因为Git跟踪并管理的是修改，而非文件。如：
1
一改：12 后git add，git status 不同
二改：123后git commit，git status 相同
第一次修改 -> git add -> 第二次修改 -> git commit
第一次修改，git add后，工作区的第一次修改 放入 暂存区，准备提交。
第二次修改 没放入 暂存区， git commit 只负责把暂存区的修改提交。
也就是 第一次修改被提交，第二次修改不会被提交。
git status 查看的是暂存区是否更改
git diff HEAD -- readme.txt可以查看版本库和工作区里最新版本的区别。
提交第二次修改，需要再次 git add
4.4.撤销更改
git checkout -- readme.txt ；丢弃工作区的修改，工作区是干净的（clean）。让工作区和暂存区里的版本一致，暂存区版本为最近一次git add的状态
git checkout -- filename ;--很重要，没有--就变成了切换到另一个分支的命令 git checkout branch_name。
git reset HEAD readme.txt ;把暂存区修改撤销掉（unstage），暂存区是干净的（clean）
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
4.5.删除文件
删除工作区文件后，要
git rm filename
git commit -m
5.远程仓库
自行注册GitHub帐号，本地Git仓库和GitHub仓库直接的传输是通过SSH加密的。
第一步：
创建SSH Key。用户主目录下，看看有没有.ssh目录。
有的话，看目录下有没有id_rsa和id_rsa.pub，有的话，直接跳到第二步，
没有的话打开Git Bash，创建SSH Key：
ssh-keygen -t rsa -C "xxxx@xx.com"
把邮件地址换成自己的地址，一直回车，使用默认值。
完成后，目录下有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的密钥对。
id_rsa是私钥id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以告诉任何人。
第二步：
登录GitHub，打开“Settings”，“SSH and GPG keys”页面。
点击New SSH key，填上任意Title，
在Key文本框里粘贴id_rsa.pub文件的内容，
点击下方 Add SSH key。
输入密码，确认。
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。
如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。这个方法我们后面会讲到的，相当简单，公司内部开发必备。
5.1.添加远程库
登陆GitHub，找到“Create a new repo”按钮
在Repository name填入learngit，其他保持默认设置，
点击下方“Create repository”按钮，就成功地创建了一个新的Git仓库：
现在，我们根据GitHub的提示，在本地的learngit仓库下运行命令：
git remote add origin git@github.com:ycanye2009/learngit.git
请千万注意，把上面的ycanye2009替换成你自己的GitHub账户名，
否则，你在本地关联的就是我的远程库，关联没有问题，
但是你以后推送是推不上去的，因为你的SSH Key公钥不在我的账户列表中。
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，
但是origin这个名字一看就知道是远程库。
下一步，就可以把本地库的所有内容推送到远程库上：
git push -u origin master
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，
还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
只要本地作了提交，就可以通过命令：
git push origin master
把本地master分支的最新修改推送至Github。
SSH警告
当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告。
这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，
需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。
Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
这个警告只会出现一次，后面的操作就不会有任何警告了。
小结：
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
5.2.从远程库克隆
git clone git@github.com:ycanye2009/learngit.git
要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。
Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。
6.分支管理
6.1.创建与合并分支。
I.每次提交，都串成一条时间线，这条时间线就是一个分支。在Git里这个分支叫主分支，即master分支。
HEAD不指向提交，而是指向master，master指向提交。
II.创建新分支，例如dev，建立一个dev指针，指向master相同的提交，把HEAD指向dev，表示当前分支在dev上。
III.对工作区的修改和提交，就是针对dev分支了。
IV.dev完成，dev合并到master，master指向当前提交，HEAD指向master。
V.合并完成，删除dev分支。
小结
Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
Fast-forward “快进模式”
删除分支：git branch -d <name>
6.2.解决冲突。
当Git无法自动合并分支时，就必须首先解决冲突。
解决冲突后，再提交，合并完成。
用git log --graph命令可以看到分支合并图
6.3.分支管理策略
I.master分支非常稳定，仅用来发布新版本，平时不能在上面干活。
II.dev分支，不稳定，发布时，把dev分支合并到master上，在master上发布。
小结
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以用普通模式合并，
合并后的历史有分支，能看出来曾经做过合并，
而fast forward合并就看不出来曾经做过合并。
6.4.Bug分支
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
暂存区是公用的，如果不通过stash命令隐藏，会带到其它分支（issue-101）去
幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：git stash
Git的stash恢复，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，用git stash list查看，再git stash pop，回到工作现场。
6.5.Feature分支
开发一个新功能（feature），最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。
6.6.多人协作
I.查看远程库 git remote ;查看远程库详细信息用 git remote -v，无推送权限，则看不到push地址
II.推送分支 切换到master分支，git push origin master;切换到dev分支，git push origin dev
需要推送的分支：
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
III.抓取分支
克隆只会克隆master分支，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，
于是他用这个命令创建本地dev分支： git checkout -b dev origin/dev ；创建与远程仓库同步的分支。
多人协作的工作模式通常是这样：
首先，可以试图用git push origin branch-name推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
小结
查看远程库信息，使用git remote -v；
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。
7.标签管理
发布一个版本时，我们通常先在版本库中打一个标签（tag）。
标签是版本库的快照，是指向某个commit的指针，跟分支很像，但分支可以移动，标签不能移动
创建和删除标签都是瞬间完成的。
tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起
7.1创建标签
打一个新标签,默认标签是打在最新提交的commit上的：git tag v1.0
给某次提交打标签：git tag v10.9 <commit_id>
查看所有标签：git tag ；标签不是按时间顺序列出，而是按字母排序的。
查看标签信息：git show <tagname>
创建带有说明的标签，用-a指定标签名，-m指定说明文字：git tag -a v0.1 -m "version 0.1 released" 3628164
可以通过-s用私钥签名一个标签：
通过-s用私钥签名一个标签：git tag -s v0.2 -m "signed version 0.2 released" fec145a
小结
命令git tag <name>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
git tag -a <tagname> -m "blablabla..."可以指定标签信息；
git tag -s <tagname> -m "blablabla..."可以用PGP签名标签；
命令git tag可以查看所有标签。
7.2.操作标签
删除标签：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 push origin <tagname>可以推送一个本地标签；
命令git push origin --tags可以推送全部未推送过的本地标签；
命令git tag -d <tagname>可以删除一个本地标签；
命令git push origin :refs/tags/<tagname>可以删除一个远程标签。
8.使用GitHub
fork
clone
push
pull request
小结
在GitHub上，可以任意Fork开源仓库；
自己拥有Fork后的仓库的读写权限；
可以推送pull request给官方仓库来贡献代码。
用git remote -v查看远程库信息
9.自义Git
让Git显示颜色，会让命令输出看起来更醒目：git config --global color.ui true
9.1.忽略特殊文件
.gitignore
忽略文件的原则是：
I.忽略操作系统自动生成的文件，比如缩略图等；
II.忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
III.忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
一个完整的.gitignore文件，内容如下：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
# My configurations:
db.ini
deploy_key_rsa
最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。
小结
忽略某些文件时，需要编写.gitignore；
.gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
9.2.配置别名
I.git status别名git st：git config --global alias.st status
当然还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch：
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
II.git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。
既然是一个unstage操作，就可以配置一个unstage别名：
$ git config --global alias.unstage 'reset HEAD'
III.配置一个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"
IV.配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。
V.配置文件放哪了？每个仓库的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]后面，要删除别名，直接把对应的行删掉即可。
VI.而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com
配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。
小结
给Git配置好别名，就可以输入命令时偷个懒。我们鼓励偷懒。
END. 附录：GIT备忘单(GIT CHEAT SHEET)
1.CREATE
Clone an existing repository
$ git clone ssh://user@domain.com/repo.git
Create a new local repository
$ git init
2.LOCAL CHANGES
Changed files in your working directory
$ git status
Changes to tracked files
$ git diff
Add all current changes to the next commit
$ git add .
Add some changes in <file> to the next commit
$ git add -p <file>
Commit all local changes in tracked files
$ git commit -a
Commit previously staged changes
$ git commit
Change the last commit
Don‘t amend published commits!
$ git commit --amend
3.COMMIT HISTORY
Show all commits, starting with newest
$ git log
Show changes over time for a specific file
$ git log -p <file>
Who changed what and when in <file>
$ git blame <file>
4.BRANCHES & TAGS
List all existing branches
$ git branch -av
Switch HEAD branch
$ git checkout <branch>
Create a new branch based
on your current HEAD
$ git branch <new-branch>
Create a new tracking branch based on
a remote branch
$ git checkout --track <remote/branch>
Delete a local branch
$ git branch -d <branch>
Mark the current commit with a tag
$ git tag <tag-name>
5.UPDATE & PUBLISH
List all currently configured remotes
$ git remote -v
Show information about a remote
$ git remote show <remote>
Add new remote repository, named <remote>
$ git remote add <shortname> <url>
Download all changes from <remote>,
but don‘t integrate into HEAD
$ git fetch <remote>
Download changes and directly
merge/integrate into HEAD
$ git pull <remote> <branch>
Publish local changes on a remote
$ git push <remote> <branch>
Delete a branch on the remote
$ git branch -dr <remote/branch>
Publish your tags
$ git push --tags
6.MERGE & REBASE
Merge <branch> into your current HEAD
$ git merge <branch>
Rebase your current HEAD onto <branch>
Don‘t rebase published commits!
$ git rebase <branch>
Abort a rebase
$ git rebase --abort
Continue a rebase after resolving conflicts
$ git rebase --continue
Use your configured merge tool to
solve conflicts
$ git mergetool
Use your editor to manually solve conflicts
and (after resolving) mark file as resolved
$ git add <resolved-file>
$ git rm <resolved-file>
7.UNDO
Discard all local changes in your working
directory
$ git reset --hard HEAD
Discard local changes in a specific file
$ git checkout HEAD <file>
Revert a commit (by producing a new commit
with contrary changes)
$ git revert <commit>
Reset your HEAD pointer to a previous commit
…and discard all changes since then
$ git reset --hard <commit>
…and preserve all changes as unstaged
changes
$ git reset <commit>
…and preserve uncommitted local changes
$ git reset --keep <commit>