Git实战教程[六]——基于GitLab搭建Git服务器

安装步骤(bitnami方式)

  1. 下载GitLab

    $ wget https://downloads.bitnami.com/files/stacks/gitlab/8.14.3-0/bitnami-gitlab-8.14.3-0-linux-x64-installer.run
  2. 运行安装包

    $ chmod  777   bitnami-gitlab-8.14.3-0-linux-x64-installer.run
    $ ./bitnami-gitlab-8.14.3-0-linux-x64-installer.run

    安装过程中需要输入邮箱、账号、密码、绑定域名等信息

  3. 赋权

    $ chown -R root:gitlab_ci /home/gitlab_ci  
  4. 安装成功后通过安装过程中填写的域名绑定即可访问

使用简介

  • 通过安装时输入的域名访问GitLab
    QQ截图20170118151004.png

  • 创建项目
    QQ截图20170118151841.png

  • 项目创建后可在项目详情查看项目的文件、分支、标签等信息
    QQ截图20170118152145.png

  • 进入项目的分支详情可以创建新分支
    QQ截图20170118155750_副本.png

  • 在项目详情的设置中选择Protected Branches可进行项目分支的权限设置
    QQ截图20170118155735_副本.png
    QQ截图20170118154648.png


[目录]
[上一篇] Git实战教程[五]——发布操作



Git实战教程[附录一]——分支模型设计

前言

本教程中的分支模型是从Git经典模型中按实际开发需要修改而得。

Git模型

gitdashflow.png

当前模型

current

比较

当前模型比Git模型仅仅少了release分支,因为我们的项目基本都是覆盖发布,很少出现多版本共同存在的情况,为减少发布的操作所以取消了release分支。相应的若项目需要实现多版本共存则可以通过增加release分支实现。

再谈Git分支

Git可以通过分支实现非常灵活的版本管控,很多情况下都可以通过增加分支解决版本问题。
最开始学习Git的时候为了尽量保持分支的简单易懂(分支越多,操作越多),远程仓库只有master和dev分支,但是在热修复的情况下developer角色没有权限把fix bug分支的内容直接提交到master分支,在最后不得不加上hotfix分支作为中间分支解决热修复的问题(《Git实战教程[四]——Bug热修复》)。经过这一演进过程,一方面感受到Git分支概念的灵活强大,另一方面不得不佩服Git模型的实用性(目前很多组织认为Git模型过于繁杂,纷纷对其改造,如GitHub的workflow则非常简化,但是对于传统型项目始终是Git模型更能胜任)。


[目录]



Git实战教程[二]——环境搭建

一、安装TortoiseGit

TortoiseGit下载地址
安装过程略。

二、安装Git

Git For Windows
安装过程略

三、TortoiseGit配置Git

TortoiseGit只是相当于一个图形界面,底层还是要调用Git的命令行,所以TortoiseGit要配置Git的路径。

  • 右键TortoiseGit -> Settings
    aa_副本.png

  • 在General标签中配置Git.exe的目录
    QQ截图20170110173116_副本.png


[目录]
[上一篇] Git实战教程[一]——Git基础
[下一篇] Git实战教程[三]——本地开发



Git实战教程[五]——发布操作

操作流程图如下

QQ截图20170116145023_副本.png

1.把dev分支的内容push到master(操作前需确保dev分支上内容已是最新)

2.switch 切换到master分支

3.执行merge操作,合并来自dev分支push的内容

QQ截图20170110151355.png

4.右键项目TortoiseGit -> Create Tag,新增一个名为v1.0.0的标签

QQ截图20170116134258_副本.png

5.提交Tag到远程仓库

步骤四中创建的标签,只在本地生效,需提交到远程仓库才能创建永久标签。TortoiseGit -> Push, 在弹出窗口注意选择Include Tags,然后点OK。
QQ截图20170116134554_副本.png

6.更新hotfix分支保持与master一致

注:这一步留在待发现bug时再更新hotfix分支也可以,看团队选择。

  • 从master分支push到hotfix分支
  • hotfix合并从 master push 过来的内容

做完以上步骤,就可以打包发布了~


[目录]
[上一篇] Git实战教程[四]——Bug热修复
[下一篇] Git实战教程[六]——基于GitLab搭建Git服务器



Git实战教程[一]——Git概述

前言

本教程针对实战操作,一切内容从实操角度出发,对底层命令的使用和过深的概念不作阐述。本教程主要基于TortoiseGit等图形界面工具的使用进行讲解,但是操作是互通的,理解了概念后换成任一工具都可以。建议在了解应用层面后也了解一下Git的底层操作,可参考Git经典教程《Git教程——廖雪峰的官方网站》

什么是Git

一个版本控制系统,特点是免费、开源、高效、分布式。

