今天介绍一下工作中会用到的 Git 分支模型。另外文末送签名书,程序员必备的面试书.
其实日常工作中,会经常使用到Git,如果不会使用Git,很大可能会被认为是菜鸟,没有团队协作开发经验,所以熟练使用Git是非常有必要的!
我曾经有个同事,新入职 上午装好了开发环境,团队讲了一下项目情况然后Leader安排他自己去看代码,管理员给他分配了一个Git账号,让他自己去从服务器获取代码!
过了一天,第二天早上团队开晨会的时候,团队成员在讲述自己看项目时遇到的问题,轮到那们新同事报告的时候,他居然说没有办法获取代码,说自己不会用Git,以前都是自己一个人开发,不需要用Git,说完这话就被团队成员狠狠的BS了,然后被安排去学习使用Git,从那以后我就对Git逐渐重视!
今天我整理了使用Git的一些技巧,希望可以帮助大家!
闲言
在学校不管是自己写课程设计还是给老师做项目,有 2 到 3 个人一起协作开发时就会使用 Git ,但是只是简单用了它所提供的代码协作功能,在学校的项目,比如课程设计,开发完老师检查完就没有维护了,给老师做项目也是,基于项目的特征:没有持久性、一次性开发,所以没有应到 Git 分支模型。在企业中,一个应用往往是有比较长的生命线,由很多个迭代项目开发构成,这时要解决几十甚至几百人的代码协作问题,就需要一套完整的规范的代码开发流程。
我还记得当初大四的时候,去了一家企业实习,当时小团队只有 3 个开发人员,git 使用没有规范,只有一个 master 主分支,项目也没有管理规范,来一个需求点就做。当时经常出现代码覆盖,各种代码合并,线上代码也不知道是哪个节点的代码。。。到我走的时候,也没使用上这个分支模型。毕业后入职了某银行,不说分支模型了,Git 都没用上,直到今年跳槽到互联网公司才了解到这个分支模型。因此,你工作不一定会真正用到这个分支模型,如果是在互联网企业,很有可能会使用上。
有些小伙伴看到这张偌大的图觉得有些晕,很认真地说,这是一张大家都在用的图,特别是互联网企业。如果是还没有工作的小伙伴,可能有些陌生,没事,我们来看一下这些内容。
分支介绍
master :这个分支的代码是发布到生产的代码
develop :这个分支的代码是预发布到生产的代码
release :这个分支的代码是新版本发布到生产的代码
feature :这个分支的代码是新需求开发的代码
hotfix :这个分支的代码是紧急修复生产 bug 的代码
场景设想
下面列举一些可能你在工作中会经常面对的场景
好了,一大坨的文字描述了基于分支模型开发的过程。不同公司在应用过程中可能会有些微小的不同,但是整体流程都是差不多的。比如有的公司可能会把 release 合并到 master 后,用 master 代码发布到生产,发版当时有异常,再从 master 分支上拉 hotfix 分支进行修复。上面描述的步骤就不一样了,发版时出现异常,直接在 release 上修复。这些小的差别就不用计较太多啦。
希望本文能够让你认识到有这么一个标准的 Git 分支模型,在不管工作上还是学习上,在需要分支管理的时候,回忆起有这么一个图,根据你的场景再应用进去,肯定会少走很多弯路。