概要
本文介绍了git format-patch提交更新的替代方案，使用类似CVS的提交和更新来代替现在正使用的操作相对麻烦的format-patch。
如何创建一个CVS模式的公共库?
确保用户组git已存在，确保开发人员在git组中
chgrp -R .git git # 将.git改为git组
chmod -R 775 .git
cd .git&&chmod 664 config description index&&chmod 777 HEAD
通过以上命令就创建了一个CVS模式的公共库，可以方便的使用push和pull来进行操作。
从远程服务器192.168.9.9的/var/proj/project目录检出项目到project目录下
git clone maker@192.168.9.9:/var/proj/project project
每个用户clone项目之后需要设置身份
git config –global user.name “maker” # 改成自己的
git config –global user.email “makerwang@gmail.com” # 改成自己的
已检出项目不需要做任何修改，在必要情况下设置身份即可。
PUSH
在本地提交(commit)后，使用git push来将本地的(这里指每个开发者独立检出的项目)修改提交到公共库中。
切记,使用push命令提交之后再对公共库进行修改之前要把公共库切换到最新版本
PULL
使用git pull来进行项目的更新，提交前最好使用pull来将项目更新至最新，否则将无法进行push操作。
如果两人同时修改了同一行代码，pull操作将提示冲突”both modified”，通过git status查看冲突，人工解决冲突并将解决冲突后的文件再次进行提交，然后再进行push操作。
在给arch的最近一次更新中，发现git push命令无法正常执行，报错
![remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to ‘xxx.xxx.xxx.xxx:xxx/xxx/xxxxx/xxxxxx’
这是由于git默认拒绝了push操作，需要进行设置，修改.git/config添加如下代码：
[receive]
denyCurrentBranch = ignore
在需要使用该功能的目录下创建.gitattributes文件并在.gitattributes中添加ident属性：
* ident
这样在任何文件中都可以使用$Id$来显示当前文件最后修改的版本号。
如果项目是从svn或者其他版本控制系统移植过来的可能文件中已经有了版本信息，比如
/*
* $Id: abcdefghijklmn $
*/
象这样的版本信息git会自动识别并替换成git下的版本，当然前提是这个文件有过修改或者提交。
上一篇的GIT文章，介绍了在自己的机器上打补丁的方法（即分机打补丁），大家做的东西总归是要合并在一起的嘛，不管需要与否，我们还是了解一下，比较好。（下述方法，可能不适用于所有情况，只是针对我们的操作进行讲解）
我们的工作环境是在Ubuntu下面。
在自己的机器上
sftp root@192.168.1.1 //链接到局域网的服务器
put /home/zhuozi/project/0001-hello.patch /home/project/ //把你要打的补丁上传到服务器上
maker: 这里可以使用scp命令来完成两台主机间的文件传输，上面的动作可以写成
scp ~/project/0001-hello.patch root@192.168.1.1:/home/project/
进入服务器项目的所在目录
git apply --check 0001-hello.patch //检查补丁是否正确
git apply 0001-hello.patch //如果补丁正确，应用此命令打补丁
git status //在服务器上查看需要补丁修改过的文件
git commit //在服务器上把修改的文件提交
这样服务器上面的补丁就打好了
最近从SVN转换到GIT下工作，遇到了很多的问题，很多的命令不一样了，有一些原理机制也不太一样了。
从我们实际的项目入手，把我需要用到的主要操作记录下来。
1.checkout
git clone git://address
2.如果你不进行任何配置（我就没有进行任何配置），你现在的工作分支就是当前本机的“主干”，再你修改之后需要进行提交
git commit 这里的提交并不是提交到了，服务器或者你们工作小组的某一台机器，而是提交到了你的本机。（自己本机还需要提交？这个工作原理，大家可以查看一下文档。）
3.在提交之后，我们需要打补丁。
$ git-fetch origin
$ git-rebase origin
$ git-format-patch origin
在执行这三个操作之间最好先 git pull更新一下，再完成这些操作之后，在当前的文件夹下会生成一个文件。你把这个文件，也就是补丁
发给项目的负责人，由他来进行合并。
如果在自己本机提交多次，打补丁的时候会生成多个补丁文件，这样一起传输有一些麻烦，合并起来也不是很方便。我们就需要在打补丁
之前
$git log
先查看一下版本
$git-reset –soft 哈希数（即版本序号）回退到以前的版本再次重新打补丁，这里的回退只是版本的回退，修改的文件都没有回退
到以前。
整个分机打补丁的流程就完成了，分机需要做的就是更新－>修改－>打补丁。
刚刚接触git，就先写这么多。
PS：补充
经过一阶段的使用，在实际的应用过程中，我们在打补丁的时候遇到了很多的问题。
虽然说具体问题具体分析，但是还是在这里写一下一些问题的处理办法。
#git status 我们在提交之前都会看一下，我们修改了哪些文件。
#git add 如果被修改的文件没有被提交，记得要添加上去。
#git commit 我们把我们自己修改的文件提交一下。
#git pull 更新，一直更新到already什么的，如果遇到冲突了就解决，解决完之后commit上去，再更新
#git log 查看版本，如果补丁打不上，选择回退的版本，也就是服务器上最新的版本。
(这里要注意一下，有的时候会出现一个补丁自动合并的版本，这个时候我们就需要回退到这个版本的下一个)
#git status 版本回退之后，查看一下文件的状态
#git commit 再一次提交
剩下的就是上面提到的打不定的方法了
