初始化一个Git仓库，使用git init命令。
添加文件到Git仓库，分两步：
使用命令git add，注意，可反复多次使用，添加多个文件；使用命令git commit -m，完成。工作区（Working Directory）
就是你在电脑里能看到的目录，比如learngit文件夹就是一个工作区。
版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
现在，你又理解了Git是如何跟踪修改的，每次修改，如果不用git add到暂存区，那就不会加入到commit中。
例如：第一次修改 -> git add -> 第二次修改 -> git add -> git commit
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git restore <file>。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD，就回到了场景1，第二步按场景1操作。或者使用git restore --staged <file>，就回到场景一。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考[版本回退](# 版本回退)一节，不过前提是没有推送到远程库。
一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了
$ rm test.txt这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
$ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) deleted: hehe.txt no changes added to commit (use "git add" and/or "git commit -a")现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：
$ git rm hehe.txt rm 'hehe.txt' $ git commit -m "remove hehe.txt" [master 7c9f18a] remove hehe.txt 1 file changed, 1 deletion(-) delete mode 100644 hehe.txt另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
$ git restore hehe.txtgit restore其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。
Git支持多种协议，包括https，但ssh协议速度最快。
使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
$ git clone git@github.com:liqudong/gitskills.git 创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
首先，我们创建dev分支，然后切换到dev分支：
$ git checkout -b dev Switched to a new branch 'dev'git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev $ git checkout dev Switched to branch 'dev'然后，用git branch命令查看当前分支：
$ git branch * dev mastergit branch命令会列出所有分支，当前分支前面会标一个*号。
然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：
Creating a new branch is quick.然后提交：
$ git add readme.txt $ git commit -m "branch test" [dev b7081ba] branch test 1 file changed, 2 insertions(+), 1 deletion(-)现在，dev分支的工作完成，我们就可以切换回master分支：
$ git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'.切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
现在，我们把dev分支的工作成果合并到master分支上：
$ git merge dev Updating 5e9fb4e..b7081ba Fast-forward README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的：
$ cat README.md # gitskills Creating a new branch is quick.注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
合并完成后，就可以放心地删除dev分支了：
$ git branch -d dev Deleted branch dev (was b7081ba).删除后，查看branch，就只剩下master分支了：
$ git branch * master因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
tips:
一.版本导致的差别：
1.x版本：
（1）.git add all可以提交未跟踪、修改和删除文件。
（2）.git add .可以提交未跟踪和修改文件，但是不处理删除文件。
2.x版本：
两者功能在提交类型方面是相同的。
二.所在目录不同导致的差异：
（1）.git add all无论在哪个目录执行都会提交相应文件。
（2）.git add .只能够提交当前目录或者它后代目录下相应文件。
switch
我们注意到切换分支使用git checkout，而前面讲过的撤销修改则是git checkout --，同一个命令，有两种作用，确实有点令人迷惑。
实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：
创建并切换到新的dev分支，可以使用：
$ git switch -c dev直接切换到已有的master分支，可以使用：
$ git switch master使用新的git switch命令，比git checkout要更容易理解。
小结
Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout或者git switch
创建+切换分支：git checkout -b或者git switch -c
合并某分支到当前分支：git merge
删除分支：git branch -d
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图。
$ git log --graph --pretty=oneline --abbrev-commit * 5f26087 (HEAD -> master) conflict fixed |\ | * d277416 (feature1) AND simple * | 479a33f & simple |/ * 038e80b remove readme.md * 1e07dbd (origin/master) add readme.txt * 6e99bc7 branch test * d272252 remove haha * ed143f2 add haha * 7c9f18a remove hehe.txt * db7882f add test.txt * fc8524e remove test.txt * 7b04edb add test.txt * ce6b5d6 delet hehe.txt * 0b3939a git tracks changes * c9ed834 git tracks changes * a0e27f8 understand how stage works * 06f5a85 append GPL * 22c729b add distributed * 192c21f wrote a hehe file * 94d4ceb wrote a readme file通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge：
首先，仍然创建并切换dev分支：
$ git switch -c dev Switched to a new branch 'dev'修改readme.txt文件，并提交一个新的commit：
$ git add readme.txt $ git commit -m "add merge" [dev f52c633] add merge 1 file changed, 1 insertion(+)现在，我们切换回master：
$ git switch master Switched to branch 'master'准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，我们用git log看看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit * 3da095d (HEAD -> master) merge with no-ff |\ | * d77f8f4 (dev) add merge |/ * 5f26087 conflict fixed可以看到，不使用Fast forward模式，merge后就像这样：
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
小结
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
$ git status On branch dev Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
$ git stash Saved working directory and index state WIP on dev: f52c633 add merge现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git checkout -b issue-101 Switched to a new branch 'issue-101'现在修复bug，需要把“Git is free software …”改为“Git is a free software …”，然后提交：
$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：
$ git switch master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)太棒了，原计划两个小时的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@{0}: WIP on dev: f52c633 add merge工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：
$ git stash pop On branch dev Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)再用git stash list查看，就看不到任何stash内容了：
$ git stash list你可以多次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 branch * dev master $ git cherry-pick 4c805e2 [master 1d4b803] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。
有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
master $ git cherry-pick 4c805e2 [master 1d4b803] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
Git自动给dev分支做了一次提交，注意这次提交的commit是`1d4b803`，它并不同于master的`4c805e2`，因为这两个commit只是改动相同，但确实是两个不同的commit。用`git cherry-pick`，我们就不需要在dev分支上手动再把修bug的过程重复一遍。 有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要`git stash`命令保存现场，才能从dev分支切换到master分支。 ### 小结 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除； 当手头工作没有完成时，先把工作现场`git stash`一下，然后去修复bug，修复后，再`git stash pop`，回到工作现场； 在master分支上修复的bug，想要合并到当前dev分支，可以用`git cherry-pick `命令，把bug提交的修改“复制”到当前分支，避免重复劳动。