Git 的原理与使用（上）与Git 的原理与使用（中） 中介绍了Git及其相关概念，本地与远程的Git命令操作等，本文接着以上两篇，将对Git的标签管理、多人协作与企业级开发模型三方面展开介绍。
七、标签管理
1.理解标签
标签 tag，可以简单地理解为是对某次 commit 的一个标识，相当于起了一个别名。
例如，在项目发布某个版本时，通常会针对最后一次 commit 起一个 v1.0 这样的标签，来标识“里程碑”的意义。
这有什么用呢？相较于难以记住的 commit id ， tag 是一个自定义的、更简短好记且有意义的标识。在当我们需要回退到某个重要版本时，直接使用标签便能很快地定位到。
2.创建标签
（1）如何创建标签
我们可以给某一次提交（commit）来“打标签”。
在Git中打标签非常简单。
首先切换到需要打标签的分支上（git chekcout <分支名>），然后敲命令
git tag [name]
就可以打上一个新标签：
git tag v1.0 # 默认对最新的一次提交进行打标签
回车之后，会默认给我们最新一次的提交打一个标签，此处打上的标签就是v1.0。
可以用命令
git tag
可以查看当前存在的所有标签（注：标签不是按时间顺序列出，而是按字母排序的）：
执行tree .git，查看打了标签之后git版本库中有什么变化：
（2）如何在指定的commit上打标签
首先找到历史提交的某个commit id，然后通过命令打上即可：
# 命令 git tag [name] [commitID] # 对44e30f7这一次提交进行打标签 git tag v0.9 44e30f7
（3）如何给新创建的标签添加标签说明
Git 还提供了创建带有说明标签的功能。用-a指定标签名，-m指定说明文字，格式为：
git tag -a [name] -m "XXX" [commit_id]
例如：
git tag -a v8.0 -m "important tag:xxxx" 7222302 # 对7222302这一次提交进行打标签，并附上标签说明
使用命令
git show [tag名称]
可以查看这个tag对应的详细信息，包括tag的标签说明：
3.操作标签
（1）删除标签
如果标签打错了，也可以删除：
git tag -d <tag名称>
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
（2）推送本地标签到远程仓库
本地的标签也可以推送到远程仓库中。
远端码云上也有标签一栏：
如果要推送某个标签到远程，使⽤命令
git push origin <tagname>
此时查看远端码云，可以看到标签已经被更新：
如果本地有很多标签，也可以一次性的全部推送到远端：
git push origin --tags
（3）删除远程标签
如果标签已经推送到远程，要删除远程标签，会相对麻烦一点：先从本地删除，然后把操作push到远端：
git push origin :<tag名称>
（冒号后面跟tag的名称）
git push origin :refs/tags/v1.0
在码云上查看，已删除成功：
八、多人协作
1.完成准备工作
目前，我们已经完成了如下学习：
基本完成Git的所有本地库的相关操作，git基本操作，分支理解，版本回退，冲突解决等等。
申请码云账号，将远端信息clone到本地，以及推送和拉取。
为了实现多人协作开发，我们先做一些准备工作来模拟有两个用户协作开发的情景：
之前的演示中，我们已经将项目clone到了Linux主机上，那么现在我们再将同一个远程仓库clone到Windows主机上。远程仓库与主机的关系如下：
注意，在实际开发中，每个用户都有自己的Gitee或Github账号，如果要多人进行协同开发，必须要将用户添加进开发者，用户才有权限进行代码提交：
邀请用户：
至此，我们相当于有了分别在Linux和Windows上针对于同一项目进行协作开发的两个用户。关于用户的准备工作到这里就完成了。
但是目前，我们的仓库中只有一个master主分支。而在实际的项目开发中，在任何情况下其实都是不允许直接在master分支上修改代码的，这是为了保证master分支的稳定。所以在开发新功能时，常常会新建其他分支，供开发时进行迭代使用。
我们可以直接先在远程仓库新建dev分支：
创建成功：
然后，我们在Linux主机上以pull的方式，并在Windows上以clone的方式，把远端仓库同步到本地：
在Linux主机上pull的远程仓库代码
这里补充到了在本地查看远程分支的命令：
git branch -r
pull后便可以看到远程的dev分支：origin/dev，但本地并没有dev分支，因此接着要切换到本地的dev分支供我们进行本地开发。
以下命令会将本地分支和远程分支的进行关系链接：
git checkout -b [本地分支] [远程分支]
查看本地仓库分支和远程仓库分支对应关系：
git branch -vv
建立起连接后，在本地分支和远程分支之间进行push或pull就可以直接使用短命令：
而在Windows中，我们通过clone操作将远程仓库clone至本地即可。
2.同一分支下多人协作（不常见）
现在开发者1在Linux本地对file.txt进行修改，并将修改push到远程仓库：
push后，码云上仓库的dev分支就有了我们上面进行过的修改（在file.txt中增加了一行aaa）。
此时，另一位开发者2（Windows）与开发者1（Linux）协同开发，也在本地新建分支dev：
注意，此处的dev并没有和远程仓库origin/dev关联。因此如果试图直接git pull拉取远程仓库，会失败：
使用
git branch --set-upstream-to=origin/<远程分支名> <本地分支名>
可以手动给二者建立关联：
建立完关联后，如果开发者2在Windows上也要对file.txt文件作修改，并试图push，此时push会失败：
这是因为当前push的commit和开发者1的push的commit有冲突。
解决办法也很简单，Git已经提示我们，正确的做法是先用git pull把最新的提交从origin/dev抓下来，然后，在本地进行合并并解决冲突，最后再推送。
pull提示冲突：
解决冲突：
重新推送：
此时，我们看到远端的码云已经能看到我们的新提交了：
以上就是二位开发者协同开发、遇到冲突并且解决的一个情景。
此后，两名开发者就可以进行协同开发了，不断的 git pull/add/commit/push ，遇到了冲突，就使用我们之前讲的冲突处理方式解决冲突。
对于其中一位开发者来说，要想看到小伙伴的代码，也只需要pull一下即可。
最后不要忘记，虽然我们是在分支上进行多人协作开发，但最终的目的是要将开发后的代码合并到master上去，让我们的项目运行最新的代码。
master没有将dev分支下的内容进行merge，在master下是看不到dev中有的修改的（即“aaa”和“bbb”这两行代码）。
想让dev分支中的代码merge进master，有两种选择：
1、令本地的master分支merge dev，再将本地的master分支push到远端master。这样远端的master分支也就能包含dev分支上的修改了。
tips：在master分支merge dev，是可能会和dev分支出现冲突的。更安全的做法是先让dev来merge master，然后在dev上解决完冲突后，再用master merge dev。
注意：用dev来merge master时，要让master处于最新的状态。存在一种可能：在本地master还未与本地dev合并时，有其他人修改了origin/master导致此时我本地的master并不是最新的，那么再后面将master push到远程的时候，依然可能产生冲突。
master：merge dev之后，就能把master push给origin/master了
2、在远程仓库提一个PR(Pull Request)申请单，然后由仓库的管理员审批这个单子。管理员同意之后，就会在远端自动执行merge操作，将远程的dev分支merge进远程的master分支。【推荐这个方式，因为让审批员审查是对代码的一层保障。】
最后点击「创建Pull Request」，就把这个PR申请提交给了管理员，让管理员审批。
在完成origin/dev分支合并到origin/master分支的操作后，origin/dev分支对于我们来说就没用了，那么dev分支就可以被删除掉。我们可以直接在远程仓库中将dev分支删除掉：
总结一下，在同一分支下进行多人协作的工作模式通常是这样：
首先，在本地发开完后，可以试图 push 自己的修改。
如果push失败，则因为远程分支比你的本地更新，需要先用 git pull 拉取远程分支以更新本地分支。
如果合并有冲突，则解决冲突，并在本地再次提交。
没有冲突或者解决掉冲突后，再用push就能成功。
功能开发完毕，将origin/dev分支 merge 进 origin/master（两种方式），最后删除origin/dev分支。
Git 的原理与使用（下）（二）
+https://developer.aliyun.com/article/1522000?spm=a2c6h.13148508.setting.14.439a4f0eWJ4WIw
