Git与版本控制
首先是申明我的博文不是干货,只是一个引导。干货可以让我们学习到东西不假,但是同时也降低了我们的思考能力也让人不愿意多想,这对一个开发人员来讲可以说是一个致命伤。
前言
我们公司一直有我们自己的本地服务器,其实主要是拿来做文件归档和冗余存储的。由于我们开发项目使用UE4的资源很多,一个项目也不是由一个人员就可以开发完成了于是所以文件的共享就是一个必不可少的需求。总不可能用一个U盘考着好几十个G的工程文件给项目组其他人员吧。于是我们开始搭建了公司的本地服务器,搞了一系列的事情,什么本地DNS,群集域等等。之后博文可能有机会详解一下怎么搭建。但是最重要是速度,耗财耗力之后最后的网络情况是万兆总线,千兆到桌面基本和网吧的规格一样了,同时我们的终端数量不多所以总体情况是网络速度比网吧还快。这里可以装一个B,从服务器配置到网络部署到群集域搭建终端搭建都是我一人完成的,哈哈哈。之后公司业务拓展了不仅仅是UE4项目还有其他C++项目或者web开发的项目这样一来项目文件不会大的离奇,同时文件基本上全部是代码,如果多人合作的话即便有文件共享系统还是不那么方便所以本地Git系统就正式搭建了起来。
为什么会讲服务器呢,因为这是本地Git系统的基础。诚然Git不适合做几十上百G文件的托管但是仅仅是代码文件的话那就异常的方便好用了。这一篇文章往下会结合我的使用经验和网上一些大神的教程总结一些Git有什么好处,怎么用,当然我也是一个免费用户,同时我们项目也不是特别的大所以实际应用到的git功能还是很有限的,欢迎大家补充。我们使用的是GitLab,搭建在刚刚所得那一台服务器上面的一个虚拟机上,虚拟机分配有4个核心和4g内存,虚拟磁盘有500G,系统是Ubuntu。
项目说明
一般来讲如果一个开放人员做了一个项目假设这个项目没有任何说明文档的话,过了一段时间客户需要修改功能或者之后需要拿这个项目来二次开发,这样一开就会存在很大的问题一共有两点。1、对这个开发人员来讲即便是他自己写的代码在做修改之前他也会花时间来重新熟悉具体到每一个自己封装类的作用和这个类的使用方法与需要规避的情况。2、如果这个开发人员离职了那么等于说他写的代码直接作废,对于任何新开发人员来讲熟悉别人的代码还不如自己重写一个(前提是它写的出来),当然这个是小项目情况下。以上两点还仅仅是我们公司遇上的情况实际使用的话还有很多其他的问题。所以对于项目有文档就十分的重要。但是文档毕竟是一个文件到时候这个文件放在那里合适也就成了一个问题。同时每一次修改对应增减说明也会进入文档所以对于一个项目文档还要保持唯一性,如果仅仅是一对文件的话在多人项目里面这就没法管理了。
所以我们使用项目说明,每一个项目在放到Git之前在项目文件夹里放置一个readme.md的文件这个文件会push到git上面去,这个文件就是我刚刚说的说明文档。一旦你上传完成之后在git项目的项目主页上自动把说明页面显示出来方便阅读的同时还支持很多特定的变现方式。比如输入公式,插入代码块,图片,超链接等。甚至还支持html语法来写说明文档。这样一来可以写的详细并且速度很快。这也就是为什么不写一个word一定要写md文件的原因。
md文件使用的语法和编辑器叫是Markdown,这个东西十分的强大如上所示它可以具有自己的语法同时支持html吊的不行,甚至很一些硕士博士的论文都是使用Markdown写的,编写说明文档时每一个人都有不同的习惯反正原则上是大家可以很好的理解就可以了。这里没有什么需要说明的了最后推荐一个Markdown编辑器给大家 Typora不要太好用稍微熟悉一下语法就可以写出较为实用的文档。
分支管理
对于同一个项目在多人开发的情况之下,不同开发员的项目如果直接覆盖到整个项目回滚便会十分的麻烦,这还仅仅是一种情况,一般来讲只要项目的参与人员超过一个必须使用分支。
分支其实是对同一个项目的不同版本。每一次新建一个项目会自动创建一个主分支master,之后提交新代码会将这个分支里的内容覆盖,并将你的修改给记录下来这样来了如果有多个人向同一个分支提交那么版本迭代势必会出问题。如果另一个开发员修改了原始代码之后新建一个分支并将代码提交到新分支之上就可以解决混乱的问题,分支是十分常用的功能,如果对一个非常大规模的公司来讲或者说某一个社区来讲,分支的存在可以确定原始开发者代码的唯一性,其他第三方修改可以放到其他分支这样一来就可以明确权限,比如是否有权新建分支,是否有权向某一个分支提交代码。这仅仅是基础应用。还有一种情况是指假设软件分为开发版、公测版、发行版的话每一个对于的版本可以是一个分支这样可以确定版本。
分支还有一个好处是提交的机制,每一次git的提交不是简单的把所有代码都上传一次,他仅仅上传你修改了的部分,没建立一个新的分支其实是指主分支的原始文件加本次提交所修改的代码,所有无论是原有代码上面的新提交还是新分支上传只会上传不同的部分这样一来容量其实使用的很小,但是每一次的修改都会归档方便之后对任意一次修改的下载。
代码比较
git最大的优点就是代码比对功能,对于管理者而言知晓一个开发员的工作量只需要看看这个开发员提交了几次代码,同时每一次提交所修改的代码有多少行,可以十分快速的判断这个开发员的工作情况。对于不同的开发员而言,每一次修改文件可以一行一行的在git上面对比有哪一些变化这个就很使用了,一个好的程序如果在之后出现了bug可以通过git快速的定位带修改位置从而判断问题出在什么地方。然后就是代码注释,我一次提交之后如果直接写在注释里面那么久不能比对多提交代码的注释比如说我显示使用互斥锁写了一个线程保护,第二次我提交的时候我把它换成了临界区,我不可能在修改之后还保存原来的代码,更不可能在代码里面注释我为什么要这样换。但是这个我们可以直接写到git的注释系统上面这样一来可以明确每一次提交修改的原因和修改出发点在哪里,其实小项目这个没有太大必要但是一点项目代码达到上万行这个就非常重要了,任何一个开发员都会忘记自己修改的初衷,既不能总结自己的错误,同时还有花时间二次学习。
任务发布
一般的ERP系统可以完成常规办公上面的管理,甚至各个财务也有可能会涉及但是绝对不可能涉及到对一个程序开发进度的监管。git上面的人物系统不仅可以发布任务给到每一个开发员,同时开发员可以返回任务情况提交给管理者,一般来讲足够对任务和人员开发工作进度进行监控了,同时git兼顾了OA功能可以让开发成员间进行通讯较为方便。
总结
由于接触git的时间没有很长目前主要使用的就是上述的功能,同时目前我们公司涉及的项目不算十分庞大所以这些功能足够现阶段的时候之后在大项目来之前可能时候几个较为高级的功能到时候再回来补齐。总之git是一套十分成熟的系统,在目前使用的过程之中没有发现任何问题。而且很大提高了生产力,如果你已经使用过git你就知道我说的是什么意思,要是你还没有使用过那么不用说了我极力推荐。其实本地git和网上的各个git托管平台我推荐使用本地的,代码安全不用细说,最主要的是管理方便,即便账号泄露也有域作为保护虽然我们公司现在的规模不存在这些问题,但是往后就说不准了。
鸭,写的不错,这个博客布局,功能看起都还不错,还是响应式的,另外个人觉得在发表评论的时候,输入内容时或者点击按钮提交时应该去教验一下输入框的内容,没有填写或填写内容错误,应该及时给予错误提示,而不是另外转到一个错误页面
666666,太专业了你