Git与SVN

  • Git相对SVN的优点
    Git的优势在于能够非常灵活的基于指针创建分支,提高项目版本的灵活性。SVN是基于文件复制创建分支,导致分支功能效率低下、非常鸡肋,所以SVN的开发操作一般都在主线上,版本管理相对限制。
  • SVN相对Git的优点
    SVN天生就是集中式版本管理系统,对权限控制的支持达到极致,可以根据项目组要求进行文件级别的各种权限限制;Git倡导的是开源精神,所以Git对权限管理的支持不高,虽然可以通过例如GitLab等服务配置权限,但也只能配置控制到分支级别。

Git的重要概念

  • Git的分布式与集中式
    Git是基于分布式的版本管理系统,主要的思想是去中心化,意思是所有的机子都可以成为远程仓库,理论上是每个人都可以从最近的机子获取代码。但是Git的实际应用中主要还是基于集中式进行,通常会有一台服务器作为远程仓库,项目组的开发成员会从这个远程仓库上获取代码,而最后也是提交代码到这个远程仓库。

  • Git的本地仓库与远程仓库
    Git中会有本地仓库和远程仓库的概念,在这里我们简单的把本地仓库当作开发者的本地Git,而远程仓库就是上边提到的集中式的中心仓库,本地仓库要向远程仓库提交代码时是通过push操作实现的。
    补充:为什么只能是本地仓库向远程仓库(此处特指中心仓库)push,而不能反过来?Git是分布式的,理论上每个仓库都是平等一致的,中心仓库其实也是一个普通仓库。假设仓库A向另一个仓库B push文件时,建立的连接是基于ssh的,那么前提就要求仓库B必须保存了仓库A的SSH key,也就是仓库A要先创建SSH key,然后把SSH Key告诉了仓库B,在仓库B保存了仓库A的SSH key后A仓库才有权限把文件push到仓库B,基于这个原理我们就能够轻易的实现集中式的Git。

  • Git的分支
    Git的最强大之处就是以分支为主导的开发模式,本教程中是比较精简的模型,远程仓库主要有master和dev两条分支,为了实现热修复还有一条hotfix分支。开发的时候开发者需要习惯为每个开发任务分别创建分支,在新的分支上进行功能开发,开发完成后再合并到远程分支。

Master和Developer角色

本例中设定的角色只有Master和Developer角色。一般开发者都是Developer角色,拥有对dev、hotfix分支的所有权限,但不能操作master分支;而能够拥有版本发布权限的开发者则是Master角色,除了拥有dev分支的所有权限外,还拥有master分支的所有权限。

Git的常用功能

  • clone 从远程仓库下载项目到本地
  • pull 更新本地文件
  • create branch 创建分支
  • switch/checkout 切换分支
  • commit 修改内容提交到分支
  • push 把分支内容提交到远程仓库
  • merge 合并从其他分支push过来的内容
  • stash save 保存当前工作快照
  • stash pop 恢复工作快照

分支模型

QQ截图20170113131952_副本.png

分支模型的设计可参考《Git实战教程[附录一]——分支模型设计》


[目录]
[下一篇] Git实战教程[二]——环境搭建



Git实战教程[目录]
Git实战教程[四]——BUG热修复

此处的“BUG热修复”指的是不影响dev分支的情况下修复master主线上某一版本的BUG。

假设场景

  1. 项目在半个月前发布了1.0.0版本,并在master主线上打了一个名为1.0.0的TAG;
  2. 客户今天突然发现了生产环境上一个严重的BUG,接到投诉的项目经理要求对问题紧急修复,并尽快发布;
  3. 项目的代码相对1.0.0版本已经是面目全非的状态;
  4. 你已经阅读过《Git实战教程[二]——本地开发》

操作流程图如下

QQ截图20170116233331_副本.png

1. Stash保存工作镜像

  • TortoiseGit -> Stash Save
    QQ截图20170116214333.png
  • 在弹出的窗口填写镜像信息,方便之后还原
    QQ截图20170116214644.png

    2. 基于tag v1.0.0创建fix bug分支

    右键项目 TortoiseGit -> Create Branch,在弹出窗口中填写分支名称,并选择Base On Tag v1.0.0。
    QQ截图20170116133625.png

3. 修复Bug

  • 在fix bug分支上修复bug
  • 修复后提交修改到本地仓库
  • push代码到hotfix分支

    4. 更新hotfix分支

  • hotfix合并fix bug分支push的内容(Merge时注意选择from Branch remotes/origin/hotfix),待测试人员测试

    5. 更新dev分支

    注:hotfix测试通过后master分支的发布将由Master角色的人员负责,而developer虽然不用处理master分支,但是仍然要把fix bug分支的内容提交到dev分支,否则下次发布版本时bug依然存在。
  • 从dev分支pull,更新hotfix代码
    QQ截图20170116230220.png
  • 在假定场景中提到v1.0.0与dev相差很大,所以pull后出现冲突是非常正常的。
    QQ截图20170116230650.png
  • 对于冲突的地方应按提示进行修改,解决冲突。
    QQ截图20170116230704.png
  • 解决完冲突后fix bug分支push代码到dev分支,然后再merger dev分支即可。

    6. Stash Pop还原工作镜像

  • TortoiseGit -> Stash Pop 还原成上一次Stash保存的工作镜像。
    (若有多个stash镜像可通过TortoiseGit -> Stash List查看镜像列表,然后指定一个镜像进行还原)

