git工作流

了解git

Git (/ɡɪt/)[8] is a distributed version control system[9] that tracks changes in any set of computer files, usually used for coordinating work among programmers who are collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different computers)

– git wiki

简单来说git是一个分布式的版本管理工具，它能够追踪每一个文件的变更记录。可能这样说过于抽象了，我们来列举一个更加具体的例子。现在我们有一个文件A，小明在这个里面进行了改动在A文件里面写下了: “我叫小明”，但是有另一个人小张，把我叫小明给改成了 我不叫小明，如果我们使用word或者wps进行的编辑，那么我们就无法知道到底是谁在什么时候改动了这个文件，以及这个文件的历史记录是什么，而git就是能够帮助我们知道某一个文件它的操作记录具体是谁改动的，改动之前和改动之后的区别到底是什么。相信说到这里大家如果是小白的话可能还是对git一头雾水，这里给大家指路到[廖雪峰git教程][https://www.liaoxuefeng.com/wiki/896043488029600/896067008724000]，因为本文主要的侧重点还是git在生产环境当中到底具体如何使用，对于基础内容不再重复造轮子

cook

经过前面的学习大家已经对git有了一些简单的理解，那么从这里开始我们主要聊一下实际工作中的git的工作流到底是什么样子的。

分支

相信大家都知道所有的git文件系统都有一个主干分支 master/main 我们在进行生产环境代码上线肯定是只能够上master分支的，别人进行系统开发也肯定是完全依赖于master/main分支进行开发，因此我们如果说想要开发自己的代码一般来说会有这样的规范

• 功能分支：

  • feature/_xxxx
  • feat_xxxxx

• 线上bug修改

  • hotfix/xxxxx
  • hotfix_xxxxx

这两个分支基本上能涵盖掉90%以上个人开发场景，但是有一定的情况下我们可能还会有dev分支和release分支，这两个一般是小团队进行小步迭代代码的时候比较场景，在实际业务开发当中出现的情况比较少，基本上都是新建feat或者hotfix

ok私房菜：在实际进行业务开发的时候，我们可能还会遇到两类分支分别叫做bus分支和env分支，这两类分支通常都不是个人进行建立的，那么这里来个大家介绍一下bus分支，比如我们部门的微服务有多个业务方进行更改的时候，我们不可避免的可能会导致我们部门的微服务多次迭代并且发布，这会导致我们的服务本身并不稳定，并且还可能会出现A和B部门同时修改了一块代码 互为冲突的情况，那么为了解决这种场景，git当中有一种方式是我们部门约定只能每周四进行代码上线，所有更改我们微服务的部门把分支提交到一个共同的bus分支上面去，这样如果有冲突的话能够提前发现，并且也有效的降低了服务发布的次数，当然这样也会有一定的问题，就是一旦需要回滚会直接把所有人的提交全部回滚掉，因此使用bus分支的情况下，我们还有一个额外约定，那就是不允许代码回滚，env分支则是指 测试环境，灰度环境 线上环境 的分支，那么线上的话肯定就是master分支而其余的环境我们则要求代码要合并到具体的测试环境分支上在进行发布

git的一些基操

• 当前分支进行了一次错误的commit，回滚最近一次commit
  • git reset HEAD^