版本控制器Git5
版本控制器Git(5)
前言
本篇是最后一篇，主要介绍标签管理有关的内容
一、理解标签
- 标签定义：在Git中，标签（tag）是对某次提交（commit）的一个标识，相当于起了一个别名。
- 应用场景示例：
- 在项目发布某个版本时，可以针对最后一次提交起一个如v1.0这样的标签来标识里程碑意义。
- 标签的意义：
- 相较于难以记住的commit id，标签提供了一个更易记忆且有意义的名字。给重要的提交打上标签后，可以 直接查找该标签以找到对应的commit id，从而使用这个commit id进行版本回退
二、创建标签
- 基本创建：
- 切换到需要打标签的分支上，执行 git tag [name] 命令即可创建一个新标签，默认是为最新的提交打标签。
- 查看所有标签：
- 使用git tag命令查看所有已有的标签。
注意，标签不是按时间顺序列出，⽽是按字⺟排序的
- 指定提交创建：
- 如果想要在特定的历史提交上打标签，可以找到该提交的 commit id ，并执行 git tag [标签] [commit id] 。
- 带有描述信息的标签：
- 可以为标签添加描述信息，以便未来查看时了解其背景或内容。使用命令git tag -a [标签] -m “描述” [commit id]。
- 查看标签信息：
- 使用 git show [标签] 命令可以查看特定标签的信息。
三、操作标签
- 删除本地标签：
- 如果标签有误，可以通过git tag -d [标签]命令安全地在本地删除。
因为目前创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
- 推送标签至远程仓库：
- 推送单个标签到远程仓库：git push origin（仓库名） [标签]
- 批量推送所有标签：git push origin –tags
- 删除远程标签：
- 首先从本地删除：git tag -d [标签]
- 然后从远程删除：git push origin :refs/tags/[标签]
四、多人协作场景一
假设我们现在已经做好了准备，现在就要开始进行多人协作开发了
Linux环境下，我们将项目clone到了指定目录， 然后在windows环境下，再clone同一个项目仓库，用来模拟和我们一起开发的小伙伴
注意，课件中是模拟了两个⽤⼾，实际开发中，每个⽤⼾都有⾃⼰的gitee/github账号，如果要多⼈进⾏协同开发，必须要将⽤⼾添加进开发者，⽤⼾才有权限进⾏代码提交
那么接下来，我们就在gitee上新建dev分支来供我们使用
创建成功的远程分⽀是可以通过 Git 拉取到本地来，以实现完成本地开发⼯作。
接下来让我们和另⼀名开发的⼩伙伴都将远程仓库进⾏⼀次拉取操作，并观察结果
对于我们，要操作的是：
注意：之前讲的 git branch 其实只能查看本地分⽀，要查看远程分⽀需要加上 -r 选项。但前提是要 pull ⼀下拉取最新的远端仓库，才能看到最新的内容
拉取后便可以看到远程的 dev 分⽀，接着切换到 dev 分⽀供我们进⾏本地开发。要说明的是，我们切换到的是本地的 dev 分⽀
而对于小伙伴来说，要操作的是：
现在，我们和另一位⼩伙伴就可以在 dev 上完成开发，并 push 到远程
我在 file.txt 文件中新增加了一行 complete the first function!
接下来让我们看看码云上的仓库状态
⾄此，我们已经将代码成功推送⾄码云，接下来假如你的⼩伙伴要和你协同开发，碰巧也要对 file.txt
⽂件作修改，并试图推送，例如：
这时推送失败， 因为你的⼩伙伴的最新提交和你推送的提交有冲突 ，解决办法也很简单，Git已经提⽰我们，先⽤ git pull 把最新的提交从 origin/dev 抓下来，然后，在本地进⾏合并，并解决冲突，再推送，操作如下：
解决冲突，重新推送：
此时此刻，我们去码云那里就能看到我们的新提交了！
最后不要忘记，虽然我们是在分⽀上进⾏多⼈协作开发，但最终的⽬的是要将开发后的代码合并到
master上去，让我们的项⽬运⾏最新的代码。接下来我们就需要做这件事情了：
- 切换⾄ master分⽀, pull ⼀下，保证本地的master是最新内容。合并前这么做是⼀个好习惯
- 切换⾄ dev 分⽀, 合并 master 分⽀，这么做是因为如果有冲突，可以在dev分⽀上进⾏处理，⽽不是在在master上解决冲突。这么做是⼀个好习惯
- 切换⾄ master 分⽀，合并 dev 分⽀
- 将 master 分⽀推送⾄远端
此时，查看远端仓库，master已经是最新代码了
此时，dev 分⽀对于我们来说就没⽤了， 那么 dev 分⽀就可以被删除掉。我们可以直接在远程仓库中将dev分⽀删除掉
总结一下， 在同一分支下进行多人协作的工作模式通常是这样：
- ⾸先，可以试图⽤ git push origin branch-name 推送⾃⼰的修改；
- 如果推送失败，则因为远程分⽀⽐你的本地更新，需要先⽤ git pull 试图合并；
- 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再⽤git push origin branch-name推送就能成功！
- 功能开发完毕，将分⽀ merge 进 master，最后删除分⽀。
五、多人协作场景二
⼀般情况下，如果有多需求需要多⼈同时进⾏开发，是不会在⼀个分⽀上进⾏多⼈开发， ⽽是⼀个需求或⼀个功能点就要创建⼀个 feature 分⽀ 。
现在同时有两个需求需要你和你的⼩伙伴进⾏开发，那么你们俩便可以各⾃创建⼀个分⽀来完成⾃⼰的⼯作。在上个部分我们已经了解了可以从码云上直接创建远程分⽀，其实在本地创建的分⽀也可以通过推送的⽅式发送到远端。在这个部分我们就来⽤⼀下这种⽅式
对于你自己来说，可以用这样的方式：
而对于你的那位小伙伴来说，可以采用这样的方式：
此时，在本地，你看不⻅他新建的⽂档，他看不⻅你新建的⽂档。并且推送各⾃的分⽀时，并没有任
何冲突，你俩互不影响，⽤起来很舒服！！
再来看下远端码云上此时的状态：
对于你的feature-1分支
对于那位小伙伴的feature-2分支
正常情况下，你俩就可以在⾃⼰的分⽀上进⾏专业的开发了！
但天有不测⻛云，你的⼩伙伴突然⽣病了，但需求还没开发完，需要你帮他继续开发，于是他便把feature-2 分⽀名告诉你了。这时你就需要在⾃⼰的机器上切换到 feature-2 分⽀帮忙继续开发，要做的操作如下
查看远程状态，推送成功了：
这时，你的⼩伙伴已经修养的差不多，可以继续进⾏⾃⼰的开发⼯作，那么他⾸先要获取到你帮他开发的内容，然后接着你的代码继续开发。或者你已经帮他开发完了，那他也需要在⾃⼰的电脑上看看你帮他写的代码
Pull ⽆效的原因是⼩伙伴没有指定本地 feature-2 分⽀与远程 origin/feature-2 分⽀的链接，所以我们只要根据提示，设置feature 和 origin/feature-2的链接即可
⽬前，⼩伙伴的本地代码和远端保持严格⼀致。你和你的⼩伙伴可以继续在不同的分⽀下进⾏协同开发了。
各⾃功能开发完毕后， 不要忘记我们需要将代码合并到master中才算真正意义上的开发完毕
由于你的⼩伙伴率先开发完毕，于是开始 merge ：
此时远程仓库的状态：
当你的⼩伙伴将其代码 merge 到 master 后，这是你也开发完成了，也需要进⾏ merge 到 master 操作，操作跟小伙伴大差不差，操作完后此时远程仓库的状态：
此时， feature-1 和 feature-2 分⽀对于我们来说就没⽤了， 那么我们可以直接在远程仓库中将dev分⽀删除掉：
当前我们已经删除了远程的⼏个分⽀，使⽤ git branch -a 命令可以查看所有本地分⽀和远程分⽀，但发现很多在远程仓库已经删除的分⽀在本地依然可以看到
使⽤命令 git remote show origin ，可以查看remote地址，远程分⽀，还有本地分⽀与之相对应关系等信息
此时我们可以看到那些远程仓库已经不存在的分⽀，根据提⽰，使⽤ git remote prune origin 命令
总结
本专栏内容主要来自于《Pro Git》和 网课内容，不算很难，但是很有意义，实际开发中肯定会有更规范也更复杂的Git使用准则，那就等到未来有一天如果我真的成为了程序员，再回来跟大家讲解吧~