【C++拓展(三)】Git的企业级使用指南(下)

💓博主CSDN主页:杭电码农-NEO💓

⏩专栏分类:C++从入门到精通⏪

🚚代码仓库:NEO的学习日记🚚

🌹关注我🫵带你学习C++
  🔝🔝

C++拓展

1. 前言

就在上一篇文章Git企业级使用(上)了解到了git的分支管理,显而易见,分支管理往往用于公司中的团队合作以及突发情况的紧急处理

本章重点:

本篇文章会着重讲解分支管理中, 如何合并分支, 在分支管理中的一些常见问题. 最后会讲解git的分布式版本控制系统,以及git的标签使用.

2. 分支合并操作

上篇文章已经了解过如何创建,切换,查看分支了, 这里就直接继续了

合并分支

使用指令: **

git merge dev

** 将dev分支的内容合并到master主分支

删除分支
当我们将dev分支合并到master后,dev分支可能就没什么用了,此时就需要删除它

使用指令: **

git branch -d dev

**

基本步骤可用下图表示:

3. 分支冲突

现在有这样一种情况, 主分支文件中只有语句: “aaa”, 现在创建一个dev分支, 在dev分支中, 在aaa后面添加了bbb语句,而我们的master分支在合并前是看不见这个bbb的,此时master分支也在aaa后面添加了ccc语句,这时再去合并就会出现问题,步骤如下图:

这种情况应该怎么办呢? 事实上, 当我们进行合并后,git回给我们进行提示, 当我们merge后再去查看文件内容, 会发现文件中既有bbb也有ccc,此时你需要删除bbb或ccc,保留你想要的最终结果, 最后再进行一次add和commit提交即可.综上所述,遇见合并冲突需要我们手动解决

4. Fast for word模式

以上说的分支合并操作, 其实都是fast forword模式, 那么什么是fast forword模式呢?

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev 分⽀，但依旧能看到 master 其实是由其他分⽀合并得到的

这里干讲是有点抽象的,建议大家一边看,一边实践

Git支持强制禁用fast forword模式

使用指令: **

git merge -no-ff -m "合并信息" dev

**

使用-no-ff选择可以禁止此模式, 它会在 merge 时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出分⽀信息

5. 分支管理策略

在实际的公司项目开发中,master主分支应该是要很稳定的,是用户正在访问的服务所在的分支,它仅仅用于发布新版本,不能在master分支上进行工作.我们干活大部分都是在自己新建的分支上干活,甚至是在dev分支上新建分支干活,每个人完成的某个模块时,就向dev分支进行合并即可,所以我们整个项目的分支可能是下面这种情况

master分支遇见BUG的解决方案

想象一下, 一个项目正在master分支上跑着, 程序员正在dev分支上添加新的功能, 但是此时master分支出现了严重的bug,请问这个时候你怎么应对? 由于dev分支正在开发新功能,导致master分支的代码和dev分支的代码是不一样的, 如果直接在dev分支上修改bug, 那么我们就需要退回master分支的版本, 修复好bug后再重新写新功能, 难受,实在是太难受了!

**

有没有什么方法可以将dev分支的代码暂存起来?等修复好master分支的bug后再将暂存的代码拿出来呢?

**

还真有! Git提供了git stash指令,可以将当前工作区的信息进行储存, 被储存的内容会在将来某个时刻被放出来

**

gti stash

** 将当前工作区文件信息进行储存

**

git stash list

** 查看存储区内容

**

git stash pop

** 将存储区代码恢复

6. Git的分布式版本控制

以上所有内容都是在本地服务器上进行的, 但是在合作完成一个项目时, 不可能多个人同时使用一台机器写代码, 于是像GitHub或gitee都提供了一个叫中央服务器仓库的东西, 这个仓库是项目在团队协作时,需要联网交互的.

所以我们在刚学习git时, 在add和commit之后, 我们会进行push操作, 这个push操作本质上就是将本地服务器的一些内容修改, 推送到中央服务器, 以便其他团队成员能及时看见你的修改.并且我们在push前, 需要先使用git pull命令, 因为你不能保证你的团队中是否有人push过内容到中央服务器, 一旦有人push, 中央服务器的内容就和你本地的内容有所冲突, 所以养成好习惯, push前先使用pull

7. Git的标签管理

试想一下这样的场景, 公司在团队协作开发项目时, commit提交了上万次, 但是此时你想要回滚到某个特定的commit版本, 你怎么应对? 难道一个一个的去找吗? 难受, 实在是难受

理解标签

标签tag可以理解为对某次commit的一个标识, 相当于为此次commit取别名, 例如在项目发布某个版本时, 可以给最近一次commit打上v1.0的标签,这样下次需要回滚到1.0版本的提交时, 就不需要查看log了, 只需要查看tag标签即可定位

**

以下是关于标签操作的常用指令

**

创建标签

使用指令: **

git tag [name],如: git tag v1.0

**

此次标签默认打在最新一次提交的commit id上

查看所有标签

使用指令: **

git tag

**

给标签标注信息

使用指令: **

git tag -a [name] -m "信息"

**

查看标签信息

使用指令: **

git show [标签名]

**

删除标签

使用指令: **

git tag -d [标签名]

**

推送标签至远端服务器

使用指令: **

git push origin v1.0

**

推送所有标签: **

git push origin --tags

**

不论是Git的分支管理,还是标签管理, 都需要大家去实操, 否则不能理解到这其中的精髓所在

8. 总结

本次Git的企业级使用就分享到这儿, Git其实还有很多知识值得我们探索, 所以,加油吧少年!