综合技术

『互联网架构』软件架构-git服务搭建与使用(四)

微信扫一扫,分享到朋友圈

『互联网架构』软件架构-git服务搭建与使用(四)
0

很多跟我一样大概有十多年的同事,一直做着企业内部开发,现在还在使用svn,跟大家聊起来git,他们都知道,只是项目里用习惯了svn一直也没改变,我相信这只是时间的问题,在不久的将来必然会使用git,正如我刚入行的时候ssh还是struts1 和hibernate。git更接近互联网,更方便。有一次一个老铁告诉我,他们是上市公司,研发中心负责管理总体的代码都在svn总部那边,svn服务器挂了,导致他想回退版本都没办法,因为本地都没保存之前的代码。如果是git我告诉你这些都不是问题,这就是分布式和集中化的区别。其实可以理解,传统的行业还是svn占据范围比较大,git的使用还是要花费一定的时间,不想为工具上的事情花费时间也是可以理解的。源码:https://github.com/limingios/netFuture 里面的git

GIT的原理和SVN的区别

  • SVN

发展历史

在2000年2月,他们联系《使用CVS开发开源项目》(Open Source Development with CVS)(Coriolis, 1999)的作者Karl Fogel,并征求了他是否愿意在这个新的项目中担任一个角色。巧合的是,当时Karl已经和他的朋友Jim Blandy讨论了一个关于新的 版本控制 系统的设计。在1995年,这两人就成立了Cyclic Software,一个提供CVS的商业支持的软件公司。虽然他们经营商业服务,但是仍然在每天都在工作中使用CVS。使用CVS的挫折感使得Jim认真思考更好的方法来管理数据,不但确定名字为“Subversion”,而且完成了Subversion档案库的基础设计。当 CollabNet 的电话到来时,Karl立即答应了加入项目中,而且Jim让他的雇主RedHat Software同意让他在这个项目中不定期工作。CollabNet雇用了Karl和Ben Collins-Sussman,并在5月开始了详细设计工作。在得到了来自CollabNet的Brian Behlendorf、Jason Robbins和Greg Stein(当时是一名活跃在WebDAV/DeltaV规范过程的自由程序员)很多创意的帮助下,Subversion很快地引起了一个活跃开发者社区的注意。它找出并欢迎很多同样在CVS上受到挫折的社员能来为这个项目做点什么。Subversion 最初的设计Team定下了几个简单的目标。 它必须在功能上可取代 CVS,也就是说, 所有 CVS 可做到的事, 它都要能够作到。 在修正最明显的瑕疵的同时, 还要保留相同的开发模式。 还有, Subversion 应该要和 CVS 很相像, 任何 CVS 使用者只要花费少许的力气, 就可以很快地上手。经过十四个月的编码后, Subversion 于2001年8月31日开始实现 “自行管理”。 也就是说, 开发人员不再使用 CVS 来管理 Subversion 的代码, 而以 Subversion 自己来管理。

SVN(Subversion)是集中式管理的版本控制器,而Git是分布式管理的版本控制器!这是两者之间最核心的区别。SVN只有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。

版本库是集中存放在中央服务器的,而干活的时候,用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了,再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作,如果在局域网内还好,带宽够大,速度够快,可如果在互联网上,遇到网速慢的话,可能提交一个10M的文件就需要5分钟,这还不得把人给憋死啊。

如果多人联合开发,svn服务器挂了,其他人都没办法提交,只能等待svn服务器起起来,无法完成协同一起开发。本地的功能,只能不停的建立分支的方式来进行区别版本号。

  • GIT <英文含义饭桶,傻瓜>

历史发展

