30 | 用好源代码管理工具，让你的协作更高效
该思维导图由 AI 生成，仅供参考
源代码管理工具发展简史
没有源代码管理工具的时代
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
源代码管理工具在软件项目中扮演着至关重要的角色。本文从源代码管理工具的发展历程出发，介绍了没有源代码管理工具的时代、本地版本管理、集中式版本管理和分布式版本管理等四个阶段。文章详细介绍了如何选择合适的源代码管理系统，包括自行搭建源代码管理系统和利用网上的代码托管平台。此外，文章提出了三个原则来帮助读者更好地使用源代码管理工具，包括频繁提交、每次提交后跑自动化测试以及提交的代码要有人审查。通过这些原则，读者可以提升代码质量，减少合并冲突，及时发现问题，从而让协作更高效。 文章还介绍了GitHub开发流程的关键步骤，强调了稳定的代码分支和代码审查、自动化测试通过后才能合并的重要性。此外，还探讨了GitHub开发流程中的常见问题，并提供了解决方案。最后，总结了源代码管理工具的重要性和设计好开发流程对保证代码质量和提高协作效率的重要性。 总的来说，本文深入浅出地介绍了源代码管理工具的发展历程、选择和使用方法，以及GitHub开发流程的关键步骤和常见问题。读者可以通过本文了解到源代码管理工具的重要性，以及如何设计好开发流程来提高代码质量和协作效率。
《软件工程之美》，新⼈⾸单¥59
全部留言(14)
- 最新
- 精选
mgxian推荐一个简单好用的代码管理平台 gogs 非常轻量好用 比 gitlab 简洁很多作者回复: 🤝感谢推荐
2019-05-0710
浮生关于代码审查遇到的问题，想请老师给些建议，目前执行过程中团队成员，因为不是自己负责的功能，审查其他人代码的积极性并不高，再加上各自任务都很紧，即使审查也是匆匆过去，有时并未起到应有的效果，请问在流程机制中有方法可以提高审查的效果吗？作者回复: 很抱歉我暂时没有好的建议。 可以尝试的是： 1. 首先强制Review才能合并是必须的； 2. 让PR小一点，减少Review的难度； 3. 时间进度上，考虑上代码审查的时间，毕竟代码审查是磨刀不误砍柴工； 4. 鼓励资深的程序员做好带头作用，可以把Review代码参与度和Review代码质量作为绩效的一部分； 5. 你可以每天检查一遍审查通过的代码，对于明显有问题的私下可以谈一谈。
2019-06-0558
bearlu我公司用svn，其实我觉得用什么工具都没关系，最重要是要了解工具，形成流程，按流程走，然后纠正流程。作者回复: 对，工具是辅助的，重要的还是能不能和人、流程结合起来。 Git确实有很多比SVN方便的地方，例如本地的代码管理确实很方便。
2019-05-075
Charles我们现在git流程比较简单，因为人少，一个岗位就1，2个人 有一个master分支，稳定版本，对应生产环境，持续集成自动发布 有一个develop分支，新功能测试分支，对应测试环境，也是持续集成自动发布 新版本或新特性或bug都创建独立开发分支，从项目管理角度无论是认领还是分配，尽量隔离开每个人的开发分支功能模块尽量独立，互不干涉，避免最终合并到develop分支后功能冲突（偶尔还是会存在，人为解决，比如哪个分支先上，先让哪个测试） 看了老师这篇分享，再看看我们的流程，的确有点简单了，感觉按目前团队情况还可以往两个方面改进，一个是Tag对应生产环境，另外一个是测试服务器，隔离开每个新特性或版本可以通过自动化部署（比如容器，好像门槛也不高了）独立测试互补影响作者回复: 👍很好的补充分享。 如果你现在人不多，这样的流程也不错的。另外不知道你们Code Review做的如何？这一环节也很重要！
2019-05-074
J.M.Liu老师，我觉得PR和分支创建是没有关系的呀。分支间的合并应该是merge和rebase操作，PR应该是合并两个库中的同一个分支吧？作者回复: 对，merge和rebase也是一种合并的方式。 PR的主要目的是为了让你可以看到这个分支和你要合并分支的差异，然后方便的在网页上review。 PR不仅仅支持两个库的分支合并，同一个库的不同分支合并也一样支持。最简单就是你可以去GitHub创建一个库，然后创建一个分支，再提交更新到这个分支，你就可以创建PR了。
2019-05-074
hua168代码审核是纯手工做的吗？没有好的工具？作者回复: 代码审查可以参考GitHub上一些开源项目的PR Review，通常网页上可以清楚的标记出代码修改，针对代码行可以写Review的评论，这就已经很方便了。 其他工具主要是Lint检查代码规范、语法错误等，这个一般在CI里面就集成了。
2019-05-074- mgxian之前看到过一个关于 code review 的观点：在让别人 review 你的代码的之前，你要确保你的代码没有基础的问题比如 单元测试要通过，不能有代码风格问题，首先你要确保你的代码是能正常工作并解决需求的，当然这些基本都可以通过自动化来操作，比如提交 PR 的时候，自动化的检查代码风格，运行单元测试，保证邀请别人 review 你代码的时候，不要为这些小事费精力，提高 review 效率和积极性。
作者回复: 是的，这个我认同，找别人Review之前自己先确保代码是没问题的，自己先检查一遍，自己先测试一遍，不能寄期望于其他人的Review。 所以我会要求我们组的同时在提交代码的时候，附上截图，其实就是为了确认自己是测试过的。 另外很多工作确实可以借助工具完成，例如lint工具，就可以帮助检查甚至格式化代码风格。
2019-05-073 
熊斌我们是自己搭建的gitlab做版本管理，以master建了一个名为developer的分支出来，大家开发的功能都往developer分支上面合并；dev作为发布测试环境的分支,等测试通过了，将dev与一个名为pro_branch（也是基于master出来的分支）的分支合并，发布生产，pro_banch发布完后会合并到master上面。。。看完这篇文章后，感觉我们完全忽视了tag的存在。。。作者回复: 版本管理除了开发分支主分支等常规做法，我觉得还有很关键的一个用法就是Pull Request（PR），每次开发一个新功能或者修复一个bug建一个分支，每次合并之前先提交PR，PR要有自动化测试结果（配合CI）和代码审查，自动化测试通过和代码审查通过才能合并。这样可以有效提高代码质量。
2019-10-3131
小老鼠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-241
一路向北最早开发软件的时候还不知道有代码版本管理这类工具，都是靠保存代码来实现，当时那个痛苦，而且只是嵌入式软件，代码量相对要少很多，也是频频出错。直到知道有版本管理软件之后，感觉是长吁一口气。后来再发现，用好代码管理工具是一个很重要的技能，不但能提高开发效率，而且能够相对快速的出新产品。作者回复: 同感，最开始我也没用过，后来发现源代码管理太有用了。 后来Git的分布式协作方式，也是刷新了以前对版本管理工具的认知。
2019-05-181
