30 | 用好源代码管理工具，让你的协作更高效
源代码管理工具发展简史
没有源代码管理工具的时代
请订阅文章所属专栏。
精选留言(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