很多人都知道,Linus在1991年创建了开源的Linux,从此,Linux系统不断发展,已经成为最大的服务器系统软件了。Linus虽然创建了Linux,但Linux的壮大是靠全世界热心的志愿者参与的,这么多人在世界各地为Linux编写代码,那Linux的代码是如何管理的呢?事实是,在2002年以前,世界各地的志愿者把源代码文件通过diff的方式发给Linus,然后由Linus本人通过手工方式合并代码!你也许会想,为什么Linus不把Linux代码放到版本控制系统里呢?不是有CVS、SVN这些免费的版本控制系统吗?因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比CVS、SVN好用,但那是付费的,和Linux的开源精神不符。不过,到了2002年,Linux系统已经发展了十年了,代码库之大让Linus很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神,授权Linux社区免费使用这个版本控制系统。安定团结的大好局面在2005年就被打破了,原因是Linux社区牛人聚集,不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议(这么干的其实也不只他一个),被BitMover公司发现了(监控工作做得不错!),于是BitMover公司怒了,要收回Linux社区的免费使用权。Linus可以向BitMover公司道个歉,保证以后严格管教弟兄们,嗯,这是不可能的。开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束,他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区(特别是 Linux 的缔造者 Linus Torvalds )不得不吸取教训,只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标:

  • 速度
  • 简单的设计

  • 对非线性开发模式的强力支持(允许上千个并行开发的分支)

  • 完全分布式

  • 有能力高效管理类似 Linux 内核一样的超大规模项目(速度和数据量)

最后实际情况是这样的:Linus花了两周时间自己用C写了一个分布式版本控制系统,这就是Git!一个月之内,Linux系统的源码已经由Git管理了!牛是怎么定义的呢?大家可以感受一下。

  • git的生命周期
  • git 和svn的区别

    SVN的特点是简单,只是需要一个放代码的地方时用是OK的。

    Git的特点版本控制可以不依赖网络做任何事情,对分支和合并有更好的支持(这应该算是开发者最关心的地方)。

  • git 命令合集

搭建和使用gitlab

学过上边的内容其实就够了,但是如果你的定位不是小兵,而是一名技术的经理的话,不仅需要了解和掌握上边的知识基本的命令,还需要搭建整个私服的gitlab环境。

  • 历史gitlab

    最初,该产品命名为GitLab,是完全免费的开源软件,按照MIT许可证分发。

    2013年7月,产品被拆分为:GitLabCE(社区版)和GitLabEE(企业版),当时,GitLabCE和GitLabEE的许可仍然是根据MIT许可分发的免费和开源软件。

    2014年2月,GitLab宣布采用开放核心业务模式。GitLabEE设置在专有许可证下,并且包含CE版本中不存在的功能。

    2015年7月,公司又筹集了150万美元的种子基金。截至2015年的客户包括阿里巴巴集团,IBM和SpaceX。

    2015年9月,GitLab从KhoslaVentures筹集了400万美元的A系列资金。

    2016年7月,GitLabCEO确认了公司的开放核心功能。

    2016年9月,GitLab从AugustCapital和其他公司筹集了2000万美元的B系列资金。

    Gitlab于2017年1月31日发布一系列紧急通告称,位于荷兰的系统管理员因操作失误而删除了包含310GB产品数据的文件夹,在取消删除操作后仅剩下4.5GB。运维人员之后检查发现,网站宣称和配备的多项备份措施均未正常运作或难以利用。Gitlab在YouTube直播了恢复数据的过程。网站最终丢失了最后6小时的数据库数据(包括问题、合并请求、评论、片段等,不含代码库)。

  • gitlab私服的搭建

    本次的安装gitlab,我直接使用docker的方式,去除了很多复杂的配置。

    如果你按照正常的gitlab来进行安装的话,里面需要配置(麻烦死):

    • 内存2G
    • Nginx
    • Redis
    • Rub
    • progsql
      通过源码生成1个虚拟机,准备工作。vagrant已经安装了 对应的docker。
      用docker安装nexus就是为了避免环境变量,用户赋权等复杂的操作。对于vagrant的如何安装不用的系统不一样可以参看
      mac 安装vgarant :https://idig8.com/2018/07/29/docker-zhongji-07/
      window安装vgaranthttps://idig8.com/2018/07/29/docker-zhongji-08/
系统类型 IP地址 节点角色 CPU Memory Hostname
Centos7 192.168.66.100 git 2 2G git

