Git的功能特性：
从一般开发者的角度来看，git有以下功能：
1、从服务器上克隆
数据库（包括代码和版本信息）到单机上。
2、在自己的机器上创建分支，修改代码。
3、在单机上自己创建的分支上提交代码。
4、在单机上合并分支。
5、新建一个分支，把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6、生成补丁（patch），把补丁发送给主开发者。
7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。
功能介绍：
从主开发者的角度（假设主开发者不用开发代码）看，git有以下功能：
1：查看邮件或者通过其它方式查看一般开发者的提交状态。
2：打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。
3：向公共服务器提交结果，然后通知所有开发人员。
优点：
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
离线
工作。
缺点：
资料少（起码中文资料很少）。
学习周期相对而言比较长。
不符合常规思维。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
开发模式
尽管 git 是一个正式项目发布系统，它却可以方便地将你的项目建立在松散的开发人员组织形式上。
Linux内核的开发，就是按这样的模式进行的。在 Randy Dunlap 的著作中（"Merge to Mainline" 第17页）就有很好的介绍
需要强调的是真正的非常规的开发组织形式，git 这种组织形式，意味着对于工作流程的约束，没有任何强迫性的原则。你不必从唯一一个远程版本库中导入（工作目录）。
项目领导人（project lead）的工作推介
1.在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。
2.准备一个能让大家访问的公共版本库。
如果其他人是通过默协议的方式（http）来导入版本库的，那么你有必要保持这个 默协议的友好性。 git-init-db 之后，复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用，但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。
3.将你的主版本库推入公共版本库。
4.git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线，可能的话，执行一下 git-prune，要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。
5.在你的主版本库中开展工作，这些工作可能是你自己的最项目的编辑，可能是你由 email 收到的一个补丁，也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。
你可以在任何你喜欢的时候重新打包你的这个私人的版本库。
6.将项目的进度推入公共库中，并给大家公布一下。
7.尽管一段时间以后，"git-repack" 公共库。并回到第5步继续工作。
项目的子系统负责人（subsystem maintainer）也有自己的公共库，工作流程大致如下：
1.准备一个你自己的工作目录，它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址（URL）将被保存在 .git/remotes/origin 中。
2.准备一个可以给大家访问的公共库，就像项目领导人所做的那样。
3.复制项目领导人的公共库中的打包文件到你的公共库中，除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。
4.将你的主版本库推入你的公共版本库，并运行 git-repack，如果你的公共库是通过的公共库是通过 pull 来导入的数据的话，再执行一下 git-prune 。
5.在你的主版本库中开展工作。这些工作可能包括你自己的编辑，来自 email 的补丁，从项目领导人，“下一级子项目负责人”的公共库哪里导入的工作等等。
你可以在任何时候重新打包你的私人版本库。
6.将你的变更推入公共库中，并且请“项目领导人”和“下级子系统负责人”导入这些变更。
7. 每隔一段时间之后，git-repack 公共库。回到第 5 步继续工作。
“一般开发人员”无须自己的公共库，大致的工作方式是：
1.准备你的工作库，它应该用 git-clone 克隆自“项目领导人”的公共库（如果你只是开发子项目，那么就克隆“子项目负责人”的）。克隆的源地址（URL）会被保存到 .git/remotes/origin 中。
2.在你的个人版本库中的 master 分支中开展工作。
3.每隔一段时间，向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作，即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins 。
4.用 git-cherry origin 命令，看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。（关于 git-rebase 命令，请参考 git-rebase）
5.用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。
