Git是一个免费、开源的版本控制软件
ps: git与gitlab的区别
版本控制是一种记录一个或若干个文件内容变化,以便将来查阅特定版本修订情况得系统。
git与其他版本控制系统的主要差别在于git对待数据的方式。
在git中的绝大多数操作都只需要访问本地文件和资源,一般不需要来自网络上其他计算机的信息(因为你本地磁盘上就有项目的完整历史)。
举个例子,要浏览项目的历史,Git 不需外连到服务器去获取历史,然后再显示出来——它只需直接从本地数据库中读取。 你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改, Git 会查找到一个月前的文件做一次本地的差异计算,而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。
这也意味着你在离线或者没有 VPN 时,几乎可以进行任何操作。 如你在飞机或火车上想做些工作,就能愉快地提交(到你的 本地 副本,还记得吗?), 直到有网络连接时再上传。如你回家后 VPN 客户端不正常,那么也仍能工作。 使用其它系统的话,做到这些是不可能或很费力的。
git中所有的数据在存储前都计算校验和,然后以校验和来引用。这意味着不可能在git不知情时更改任何文件或者目录内容。 这个功能建构在 Git 底层,是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件,Git 就能发现。
Git 用以计算校验和的机制叫做 SHA-1 散列(hash,哈希)。 这是一个由 40 个十六进制字符(0-9 和 a-f)组成的字符串,基于 Git 中文件的内容或目录结构计算出来
实际上,Git 数据库中保存的信息都是以文件内容的哈希值来索引,而不是文件名。
git操作几乎都是往git数据库中添加数据。你很难使用git从数据库中删除数据。也就是说,git几乎不会执行任何可能导致文件不可恢复的操作
很多开发人员不愿意轻易提交代码到源代码管理中心,喜欢“憋个大招”,本地做了大量修改,希望代码能“完美”。但这样做却没能享受到频繁提交带来的好处。
频繁提交,这意味着你每次提交的代码变更是比较少的,便于code review,同时如果出现问题,也可以快速定位或者直接回滚。
频繁提交,也让团队成员可以及时同步更新代码,不至于在最后合并时,产生有大量的合并冲突。
频繁提交,不意味着提交不完整的内容,而是要将提交的内容分拆,并且保证完整性
比如说,有一个涉及前后端的功能,可以拆分成前端和后端两次提交,各自有独立的代码和测试;比如说你开发新功能的时候发现有代码需要重构,那么对于重构的代码单独一次提交,不要和新功能的代码提交放一起。
自动化测试是非常有效的质量保障手段,而持续集成工具,可以让每次提交代码后,能自动的运行相应的自动化测试代码,有效的保证提交代码的指令。
源代码管理的第二个原则,就是每次提交,必须要运行自动化测试代码,如果测试不通过就不能合并,要对问题进行甄别和修复,确保提交的代码质量是没问题的。
代码审查是自动化测试之外,一种非常行之有效的提高质量的手段。
通过代码审查,可以发现代码中潜在的问题。通过代码审查,也可以加强团队中的技术交流,让水平高的开发人员review,可以帮助提高整体代码水平;review高水平的代码也是一种非常有效的学习方法。
在审查被人代码的时候,先了解清楚这个提交的代码要解决的是什么问题,想象一样如果是自己来写这个代码会怎样写。这样在审查的时候,就能发现一些和自己不一样的地方,别人好的地方我们可以学习,不对的地方应该指出。
对于审查出来的问题,可以分成三个类型:
这样对于被审查的人可以针对你的问题进行针对性修改。
另外:在让别人 review 你的代码的之前,你要确保你的代码没有基础的问题比如 单元测试要通过,不能有代码风格问题,首先你要确保你的代码是能正常工作并解决需求的,当然这些基本都可以通过自动化来操作,比如提交 PR的时候,自动化的检查代码风格,运行单元测试,保证邀请别人 review 你代码的时候,不要为这些小事费精力,提高 review 效率和积极性。
另外:代码合并之前在CI中运行的是小型测试和中型测试,不需要部署到真实环境,所有服务都在本机安装或者模拟,这
样速度是可控的。
问题:代码审核是纯手工做的吗?没有好的工具?
这三个原则很简单,可以有效提升代码质量,减少合并冲突,及时发现问题,从而让你的协作更高效。
好在下载的时候有一个心理预期
使用 github 的 api 地址: https://api.github.com/repos/organization/repository
将 organization 和 repository 替换为相应项目的即可。
在返回的 json 字符串中可以看到 size 字段,即为项目大小,单位是 KB。
单位转换器