文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Git 实践,什么才是优秀的工作流?

2024-12-02 07:02

关注

今天我们不聊基本用法,聊一聊 Git 到底应该怎么用?我们知道相比于 Svn,Git 最牛的地方在于它的分支,分支很灵活,但是如果缺乏一个使用套路,又会用的乱糟糟的,特别是在团队协作中,该怎么玩 Git 分支?

咱们也不发明什么轮子,也不设计什么全新流程,本文主要是和大家介绍三种常见的工作流:Git Flow、GitHub Flow 以及 GitLab Flow。介绍完成后,在谈谈松哥的一些使用体验。

1. Git Flow先来看 Git Flow。

Git Flow 是最早诞生也是最早被广泛使用的工作流程。

在 Git Flow 中,有两个长期存在且不会被删除的分支:master 和 develop。

在这两个分支中,master 主要用于对外发布稳定的新版本,该分支时常保持着软件可以正常运行的状态,由于要维护这一状态,所以不允许开发者直接对 master 分支的代码进行修改和提交,其他分支的开发工作进展到可以发布的程度后,将会与 master 分支进行合并,并且这一合并只在发版时进行,发布时将会附加版本编号的 Git 标签。

develop 则用来存放我们最新开发的代码,这个分支是我们开发过程中代码中心分支,这个分支也不允许开发者直接进行修改和提交。程序员要以 develop 分支为起点新建 feature 分支,在 feature 分支中进行新功能的开发或者代码的修正,也就是说 develop 分支维系着开发过程中的最新代码,以便程序员创建 feature 分支进行自己的工作。

注意 develop 合并的时候,不要使用 fast-farward merge,建议加上 --no-ff 参数,这样在 master 上就会有合并记录,关于这两个的区别,大家可以参数松哥之前的 Git 教程,这里不再赘述。

除了这两个永久分支,还有三个临时分支:feature branches、hotfixes 以及 release branches。我们分别来看:

feature branches

这个是特性分支,也叫功能分支,当你需要开发一个新的功能的时候,可以新建一个 feature-xxx 的分支,在里边开发新功能,这也是我们日常工作的大本营,开发完成后,将之并入 develop 分支中,如下图:

hotfixes branches

这个分支看名字就是用来修复 BUG 的,当我们的项目上线后,发现有 BUG 需要修复,那么就从 Master 上拉一个名为 fixbug-xxx 的分支,然后进行 BUG 修复,修复完成后,再将代码合并到 Master 和 Develop 两个分支中,然后删除 hotfix 分支,如下图:

release branches

这个是发版的时候拉的分支,当我们所有的功能做完之后,准备要将代码合并到 master 的时候,从 develop 上拉一个 release-xxx 分支出来,这个分支一般处理发版前的一些提交以及客户体验之后小 BUG 的修复(BUG 修复后也可以将之合并进 develop),不要在这个里边去开发功能,在预发布结束后,将该分支合并进 develop 以及 master,然后删除 release,如下图:

大概就是这个意思。

松哥工作中用的其实就是类似于 Git Flow 的工作流,为什么说是类似呢?我们项目中主要是保证了 master、develop 以及 release 三个分支,在此基础之上,其他随意。

2. GitHub Flow

GitHub Flow 相比于 Git Flow 就要容易很多了,GitHub Flow 也是 GitHub 上使用的工作流程,如果你想参与 GitHub 上的某一个开源项目,那么不妨看看 GitHub Flow。

官方给的 GitHub Flow 流程如下:

它的流程是这样的:

GitHub 工作流虽然用着很简单,但是他的问题也很明显,就是没有对常见的工作场景中的问题提出解决办法。

3. GitLab Flow

GitLab Flow 结合了 Git Flow 与 GitHub Flow 的优点,它不像 Git Flow 有那么多容易把新手绕晕的分支,同时它又可以适应不同的开发环境。

GitLab Flow 的最大原则叫做 upstream first,中文译作“上游优先”:即只存在一个主分支 master,它是所有其他分支的 upstream,只有上游分支采纳的代码变化,才能应用到其他分支。

对于“持续发布”的项目,我们可以在 master 分支以外,再建立不同的环境分支。例如开发的分支是 master,预发布的分支是 pre-production,生产环境的分支是 production。

在这里开发分支是预发分支的 upstream,预发分支又是生产分支的 upstream。代码的变化,必须由上游向下游发展。比如,生产环境出现了 bug,这时就要新建一个功能分支,先把它合并到 master,确认没有问题,再 cherry-pick 到 pre-production,这一步也没有问题,才进入 production,如下图:

只有紧急情况,才允许跳过上游,直接合并到下游分支。

有稳定的版本需要发布时,我们就从 master 上拉一个新的分支出来,作为发版时候的分支,这些分支上不要开发新功能,只有修补 BUG 的时候

对于”版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable、2-4-stable等等。

以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号即可。

4. 小结

好啦这就是常见的三个 Git 玩转流程,其实我们自己开发不必这么死板,结合自己的项目来就行了,松哥的项目,master、develop 以及 release 三个分支是固定的,这三个分支的作用跟前面介绍的 Git Flow 也是一致的,在此基础之上,其他的基本上没有太多限制,比较自由。

参考资料:

https://www.cnblogs.com/sloong/p/5868292.html

https://medium.com/@lf2lf2111/%E4%B8%89%E7%A8%AE%E7%89%88%E6%8E%A7%E6%B5%81%E7%A8%8B-29c82f5d4469

https://cloud.tencent.com/developer/article/1646937

本文转载自微信公众号「江南一点雨」,可以通过以下二维码关注。转载本文请联系江南一点雨公众号。

来源:江南一点雨内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