团队开发中 Git 最佳实践,不给队友拖后腿

今天跟大家分享下团队开发中Git最佳实践的知识。0 前言

在 2005 年的某一天,Linux 之父 Linus Torvalds 发布了他的又一个里程碑作品——Git。它的出现改变了软件开发流程,大大地提高了开发流畅度!直到现在仍十分流行,完全没有衰退的迹象。

本文要从具体实践角度,尤其是在团队协作中,阐述如何去好好地应用 Git。既然是讲在团队中的应用实践,我就尽可能地结合实际场景来讲述。
1 习惯养成

如果一个团队在使用 Git 时没有一些规范,那么将是一场难以醒来的噩梦!然而,规范固然重要,但更重要的是个人素质,在使用 Git 时需要自己养成良好的习惯。

1.1 提交 

如何去写一个提交信息,在具体开发工作中主要需要遵守的原则就是「使每次提交都有质量」,只要坚持做到以下几点就 OK 了:

提交时的粒度是一个小功能点或者一个 bug fix,这样进行恢复等的操作时能够将「误伤」减到最低;

用一句简练的话写在第一行,然后空一行稍微详细阐述该提交所增加或修改的地方;

不要每提交一次就推送一次,多积攒几个提交后一次性推送,这样可以避免在进行一次提交后发现代码中还有小错误。

假如已经把代码提交了,对这次提交的内容进行检查时发现里面有个变量单词拼错了或者其他失误,只要还没有推送到远程,就有一个不被他人发觉你的疏忽的补救方法——首先,把失误修正之后提交,可以用与上次提交同样的信息。

然后,终端中执行命令 git rebase -i [SHA],其中 SHA 是上一次提交之前的那次提交的,在这里是 3b22372。

最后,这样就将两次提交的节点合并成一个,甚至能够修改提交信息!

谁说历史不可篡改了?前提是,想要合并的那几次提交还没有推送到远程!

1.2 推送 

当自己一个人进行开发时,在功能完成之前不要急着创建远程分支。

1.3 拉取 

请读张文钿所写的《使用 git rebase 避免無謂的 merge》:

https://ihower.tw/blog/archives/3843。

1.4 合并 

在将其他分支的代码合并到当前分支时,如果那个分支是当前分支的父分支,为了保持图表的可读性和可追踪性,可以考虑用 git rebase 来代替 git merge;反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支,就不要采用 git rebase 了,避免出现重复的冲突和提交节点。

2 分支管理 

Git 的一大特点就是可以创建很多分支并行开发。正因为它的灵活性,团队中如果没有一个成熟的分支模型的话,那将会是一团糟。

要是谁真把这么乱的提交图表摆在我面前,就给他一个上勾拳!

2.1 分支模型 

有个很成熟的叫 Git Flow 的分支模型,它能够应对 99% 的场景,剩下的那 1% 留给几乎不存在的极度变态的场景。

需要注意的是,它只是一个模型,而不是一个工具;你可以用工具去应用这个模型,也可以用最朴实的命令行。所以,重要的是理解概念,不要执着于实行的手段。简单说来,Git Flow 就是给原本普普通通的分支赋予了不同的「职责」:

master——最为稳定功能最为完整的随时可发布的代码;
hotfix——修复线上代码的 bug;
develop——永远是功能最新最全的分支;
feature——某个功能点正在开发阶段;
elease——发布定期要上线的功能。

看到上面的「master」和「develop」加粗了吧?代表它们是「主要分支」,其他的分支是基于它们派生出来的。主要分支每种类型只能有一个,派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是:

更多信息可参考 xirong 所整理的《Git工作流指南》:

https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md

2.2 工具选择 

