Google 和 Facebook 为什么不用 Git 管理源码？

程序锅偶尔看到比较好的关于 Git 的文章也会整理一番发出来，争取在 Git 的坑上再长棵树。

Git 项目的源码禁止开发者使用 C 标准库中的某些函数，原因是这些函数太容易被误用，就算使用得当也很容易出问题。因此 Git 的源码增加了一个 banned.h 的头函数，一旦你使用了这些被禁用的函数，将在编译时报错。

这很有用，这样git diff可以在其输出中展示新文件的完整内容。但是之前，diff中的文件路径没有被标记成新的。在一份相关说明提到，apply命令也改进了其对intent-to-add选项的处理。

你一定遇到过，一个很久没修改过的功能，莫名其妙的出现了问题？肉眼查代码、屡逻辑完全找不到问题点？前两天还好好的功能，怎么这个今天就不行了？这两天改动了这么多代码，到底是那一次改动引发的 Bug？这样非崩溃的 Bug，有时候想要排查出问题，并不是一件容易的事情。我想，这个时候你会需要 git bisect !

下面所有讨论，我们都假设只使用一个分支，也就是主分支 master 的情况，虽然这种作法并不符合 git 规范，但是现实情况中绝大部分用户是直接在 master 分支上进行工作的，所以在这里我们不去引入更加复杂的各种分支的情况，也不涉及标签 tag 的操作，只讲在最简单的主分支上如何回退。

。我们不要把git看得那么神秘，git的核心就是创建备份和恢复备份，但是衍生出一堆的新概念，这些抽象概念可以帮助我们快速的学会 git，但是要很好的使用git，我们还需要GIT的一些底层原理。本文章是从文件的层面出发来重新理解GIT的工作原理和GIT命令的具体实现。

不管是代码合并，分支提供给我们的并发,但我们也往往忽略了每次提交之后在我们本地项目根目录 下.git文件夹里面的存储变化。我遇到的git“臃肿”问题就是因为在提交的时候把较大文本加入版本控制，在其他人拉取更新反推远程分支的时候，每一次 都会加剧.git下面的objects的文件夹大小

Git 是目前世界上最优秀的分布式版本控制系统。版本控制系统是能够随着时间的推进记录一系列文件的变化以便于你以后想要的退回到某个版本的系统。版本控制系统分为三大类：本地版本控制系统，集中式版本控制系统和分布式版本控制系统

值得收藏的一些git使用技巧

Git很难：因为搞砸了很容易，但是找到如何修复错误的方法缺很难。Git官方的文档，存在“先有鸡还是先有蛋”的问题——除非你知道解决问题的方法的特定名字，否则很难查询到解决方案并顺利的解决自己的问题。

现在我们开始学习如何构建一个Git服务器，如何编写自定义的Git钩子（hook）来针对某些事件（比如，通知事件）触发特定的动作以及如何将你的代码发布到网站上。