[目录]
[上一篇] Git实战教程[三]——本地开发
[下一篇] Git实战教程[五]——发布操作



Git实战教程[三]——本地开发

操作流程图如下

QQ截图20170116131233_副本.png

1. Clone项目

  • 切换到项目本地待存放目录,右键菜单选择Git Clone
    1.png

  • 在弹出窗口填写项目git地址,点击OK
    2.png

2. 切换到dev分支

  • 选中项目右键菜单选择Switch/Checkout项
    3.png

  • 选择dev分支(若本地没切换过dev分支则只能选择remotes/origin/dev分支)
    4.png

  • 右键项目,选择pull,更新项目到当前分支最新状态
    5.png

3. 本地开发新功能

  • 创建新分支(建议每当进行一个新的开发任务时都创建一个分支),右键项目选择Create Branch
    6.png

  • 在弹出窗口中填写分支名称,注意Base On是dev分支,勾选Switch to new branch,点击OK,然后就可以在新创建的分支下进行功能开发。
    7.png

4. 提交代码

  • 右键项目,选择Commit,把本地修改提交到新功能开发分支
    8.png

  • 填写更改信息,点击OK
    9.png

  • 右键项目TortoiseGit->Push,在弹出窗口选择从新功能开发分支推送到dev分支,点击OK
    10.png

5.更新dev分支代码

  • TortoiseGit->Merge,在弹出窗口选择remotes/orign/dev分支,点击OK。
    11.png

完。


[目录]
[上一篇] Git实战教程[二]——环境搭建
[下一篇] Git实战教程[四]——Bug热修复



微信企业号第三方应用开发[二]——创建应用
在应用套件里添加应用 当你创建完应用套件后,需要在套件配置应用,应用的信息填写如下。 基本信息:
信息项要求及说明
应用Logo 应用的Logo,小于2M,640*640,在授权页会被用于展示。
应用名称 应用的名称,2-16个字。
功能介绍 描述该应用的功能与特色,4-120个字内
应用类型 应用分为消息型应用和主页型应用,消息型应用进入后是类似公众号的对话窗口;主页型应用进入后直接是自定义的主页URL
主页URL 主页型应用才拥有该属性,是进入主页型应用后直接跳转到的URL
通讯录权限等级 标识应用可以对授权企业的通讯录进行哪些操作,分为三个等级,标识信息只读、全部信息只读和全部信息读写
通讯录权限范围 标识应用可以对授权企业的哪部分通讯录进行操作,分为“与可见范围一致”、“需要额外通讯录范围”。如果选择了“需要额外通讯录范围”,应用可以对企业管理员设置的额外通讯录进行操作

开发信息:

应用参数内容说明
callbackurl 用于接收托管企业号应用的用户消息,URL支持使用$CORPID$模板参数表示corpid,推送事件时会替换为企业的corpid。(填写URL时需要正确响应微信验证URL的请求,具体说明请阅读“回调模式”注意验证时$CORPID$模板参数会替换为当前服务商的corpid,校验时也应该使用corpid初始化解密库)
可信域名 设置可信域名后支持应用的OAuth2授权、JSSDK调用等
业务设置URL 该URL为服务商侧的管理后台链接,授权企业的管理员可从企业号后台的应用详情页免登录直接跳转该链接
关联到会话 开启关联到会话后,授权企业成员可从企业会话聊天界面的“+”访问该前应用,设置的URL为进入应用时跳转的URL

选择创建应用->选择应用类型->选择应用基本信息->
设置应用开发信息页面
729439-20160810125659043-334189504.png
备注:

  • 响应CallbackUrl的代码与【微信企业号第三方应用开发[一]——创建套件】中的一致。
  • “业务设置URL”,由于目前还没开发到自动登录后台的功能,所以直接填了应用的登录页面地址。

[目录]
[上一篇] 微信企业号第三方应用开发[一]——创建套件



2016总结

迟到的2016总结

大家都在31号或是1号写下了2016总结,我的拖延症一犯,就到这个时候了。