一直不喜欢「**最好用」这种命题,主观性太强,不会有一个结论。对于工具的选择,我一直都是秉承「哪个能更好地解决问题就用哪个」这个原则。所以,只要不影响到团队,用什么工具都是可以接受的。但根据多数开发人员的素质情况来看,建议使用图形化工具,例如 SourceTree(https://www.sourcetreeapp.com)。如果想用命令行,可以啊!先在心里问下自己:「我 Git 牛逼不?会不会惹麻烦给别人?」

在团队中应用 Git Flow 时,推荐使用 SourceTree 与 GitLab (https://gitlab.com/)配合的形式:

用 SourceTree 创建 feature 等分支以及本地的分支合并、删除;
用 GitLab 做代码审核和远程的分支合并、删除。

SourceTree 和 GitLab 应该是相辅相成的存在,而不是互相取代。

3 事前准备 

为了将一些规范性的东西和 Git Flow 的部分操作自动化处理,要对 SourceTree 和 GitLab 进行一下配置。

3.1 SourceTree 

按下 command + , 调出「Preferences」界面并切换到「Git」标签,勾选「Use rebase instead of merge by default for tracked branches」和「Do not fast-forward when merging, always create commit」。

这样设置之后,在点「Pull」按钮拉取代码时会自动执行 git pull –rebase;并且,每次合并时会自动创建新的包含分支信息的提交节点。

接下来,点击工具栏中的「Git Flow」按钮将相关的流程自动化。如果没有特殊需求,直接按下对话框中的「OK」就好了。初始化完成后会自动切换到 develop 分支。

这下再点「Git Flow」按钮所弹出的对话框就是选择创建分支类型的了。

3.2 GitLab 

在创建项目仓库后一定要把主要分支,也就是 master 和 develop 给保护起来。为它们设置权限,只有项目负责人可以进行推送和删除等操作。

被保护的分支在列表中会有特殊的标记进行区分。

4 开发流程 

在引入 Git Flow 之后,所有工作都要围绕着它来展开,将原本的流程与之结合形成「基于Git Flow 的开发流程」。

4.1 开发功能 

在确定发布日期之后,将需要完成的内容细分一下分配出去,负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具创建一个对应的 feature 分支。如果是多人配合的话,创建分支并做一些初始化工作之后就推送创建远程分支;否则,直到功能开发完毕要合并进 develop 前,不要创建远程分支。

功能开发完并自测之后,先切换到 develop 分支将最新的代码拉取下来,再切换回自己负责的 feature 分支把 develop 分支的代码合并进来。合并方式参照上文中的「合并」,如果有冲突则自己和配合的人一起解决。

然后,到 GitLab 上的项目首页创建合并请求(merge request)。

「来源分支」选择要被合并的 feature 分支且「目标分支」选择 develop 分支后点击「比较分支」按钮,在出现的表单中将处理人指派为项目负责人。

项目负责人在收到合并请求时,应该先做下代码审核看看有没有明显的严重的错误;有问题就找负责开发的人去修改,没有就接受请求并删除对应的 feature 分支。

在将某次发布的所需功能全部开发完成时,就可以交付测试了。

4.2 测试功能 

负责测试的人创建一个 release 分支部署到测试环境进行测试;若发现了 bug,相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。

4.3 发布上线 

当确保某次发布的功能可以发布时,负责发布的人将 release 分支合并进 master 和 develop 并打上 tag,然后打包发布到线上环境。

建议打 tag 时在信息中详细描述这次发布的内容,如:添加了哪些功能,修复了什么问题。

4.4 修复问题 

当发现线上环境的代码有小问题或者做些文案修改时,相关开发人员就在本地创建 hotfix 分支进行修改,具体操作参考「开发功能」。

如果是相当严重的问题,可能就得回滚到上一个 tag 的版本了。

5 额外说明 

这里所提到的事情,虽非必需,但知道之后却会如虎添翼。

5.1 分支命名 

除了主要分支的名字是固定的之外,派生分支是需要自己命名的,这里就要有个命名规范了。强烈推荐用如下形式:

feature——按照功能点(而不是需求)命名;
release——用发布时间命名,可以加上适当的前缀;
hotfix——GitLab 的 issue 编号或 bug 性质等。

另外还有 tag,用语义化的版本号(http://semver.org/lang/zh-CN/)命名。

5.2 发布日期 

发布频率是影响开发人员与测试人员的新陈代谢和心情的重要因素之一,频繁无规律的发布会导致内分泌失调、情绪暴躁,致使爆粗口、砸电脑等状况出现。所以,确保一个固定的发布周期至关重要!

在有一波或几波需求来临之时,想挡掉是不太可能的,但可以在评审时将它(们)分期,在某个发布日之前只做一部分。这是必须要控制住的!不然任由着需求方说「这个今天一定要上」「那个明天急着用」的话,技术人员就等着进医院吧!

Image placeholder
aoshuang
未设置
  28人点赞

没有讨论,发表一下自己的看法吧

推荐文章
项目管理最佳实践,企业如何进行有效的项目管理

前言:企业在划分项目时,可按照项目的复杂程度、管理范围等将项目分为三个级别,分别是企业级、部门级和小组级(与目标划分原则相同),然后将每一级的目标与项目对应起来。我们知道,企业制定的目标(OKR),一

springDataJpa 最佳实践

springDataJpa最佳实践 前言 SpringDataJpa框架的目标是显著减少实现各种持久性存储的数据访问层所需的样板代码量。SpringDataJpa存储库抽象中的中央接口是Reposit

走进龙岗“智慧大脑” 见证IOC的最佳实践

这里,拥有全球首例地铁5G超宽带车地无线通讯;这里,借助AI、5G、物联网等技术推动工地现场科学化和智能化管理;这里,构建了开放兼容的统一政务云平台;这里,建设了先进、安全、智能的标杆园区;这里,就是

同程旅游微服务最佳实践

本文首发胖波聊架构界,微信公众号:xiaobo2as本文概要导言微服务拆分的四个维度微服务应该如何维护版本如何从单体架构平滑过渡到微服务结语一、导言同程微服务从立项到实施推广已经走过了整整两个年头,从

Docker最佳实践:5个方法精简镜像

本文记录了精简Docker镜像尺寸的必要性及好处精简Docker镜像的好处很多,不仅可以节省存储空间和带宽,还能减少安全隐患。优化镜像大小的手段多种多样,因服务所使用的基础开发语言不同而有差异。本文将

Code Review最佳实践

我一直认为CodeReview(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题。包括像Google、微软这些公司,CodeReview都是基本要求,代码合

做银行家里的数据专家:ING探索大数据时代下的金融最佳实践

大数据文摘出品记者:高延6月18-21日,O’ReillyAIConference在北京召开。大会上,来自荷兰的金融公司ING的IT主管BasGeerdink带来了《关于数字驱动企业》的主题分享。进入

一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

Express 官网文档翻译-3.2-开发中间件

为Express应用开发中间件概述中间件函数本质上是一些可以在应用的请求-响应周期内,访问请求对象 (req),响应对象 (res),和next方法的函数。next方法是Express路由中的一个方法

开发中常见的Oracle三大故障与调优方法

墨墨导读:怀晓明先生(网名lastwinner),是具有多年数据库开发与项目管理经验的数据库专家。曾获得第一届ITPUB较佳建议奖,在多个大型IT企业多年的工作历练中,积累了丰富的系统架构设计经验。合

研发总监谈:异地研发中心的建设的若干要点(上)

和楼主说好要写一点技术管理方向的文章,从开始说到正式接受主题为《异地研发中心建设模式》的约稿有数月之久,原计划1~2周内写完,结果光思考“应该要写什么”就花了一个月。一方面是拖延癌的原因,另一方面也是

为什么说 Python 是人工智能最佳Web开发的语言?

由于所有用户都可以使用大量的预构建库,因此Python非常适合人工智能在Web开发中的应用–但是还有什么能让它变得如此吸引人?在AbsoluteDigitalMedia,我们将仔细研究Python的历

12 款最佳的 Android 防病毒工具

Android防病毒工具有很多,本文将介绍12款最佳工具在保护度、使用性和功能方面的表现。 下面是根据AV-TEST针对20款Android安全应用,于2019年6月评估的12款最佳商业级And

MongoDB与阿里云达成战略合作,云将是数据库最佳载体

摘要:开源数据库厂商与云服务供应商两大阵营之间存在争议是事实,MongoDB与阿里云达成战略合作,背后意味着什么?对MongoDB,对阿里云分别意味着什么?对整个数据库产业又意味着什么?MongoDB

Wi-Fi信号不好?混合组网架构是最佳选择

我曾与许多实施过数字化项目的公司合作过,最终却以失败告终。理念正确、实施健全、市场机会都有,却忽略了一个薄弱环节:Wi-Fi网络。例如,一家大型医院希望通过将遥测信息发送到移动设备,来改善临床医生对患

NAS与对象存储:谁是非结构化数据存储的最佳选择?

非结构化数据是增长最快的数据类型之一。随着企业日积月累地生成、收集和存储越来越多的数据,必然会带来一个问题:什么是存储非结构化数据的最佳方式?直白来说,非结构化数据就是不遵循传统数据库格式的数据,其结

数据科学在市场营销领域的8个最佳用例

在这篇文章中,我们将介绍一些数据科学在营销领域的关键用例。就数据科学的关键目标是将数据转化为可操作的洞察而言,为了获得更高的盈利,营销领域不能忽略这些洞察的应用。大数据技术,为在营销中更好地了解目标受

从0到1,马蜂窝大交通团队如何构建高效研发流程体系?

“旅游之前,先上马蜂窝”已经成为许多人习惯性的选择。2019年5月,马蜂窝完成了新一轮融资,金额达2.5亿美元。这也标志着通过集内容、社区、交易为一体的消费决策场景构建,从攻略社区起家的马蜂窝开始迈入

三个月5位老员工离职!苹果健康团队被曝内部分歧严重,员工扎堆儿离开

大数据文摘编辑部出品一年一度的秋季发布会召开前夕,苹果健康团队忽然被曝,大批老员工高调离职。据外媒CNBC报道,最近几个月,苹果的医疗保健团队紧张氛围愈加严重,这种氛围据内部人士称已经持续了一段时间,

两个月三项成果,对标谷歌!独家对话小米AutoML团队,如何让模型搜索更公平

大数据文摘出品作者:曹培信机器学习自动化(AutoML)正在引领机器学习的下一个时代,而要想让机器自己学会“炼丹”,其中最关键的步骤就是,找到最合适的算法模型,也即自动化神经架构搜索(NeuralAr

探秘ASC19:首次设置的“超级团队对抗赛”究竟是什么?

4月21日,2019ASC世界大学生超级计算机竞赛(ASC19)总决赛在大连理工大学正式拉开帷幕。根据赛程,在4月23日正式竞赛之前,所有参赛队伍的主要任务是完成竞赛系统的搭建与调试,力求在3000瓦

走近科学,探究阿里闲鱼团队通过数据提升Flutter体验的真相

背景闲鱼客户端的Flutter页面已经服务上亿级用户,因此用户体验尤其重要,完善Flutter性能稳定性监控体系,以便及早发现线上性能问题,也可以作为用户体验提升的衡量标准。那么Flutter的性能到

阿里毕玄:从生物系学生,到技术团队 leader,他是如何完成自我蜕变的

©MSuzanneD.Williams编者按:新的技术层数不穷,困扰程序员的不仅有学不完的新技术,还有每个人在职业生涯中必然会面对的成长路线问题。这就像一个产品有了清晰的roadmap,下一步走的才会

小蜜团队万字长文 | 讲透对话管理模型最新研究进展

对话管理模型背景从人工智能研究的初期开始,人们就致力于开发高度智能化的人机对话系统。艾伦·图灵(AlanTuring)在1950年提出图灵测试[1],认为如果人类无法区分和他对话交谈的是机器还是人类,

敏捷方法适合什么样的团队?

敏捷开发适用于研发团队吗?距敏捷开发宣言的发布已经过去了将近二十年,现在很多团队都在思考“敏捷”的工作方式。营销团队想要尝试Sprint的方式来加速盈利,运营团队正在采用Scrum敏捷项目管理,而人力