git：什么是git_git是什么软件-CSDN博客

git是什么

Git是一个免费、开源的版本控制软件

ps： git与gitlab的区别

Git是版本控制软件
Github是项目代码托管的平台，借助git来管理项目代码

git与其他版本控制系统的区别

版本控制是一种记录一个或若干个文件内容变化，以便将来查阅特定版本修订情况得系统。

记录文件的所有历史变化
随时可恢复到任何一个历史状态
多人协作开发或修改
错误恢复

直接记录快照，而非差异比较

git与其他版本控制系统的主要差别在于git对待数据的方式。

其他大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce、Bazaar 等等）将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异（它们通常称作基于差异（delta-based）的版本控制）
git把数据看作是对小型文件系统的一系列快照。在git中，每当你提交更新或者保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。为了效率，如果文件没有修改，git不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个快照流

近乎所有操作都是本地执行

在git中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其他计算机的信息（因为你本地磁盘上就有项目的完整历史）。

举个例子，要浏览项目的历史，Git 不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改， Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。
这也意味着你在离线或者没有 VPN 时，几乎可以进行任何操作。如你在飞机或火车上想做些工作，就能愉快地提交（到你的本地副本，还记得吗？），直到有网络连接时再上传。如你回家后 VPN 客户端不正常，那么也仍能工作。使用其它系统的话，做到这些是不可能或很费力的。

git保证完整性

git中所有的数据在存储前都计算校验和，然后以校验和来引用。这意味着不可能在git不知情时更改任何文件或者目录内容。这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。若你在传送过程中丢失信息或损坏文件，Git 就能发现。

Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串，基于 Git 中文件的内容或目录结构计算出来
实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。

git一般只添加数据

git操作几乎都是往git数据库中添加数据。你很难使用git从数据库中删除数据。也就是说，git几乎不会执行任何可能导致文件不可恢复的操作

如何用好源代码管理工具

原则一：要频繁的提交

很多开发人员不愿意轻易提交代码到源代码管理中心，喜欢“憋个大招”，本地做了大量修改，希望代码能“完美”。但这样做却没能享受到频繁提交带来的好处。

频繁提交，这意味着你每次提交的代码变更是比较少的，便于code review，同时如果出现问题，也可以快速定位或者直接回滚。

频繁提交，也让团队成员可以及时同步更新代码，不至于在最后合并时，产生有大量的合并冲突。

频繁提交，不意味着提交不完整的内容，而是要将提交的内容分拆，并且保证完整性

比如说，有一个涉及前后端的功能，可以拆分成前端和后端两次提交，各自有独立的代码和测试；比如说你开发新功能的时候发现有代码需要重构，那么对于重构的代码单独一次提交，不要和新功能的代码提交放一起。

原则二：每次提交后要跑自动化测试

自动化测试是非常有效的质量保障手段，而持续集成工具，可以让每次提交代码后，能自动的运行相应的自动化测试代码，有效的保证提交代码的指令。

源代码管理的第二个原则，就是每次提交，必须要运行自动化测试代码，如果测试不通过就不能合并，要对问题进行甄别和修复，确保提交的代码质量是没问题的。

原则三：提交的代码要有人审查

代码审查是自动化测试之外，一种非常行之有效的提高质量的手段。

通过代码审查，可以发现代码中潜在的问题。通过代码审查，也可以加强团队中的技术交流，让水平高的开发人员review，可以帮助提高整体代码水平；review高水平的代码也是一种非常有效的学习方法。

怎样做好代码审查

在审查被人代码的时候，先了解清楚这个提交的代码要解决的是什么问题，想象一样如果是自己来写这个代码会怎样写。这样在审查的时候，就能发现一些和自己不一样的地方，别人好的地方我们可以学习，不对的地方应该指出。

对于审查出来的问题，可以分成三个类型：

问题：如果对代码不清楚的地方，可以作为问题提出，进一步澄清确认
建议：原来的实现没有太大问题，但是可以有不同的实现后置更好的实现
阻塞：代码有明显问题，必须要修改

这样对于被审查的人可以针对你的问题进行针对性修改。

另外：在让别人 review 你的代码的之前，你要确保你的代码没有基础的问题比如单元测试要通过，不能有代码风格问题，首先你要确保你的代码是能正常工作并解决需求的，当然这些基本都可以通过自动化来操作，比如提交 PR的时候，自动化的检查代码风格，运行单元测试，保证邀请别人 review 你代码的时候，不要为这些小事费精力，提高 review 效率和积极性。

另外：代码合并之前在CI中运行的是小型测试和中型测试，不需要部署到真实环境，所有服务都在本机安装或者模拟，这
样速度是可控的。

问题：代码审核是纯手工做的吗？没有好的工具？