在需要使用该功能的目录下创建.gitattributes文件并在.gitattributes中添加ident属性：
* ident
这样在任何文件中都可以使用$Id$来显示当前文件最后修改的版本号。
如果项目是从svn或者其他版本控制系统移植过来的可能文件中已经有了版本信息，比如
/*
* $Id: abcdefghijklmn $
*/
象这样的版本信息git会自动识别并替换成git下的版本，当然前提是这个文件有过修改或者提交。
2010-04-21
git中使用$Id$显示版本号
2009-04-07
版本控制工具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 //在服务器上把修改的文件提交
这样服务器上面的补丁就打好了
2009-01-04
版本控制工具GIT的使用（一）分机打补丁
最近从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 再一次提交
剩下的就是上面提到的打不定的方法了
