1. Tagging
像大多数VCS软件一样，Git可以标记Tag。通常，人们利用这个功能来标注软件的不同发布版本（v1.0，v2.0等等）
Git支持两种创建Tag的方式：
1. 轻量级的（lightweight）
2. 带标注的（annotated）
我们重点学习第二种方式。
1.1 创建Tag
git tag -a v1.4 -m "my version 1.4"
1.2 查看所有Tag
git tag
1.3 查看某一个Tag
git show v1.4
1.4 推送Tag
默认情况下，"git push"命令并不会将本地的Tag推送到远程仓库。你需要使用以下命令明显地把本地所有的Tag推送到远程仓库：
git push origin --tags
也可以只推送某一个Tag到远程仓库
git push origin v1.4
这样的话，当其他人clone或者pull的时候，也会获得所有的Tag。
1.5 删除Tag
删除本地Tag
git tag -d v1.4
注意以上的这个命令并不会删除远程仓库的Tag，为了删除远程仓库中的Tag，需要使用以下命令
git push origin --delete <tagname>
1.6 检出Tag
检出Tag，使用以下的命令：
git checkout v2.0
然而这个命令会让你的仓库陷入“detached HEAD”状态，该状态会带来不好的影响。
在"detached HEAD"状态下，如果你做了新的修改，并且进行了提交，之前已经标记好的Tag和它所标记的文件是不会发生任何改变的，而你所作的新的提交将存在一个临时的分支上，且一旦切换到其他分支，这个临时分支将很难找回，除非你记得住该临时分支的精确Hash，如下：
如果从打算创建tag的一开始，就直接使用以下的命令，以上的问题就不会出现：
git checkout -b version2 v1.0
这个命令也会检出一个Tag，并且当你做了修改并且提交时，新的提交会被保存到version2这个分支上。你甚至可以沿着这个分支继续开发，在另一个方向上不断创新。
1.8 Tag的意义
对我们，我们可以在开发项目期间，对软件进行迭代升级，每当到了一个可发布的节点上时，就可以打一个Tag。这样我们在将来可以随时检出Tag，来打包生成软件的不同版本。
2. Rebase
在Git中，有两种合并分支的方式：git merge 和 git rebase。本节我们将详细学习 git rebase 命令的使用，以及在什么情况下适合使用 git rebase，在什么情况下不适合使用 git rebase。
2.1 The Basic Rebase
考虑以下场景：
正如我们已经知道的，我们可以使用
除了用git merge来合并分支外，我们还有另一个选择：git rebase 。 我们可以将experiment分支中的C4提交，通过git rebase命令，放在master分支中的C3提交的右边这就是所谓的rebasing。命令如下：
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
效果如下图所示：
git rebase 的工作流程是这样的：先找到两个分支（一个是当前分支experiment，另一个是master分支）的最近的共同祖先（C2）。然后把当前所在分支（从共同祖先之后）的所有修改存入一个临时文件中，最后把这些临时文件中的修改，按顺序一个一个地合并到目标分支最近提交的右边。如果有冲突，则在解决冲突之后，键入 git rebase --continue 继续进行 rebase 操作。
在git rebase操作完成以后，我们可以切回master分支，进行一个快速合并：
$ git checkout master
$ git merge experiment
此时，上图中的C4’与“git merge图”中的C5是完全一样的。也就是 git merge 和 git rebase 合并支的最终效果别无二致。但是用git rebase来合并分支会让提交历史看起来很“干净”。如果你在一个被rebase的分支上查看提交历史，会发现提交历史的图是线性的：就好像所有提交都是按顺序一个一个进行的，尽管这些提交曾经可能存在于两个并行的提交。
再次强调：无论是使用git rebase和git merge来合并分支，最终的效果是一样的，它们的区别仅仅只是提交历史不同而已。
2.2 More Interesting Rebases（选修）
考虑以下场景：
你从master分支（的C2提交上）创建了一个server分支，你打算在这个server分支上开发server-side的新功能，并在server分支上进行了一次提交（C3），随后你又从server分支（的C3提交上）创建了另一个client分支，并在client分支上进行了两次提交（C8、C9）。最后，你切换回master分支，并做了两次提交（C5、C6）。
假设此时你想合并client分支上的提交到master主分支，以发布一个软件的发行版，但此时你又不想将server分支上的提交合并到master中。说得直白一点：范围就是client上的所有提交（C3、C8、C9），去掉该范围中同时也属于server的提交（C3），把剩下的提交（C8、C9）合并到master。
以下命令可以满足这个需求
git rebase --onto master server client
该命令的含义是：先找到client分支，然后找出client分支是从server分支的哪次提交创建出来的（就是C3提交），把从那次提交（C3提交）之后的所有提交合并到master分支最新提交的右边。听起来有点复杂，但是该命令确实很强大，效果如下：
现在你可以让master合并client分支了，这是一种“快速合并”
$ git checkout master
$ git merge client
假设在server分支经过测试后，你决定把server分支也合并到master分支上。此时你还在master分支上，原本你需要先从master切换到server分支，然后在执行 git rebase master 来把server分支的提交合并到master分支上的，但通过以下命令，你就不需要先切换到server分支上：
git rebase master server
该命令会直接把server分支上的提交，放到master分支最新提交的右边：
然后快速合并master和server：
$ git checkout master
$ git merge server
然后删除server和client分支。此时client和server的所有提交都在master分支上，server和client分支也就没有存在的价值了：
$ git branch -d client
$ git branch -d server
2.3 The Perils of Rebasing
git rebase也是有缺点的，不能滥用。总结一句话就是：
Do not rebase commits that exist outside your repository and that people may have based work on.
翻译版本一：git rebase命令最好在你的本地仓库中使用，不要让git rebase命令应用于远程仓库。
翻译版本二：你可以在本地仓库随意地对你本地的提交进行rebase，但是最好不要将远程仓库中以及存在的分支进行rebase操作。
翻译版本三：rebase只用于你的本地仓库。一旦提交推送到了远程仓库，就不要试图对已经push到远程仓库的提交进行rebase。
无论怎么翻译，都是那一个意思。如果你遵守这条准则，那么你就不会惹来什么麻烦。但如果你违背了这条准则，你的同事就会讨厌并鄙视你了。
让我们来看一个例子，看看违反这条准备回带来什么麻烦。
第一步：你克隆了远程仓库到本地，并且在本地仓库中做了一些提交
第二步：其他小伙伴也把该远程仓库克隆下来，也做了一些提交，这些提交中包含了合并分支的操作，然后将这些提交push到了远程仓库中。随后你把远程仓库的最新修改pull了下来，并且与你本地自己的分支进行了合并，此时模型看起来是这个样子：
第三步：刚刚的那个小伙伴，决定使用rebase来替换merge，然后他又使用了 git push --force 来覆盖了远程仓库，随后你又从远程仓库pull了最新修改下来：
这个rebase操作，实际上是丢弃了C4和C6提交，而C6提交恰恰是你C7提交所依赖的一个提交。此时问题就显现了出来：如果你此时进行pull操作，且为了把最新修改合并到你自己的分支中，你将会再做一次合并的提交（下图中的C8）：
如果你运行git log命令，你将会看到上面这样的提交历史，你会发现有两个提交（C6和C4'）有着相同的作者、日期和提交信息（因为C4'是由C4和C6 rebase 而生成的，C4'和C6的提交效果就是一样的），这会让人感到困扰。更糟糕的是，如果此时你进行了push操作，包含C4和C6的修改被推送到了远程仓库中，之前的那个小伙伴随后把包含C4和C6的修改pull了下来，就会发现他之前通过rebase丢弃掉了C4和C6，又死灰复燃了！ 避免这样混乱的问题的关键在于：遵守上面那条准则！
当然，如果你发现你确实已经陷入这样的问题当中，也不是不能解决这个问题。参考https://git-scm.com/book/en/v2/Git-Branching-Rebasing中的Rebase When You Rebase”。
2.4 Rebase vs. Merge
现在你已经学会了git merge和git rebase。这两个命令都是用来合并分支的，那么应该如何抉择呢？
如果“提交历史”是为了记录开发的过程实际发生了什么，就不应该使用git rebase。因为git rebase会掩盖开发过程中的事实。尽管git merge会产生一系列的看起来较为混乱的提交，但它却如实地记录了开发过程中实际发生了什么。
如果“提交历史”是为了描述你的项目是按什么逻辑一步一步进展的，那就不应该使用git merge，毕竟git merge会让提交历史显得混乱。在你开发的过程中，你可以会需要记录一些失误，bug修复之类的修改。但当你打算把你的成果向全世界展示的时候，你更应该展示出一个更加连贯的线性故事，故事中描述了如何从A步骤进展到B步骤，再从B步骤到C步骤的过程。此时就应该使用git rebase。这样项目的读者就会有一个清晰的脉络来理解项目的进展。
但是具体问题需要具体分析，在什么情况使用什么命令，merge 还会 rebae，最终取决于你和你的团队。
最佳实践：在push之前，通过rebase来让你的提交看起来清爽一些。同时永远不要把已经push到远程仓库的提交，再次进行rebase。
3. SSH协议