我是15年拿的毕业证,也就是在15年7月份转正,按这样算那我的工龄是1年半。而我其实在14年12月就已经在现在就职的公司开始实习,如果从那时开始算,那我已经工作了整整2年,可怕。
当年刚毕业的时候很青涩,不懂真实的工作环境是怎样,在想会不会像电视上的各种勾心斗角,会不会有很多职场上的条框规矩,会不会工作上完成不了任务。到公司后发现其实一切都很自然,大家的氛围很和谐,并不用很刻意的就跟同事们熟起来,不用很刻意的就上手了安排的工作。
2015年我的进步非常快,从前在学校虽然在班里编程基础算是相对比较扎实,但是都是跟着课程走,用着基础的技术做着跟当今市场严重脱轨的各种课程设计,现在回头看就是那种玩泥巴的感觉。出来工作后初次接触前端,接触真正投入生产的框架,做着真正有用户、需求不断(kēng diē dě)变更的项目。2015的整整一年我是真的感受到我像块海绵一样,无论来多少知识都能吸收,这种感觉非常棒,而且我技术涉及了后台、前端、运维等多个方面,顺势的也斩获了2015年部门最佳员工(虽然当时部门只有十几人……)。
因为2015年没写总结,所以就在这顺便写写了,扯完了~下面开始写2016。


2016

2016我并不满意,相对2015,我的进步很不明显。列一列2016我的技术点:

  • 微信企业号
  • 微信企业号第三方应用
  • 推动项目组从myeclipse6.5转向新版eclipse(然而6.5感觉还是最舒服的版本)
  • 推动项目组使用maven
  • 个人从eclipse转向idea
  • 从搭建个人博客开始入门linux

2016我一直处于迷茫状态

  • 迷茫一 眼界
    IDE的更改、maven的使用这些写出来我觉得应该会有很多人笑话,但是我们公司是小公司,我们部门是新成立的部门,技术相对不够前沿,这些“新”东西总得要有人去推动,去改掉原有的习惯,很多时候也是我在强迫自己去接受新事物。而linux的使用这种基础我竟然到工作两年了才开始接触,不禁自己觉得羞愧(我们部门的服务器用着windows server系统)。这也让我很怀疑留在小公司是对或错,因为眼界实在是窄,所有东西都要靠自己去摸索,凭一己之力真的很难了解到所有的技术潮流。而且所有的技术都是要靠自己学习靠自己实践,这非常消耗时间,虽然通过自己的研究可以加深认识,但这是否值得就保留意见了。像转向idea的使用上我花了差不多一周时间才成功把项目跑起来,如果有前辈指导,这可能就一天的事情,这种事难道真的值得一周时间?
  • 迷茫二 个人判断
    微信企业号、微信企业号第三方应用其实最开始接触的时候我是抵触的,我认为在企业号里只能使用web页,流畅度远不如app,而事实上现在部门里几乎所有应用都是运行在企业号上,android、ios的同事已经几乎没太多事情做,纷纷转去了web前端或者后台方向,市场上也是android、ios开发者已经开始过剩。在这个问题上我开始怀疑自己的判断力,其实早在微信刚出现的时候,我是连微信都不看好,而现在这个微信称霸的局面是我当初完全不会想到的。我对很多新鲜事物第一反应可能都是表现得不看好,这种态度可能会让我错失很多机会,现在的我会比较刻意的暗示自己不要拒绝新事物,要学会拥抱世界。不过要提高自己的判断力确实是件难事,还没找到什么好方法,只能说努力提高自己的知识面。
  • 定位
    在技术上我一直都是标榜自己是不限定自己技术领域的开发者,这一点倒是没什么犹疑的,只是问题出在到底是往技术深造还是带领团队上出现了分歧。现在我每天有大量的时间是在处理着非技术问题的,例如制定开发计划、跟进项目进度、指导经验尚浅的同事、思考开发规范等,每当在我自己安排有开发任务的时候还要分暇处理着这些非开发的任务时,我就会很焦虑烦躁。最开始指定开发计划时有很多的功能我觉得在技术上是挺有意思的,都很希望把开发计划都安排到自己身上,然而经过几次的尝试后发现我根本没有足够的时间去应对这些任务,而最后不得不通过加班或者降低代码的完美度以确保开发进度。现在我在制定开发计划的时候会更加小心对自己工作的安排,如果任务符合非核心、繁琐而又技术含量不高、其他人的能力能够足以胜任等等任一情况我都会考虑把这些任务分发出去。现在我的变化是有点像管理者转型的,因为很多开发人员转管理人员都是慢慢的把编程工作的比例逐渐降低,而我对这一点会忧虑,因为我觉得在技术上我还没有足够的沉淀,过早的转型一来是我不舍得开发,二来是担心技术上的不足会影响我对错与对的判断。

总结

2015是快乐的一年,2016则有了更多的沧桑,对很多东西有更多的思考、顾虑和怀疑,希望2017能在这些问题上都找到答案,希望2017是解惑的一年。