(1). 虚拟机vagrant讲述安装的步骤

(2).机器window/mac开通远程登录root用户下

su -
# 密码
vagrant
#设置 PasswordAuthentication yes
vi /etc/ssh/sshd_config
sudo systemctl restart sshd

(3). 安装gitlab

通过shell脚本的方式运行https://hub.docker.com/r/sonatype/nexus/

mkdir gitlab
cd gitlab
mkdir postgresql
mkdir redis
mkdir gitlab
chown -R 200 data
pwd
ll
vi start.sh

start.sh 我设置的用户名:root 密码123456789qwe

#!/bin/bash
cur_dir=`pwd`
docker stop gitlab-postgresql
docker rm gitlab-postgresql
docker stop gitlab-redis
docker rm gitlab-redis
docker stop gitlab
docker rm gitlab
docker run --name gitlab-postgresql -d 
    --env 'DB_NAME=gitlabhq_production' 
    --env 'DB_USER=gitlab' --env 'DB_PASS=password' 
    --env 'DB_EXTENSION=pg_trgm' 
    --volume ${cur_dir}/postgresql:/var/lib/postgresql 
    sameersbn/postgresql:10
docker run --name gitlab-redis -d 
    --volume ${cur_dir}/redis:/var/lib/redis 
    sameersbn/redis:4.0.9-1
docker run --name gitlab -d 
    --link gitlab-postgresql:postgresql --link gitlab-redis:redisio 
    --publish 10022:22 --publish 10080:80 
    --env 'GITLAB_PORT=10080' --env 'GITLAB_SSH_PORT=10022' 
    --env 'GITLAB_ROOT_PASSWORD=123456789qwe' 
    --env 'GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alpha-numeric-string' 
    --env 'GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alpha-numeric-string' 
    --env 'GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alpha-numeric-string' 
    --volume ${cur_dir}/gitlab:/home/git/data 
    sameersbn/gitlab

运行shell脚本

sh start.sh

刚开始是这样的 http://192.168.66.100:10080/ ,gitlab初始化后就正常了。

管理员:root 密码:123456789qwe

git的使用技巧

  1. .gitignore 增加忽略文件,添加和提交的时候自动忽略
  2. 开发的时候如果开发人员5个人(A,B,C,D,E),2018年12月12日要上线版本,A是项目组长,通过master建立分支release20181212,5个人的各自的分支分别是task_A_relase20181212,task_B_relase20181212,task_C_relase20181212,task_D_relase20181212,task_E_relase20181212。各自开发完毕,都通过merge的方式merge到release20181212,A在release20181212进行测试。如果B(紧急出现问题),B切换release20181212进行修复。 所有人都修复完毕后,release201212在由A,merge到master分支。
  3. 冲突的解决:临键分支, 然后会退到上一次commit, 再pull 最新代码, 然后再与当前分支 merge, 然后再提交。

PS:可能你感觉不出来git的牛掰,如果是从比较小的公司来说,还不如用svn,尤其是大家都不太熟悉git的时候,现在是公司比较大的时候,项目的分支开发很快,例如我目前开发的项目每周一个分支,周4都要提交新的版本的时候,又有很多老铁在并行开发的时候,svn绝对是管理不过来的,但是你用git的话,gitlab里面有很多功能,分支的管理,提交的树,很强大的真正开发的时候很乱很乱,全是线条,用svn估计是想都不敢想的,不仅仅本地提交的问题,不是git好不好用的问题,而是有没有挑的问题,我们挑技术还是技术挑我们。如果公司用git,你非要用svn,你走人对吧。

百度未收录

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!

>>原文链接地址:上一篇:

已是最新文章

阅读原文...


IT人故事会

『互联网架构』软件架构-环境搭建maven(三)

上一篇

Melonport dissolves in favor of its protocol, setting a new bar for the blockchain world

下一篇

您也可能喜欢

评论已经被关闭。

插入图片
『互联网架构』软件架构-git服务搭建与使用(四)

长按储存图像,分享给朋友