软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

30 | 用好源代码管理工具,让你的协作更高效

宝玉 2019-05-07
你好,我是宝玉。在今天,源代码管理工具在软件项目中已经是标准配置了,几乎每个软件项目都会应用到,可以说是最基础的项目开发工具。选择也很多,可以自己搭建源代码管理服务,也可以直接用网上托管的服务,例如 Github、Gitlab、BitBucket 等。
但同样是应用源代码管理工具,为什么有的团队就能做到代码质量高,随时能发布新版本,高效开发?而有的团队却不能做到高效开发,拿到的代码也不稳定,合并时冲突很多?
今天,我将带你了解一下源代码管理工具,以及如何才能应用好源代码管理工具,以保证代码质量稳定,协作高效。

源代码管理工具发展简史

源代码管理工具也叫版本控制系统,是保存文件多个版本的一种机制。每一次有人提交了修改,这个修改历史都会被版本控制系统记录下来。如下图所示,每一次对内容的修改,都会形成一个当前项目完整内容的快照。
(图片来源:《什么是版本控制?》)
源代码管理工具从诞生到现在已经有 40 多年的历史了,经历了四个阶段。

没有源代码管理工具的时代

早些年开发软件可没有我们这么幸运,在 1972 年之前都没有任何工具可以帮助我们做源代码管理。
这就意味着,当你开发时,必须要告知团队里的其他人,你正在对哪些文件进行编辑,好让他们不要操作相同的文件。当你花了很长时间完成你的修改后,可能这些文件早已经被团队里的其他开发成员修改或者删除了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • _CountingStars
    推荐一个简单好用的代码管理平台 gogs 非常轻量好用 比 gitlab 简洁很多

    作者回复: 🤝感谢推荐

    2019-05-07
    6
  • Charles
    我们现在git流程比较简单,因为人少,一个岗位就1,2个人
    有一个master分支,稳定版本,对应生产环境,持续集成自动发布
    有一个develop分支,新功能测试分支,对应测试环境,也是持续集成自动发布
    新版本或新特性或bug都创建独立开发分支,从项目管理角度无论是认领还是分配,尽量隔离开每个人的开发分支功能模块尽量独立,互不干涉,避免最终合并到develop分支后功能冲突(偶尔还是会存在,人为解决,比如哪个分支先上,先让哪个测试)

    看了老师这篇分享,再看看我们的流程,的确有点简单了,感觉按目前团队情况还可以往两个方面改进,一个是Tag对应生产环境,另外一个是测试服务器,隔离开每个新特性或版本可以通过自动化部署(比如容器,好像门槛也不高了)独立测试互补影响

    作者回复: 👍很好的补充分享。

    如果你现在人不多,这样的流程也不错的。另外不知道你们Code Review做的如何?这一环节也很重要!

    2019-05-07
    3
  • 刘晓林
    老师,我觉得PR和分支创建是没有关系的呀。分支间的合并应该是merge和rebase操作,PR应该是合并两个库中的同一个分支吧?

    作者回复: 对,merge和rebase也是一种合并的方式。

    PR的主要目的是为了让你可以看到这个分支和你要合并分支的差异,然后方便的在网页上review。

    PR不仅仅支持两个库的分支合并,同一个库的不同分支合并也一样支持。最简单就是你可以去GitHub创建一个库,然后创建一个分支,再提交更新到这个分支,你就可以创建PR了。

    2019-05-07
    3
  • bearlu
    我公司用svn,其实我觉得用什么工具都没关系,最重要是要了解工具,形成流程,按流程走,然后纠正流程。

    作者回复: 对,工具是辅助的,重要的还是能不能和人、流程结合起来。

    Git确实有很多比SVN方便的地方,例如本地的代码管理确实很方便。

    2019-05-07
    3
  • hua168
    代码审核是纯手工做的吗?没有好的工具?

    作者回复: 代码审查可以参考GitHub上一些开源项目的PR Review,通常网页上可以清楚的标记出代码修改,针对代码行可以写Review的评论,这就已经很方便了。

    其他工具主要是Lint检查代码规范、语法错误等,这个一般在CI里面就集成了。

    2019-05-07
    3
  • 浮生
    关于代码审查遇到的问题,想请老师给些建议,目前执行过程中团队成员,因为不是自己负责的功能,审查其他人代码的积极性并不高,再加上各自任务都很紧,即使审查也是匆匆过去,有时并未起到应有的效果,请问在流程机制中有方法可以提高审查的效果吗?

    作者回复: 很抱歉我暂时没有好的建议。

    可以尝试的是:
    1. 首先强制Review才能合并是必须的;
    2. 让PR小一点,减少Review的难度;
    3. 时间进度上,考虑上代码审查的时间,毕竟代码审查是磨刀不误砍柴工;
    4. 鼓励资深的程序员做好带头作用,可以把Review代码参与度和Review代码质量作为绩效的一部分;
    5. 你可以每天检查一遍审查通过的代码,对于明显有问题的私下可以谈一谈。

    2019-06-05
    1
    2
  • _CountingStars
    之前看到过一个关于 code review 的观点:在让别人 review 你的代码的之前,你要确保你的代码没有基础的问题比如 单元测试要通过,不能有代码风格问题,首先你要确保你的代码是能正常工作并解决需求的,当然这些基本都可以通过自动化来操作,比如提交 PR 的时候,自动化的检查代码风格,运行单元测试,保证邀请别人 review 你代码的时候,不要为这些小事费精力,提高 review 效率和积极性。

    作者回复: 是的,这个我认同,找别人Review之前自己先确保代码是没问题的,自己先检查一遍,自己先测试一遍,不能寄期望于其他人的Review。

    所以我会要求我们组的同时在提交代码的时候,附上截图,其实就是为了确认自己是测试过的。

    另外很多工作确实可以借助工具完成,例如lint工具,就可以帮助检查甚至格式化代码风格。

    2019-05-07
    2
  • 熊斌
    我们是自己搭建的gitlab做版本管理,以master建了一个名为developer的分支出来,大家开发的功能都往developer分支上面合并;dev作为发布测试环境的分支,等测试通过了,将dev与一个名为pro_branch(也是基于master出来的分支)的分支合并,发布生产,pro_banch发布完后会合并到master上面。。。看完这篇文章后,感觉我们完全忽视了tag的存在。。。

    作者回复: 版本管理除了开发分支主分支等常规做法,我觉得还有很关键的一个用法就是Pull Request(PR),每次开发一个新功能或者修复一个bug建一个分支,每次合并之前先提交PR,PR要有自动化测试结果(配合CI)和代码审查,自动化测试通过和代码审查通过才能合并。这样可以有效提高代码质量。

    2019-10-31
    1
  • 小老鼠
    1、平凡提交,每次提交都要测试,如果每次测试的时间很长咋办?
    2、如何控制测试代码的质量,若测试代码有bug咋办?
    3、提支了一个版本v1、提到git中,一小时后又出了一个新版本v2,v1版本没有被review,v2可以被提交吗?
    4、何时写测自己的代码?reviwe别人代码频率是多少不影响项目进度。
    5、对于同一code file,两个可以同时共享打开还是独有打开,若共享打开若两人修改同一行代码merage的时候会很麻烦的。
    6、如何作好分支到主干的合并,经常出现分支上测试pass,合到主干上好些fail了。

    作者回复: 1. 一般自动化测试是运行在CI上的,所以提交后CI会接管测试,你可以做其他事情。如果时间太长,需要优化,比如应该尽可能提高中小型测试比例提高速度。
    2. 可以通过代码审查来辅助;测试代码有bug就修复bug;
    3. 建议你可以去了解一下git的分支管理,会帮助你解答这些疑惑。通常来说各个分支的提交是不受影响的,但是合并到主干(master)时要注意顺序和解决好可能的合并冲突;
    4. 取决你的个人习惯或者团队规范,很多人喜欢TDD,先写测试用例;Review代码是属于磨刀不误砍柴工的事情,Review代码的时间应该作为项目进度的一部分。
    5. git是可以同时修改的,提交的时候可以自动或手动解决合并冲突,并不是很麻烦
    6. 主要还是要频繁合并,这样可以减少合并的冲突。合并后要重新运行自动化测试,以保证代码质量。合并后出现测试失败是正常现象,找出原因,并且加以修复,并看看是否能预防类似情况再次发生。

    2019-09-24
    1
  • 一路向北
    最早开发软件的时候还不知道有代码版本管理这类工具,都是靠保存代码来实现,当时那个痛苦,而且只是嵌入式软件,代码量相对要少很多,也是频频出错。直到知道有版本管理软件之后,感觉是长吁一口气。后来再发现,用好代码管理工具是一个很重要的技能,不但能提高开发效率,而且能够相对快速的出新产品。

    作者回复: 同感,最开始我也没用过,后来发现源代码管理太有用了。
    后来Git的分布式协作方式,也是刷新了以前对版本管理工具的认知。

    2019-05-18
    1
  • 小北
    老师文章很棒,我想请教一个问题。代码合并之前的自动化测试指的是单元测试,还是ui的自动化测试。因为ui自动化测试需要部署,执行。耗费时间太长。

    作者回复: 可以参考《29 | 自动化测试:如何把Bug杀死在摇篮里?》那一篇,代码合并之前在CI中运行的是小型测试和中型测试,不需要部署到真实环境,所有服务都在本机安装或者模拟,这样速度是可控的。

    2019-05-13
    1
  • 鲍勃
    老师,如果git仓库太多,是不是用repo来统一管理会比较方便么?比如统一切换分支,统一打tag之类的。

    作者回复: 抱歉,我没理解你的问题,你说的Repo和Git仓库有什么区别?因为我经常看到人家用Repo指代Git仓库。

    另外对于Git仓库,一般同一个团队大的规则流程是一样的,也就是基于不同Git仓库,开发流程是一致的。

    2019-05-10
    1
  • javaadu
    老师文章中给出的参考资料也很棒哦

    作者回复: 谢谢支持,也欢迎你分享觉得好的资料:)

    2019-05-07
    1
收起评论
13
返回
顶部