git 简要教程！
时间：2010-11-05 来源：crazytyt
转自：http://www.kuantu.com/kite/173648
在ruby社区里，Git的使用占到了88%的比例，而Svn只有7.5%.......来源看这里
那么还等什么，为了不被别人耻笑，赶紧学习Git吧。
Git号称是分布式版本控制系统，这是什么？暂且不管，一起来用用看，如果你有Svn的使用基础，学起来会更快
零，介绍你自己给git
git config --global user.name "lilu"
git config --global user.email "[email protected]"
为什么呢，因为git可以使用从mail来的Patch去工作，这样作者和提交者不一定是同一人，这是细节不用了解。。。。
一，开始项目
在你的项目根目录下
git init （svnadmin create)
然后，如果要把全部文件都加入版本库,就
git add . (svn import)
但是，一般我们不会把所有文件都加入，那么以rails项目为例，可以在根目录下建立个叫.gitignore的文件，里边放如下内容
log/*.log
tmp/**/*
这样就不会加入log和tmp下的内容了,记得不要忘记修改.gitignore后也要提交这个文件
现在向版本库的提交
git commit -m "初始化项目"
-m后边跟的是注释
二，在项目里工作
用git工作,一定要小步走(当然任何版本控制系统都是如此)。
一个规则：如果你不能把你每次提交的注释缩短成一句话，说明你太久没有提交了。
检查你的文件状态
git status (svn status)
查看你的文件有什么变化
git diff (svn diff | less)
查看某版本和路径的变化
git diff rev path (svn diff -rrev path)
增加你的修改(git status里提示的)
git add file1 newfile2 newfolder3 (svn add file)
当然也可以 rm/mv 之类
最后，提交你的工作
git commit -m "xxx"
每次都git add你做过修改的文件很麻烦（svn就不用）,git有办法避免
git commit -a -m "xxx" （svn commit)
这样就自动提交做过修改的文件了，不需要git add file(当然新建文件和目录还是需要add)
看你以前都做过什么
git log (svn log | less)
加参数-nx可以看最后的x次修改
看文件的变化情况
git blame file (svn blame file)
观察整个版本库
git show rev:path/to/file (svn cat url)
git show rev:path/to/directory (svn list url)
git show rev (svn diff -crev url)
三，如何应对错误
你做了修改，但不想提交，可以把他们扔掉
git reset --hard
恢复单个文件
git checkout myfile.txt (svn revert myfile.txt)
有些文件忘了提交
git reset --soft HEAD^
然后add并commit
写错了注释
git commit --amend
可以更改上一个提交的注释，这一点比Svn强太多了！
四，稍微进阶一点的知识
版本号
git的版本号是用的16进制字串(SHA1 id)，看起来很吓人，但其实还比较好用
首先你可以用HEAD标注最新的版本，然后HEAD^就是上一级的版本，然后HEAD^^......也可以HEAD～n，就可以往前追溯n个版本
其次你不用写全那个16进制串，可以就写头几个数字，只要是独一的就能自动匹配
还有更多可研究的方法和窍门，总之使用起来不比Svn的递增数字版本号差就是了.
如何写注释
一般在社区的规则是第一行用一句话来概括修改的主要内容(不超过50个字符),然后是一个空行，最后是详细的修改原因和细节，如果有必要
空行的原因是第一行往往会成为邮件的标题，或者显示在可视化工具的列表里，比如gitk
提交时可以有多个-m，每一个都会独立成一个段落，善用这点
分支和合并
之前介绍过svn的分支与合并，见这里和这里,基本概念就不重复了
新建分支
git branch feature_x (svn copy http://example.com/svn/trunk http://example.com/svn/branches/feature_x)
查看现有分支
git branch (svn list http://example.com/svn/branches/)
feature_x
* master
带*的表示现有分支
转换分支
git checkout feature_x (svn switch http://example.com/svn/branches/feature_x)
合并分支回主干
先切回主干
git checkout master
然后合并
git merge feature_x (svn merge -r rev:HEAD http://example.com/svn/branches/feature_x)
git的merge又一次体现了比Svn的优越性，她可以保留每个分支的全部历史！还可以自动追踪已合并的分支并保证不重复
我们在svn的文里说过的选取合并(cherry-picking)也有了直接支持
git cherry-pick rev (svn merge -c rev url)
如果没有冲突，合并会自动提交
删除分支
git branch -d feature_x
标注版本(Tag)
非常简单
git tag v1.0.0 (svn copy http://example.com/svn/trunk http://example.com/svn/tags/name)
git的tag功能比Svn的简单copy强大很多，可以用-a命名，还可以有注释，权限跟踪什么的
推荐你用tag代替默认的那些每个版本的md5 id给别人看
五，分布式版本控制系统(DVCS)
相信到这里，你会有一个疑问。
没错，我们到现在为止做的一切，都在本地！
不需要上网，不需要远程服务器！
这也就是SVN和Git最大的区别，Git的版本库完全是在本地的，就连分支，也可以只属于本地
上边所讲的内容，都是只有自己一个人开发项目时所需要的
那么，如何和别人共享版本库并且互相同步对方的内容呢？请往下看
六，在远程版本库上工作
假设你为某个项目工作，此项目有git版本库的公开地址(以linux 2.6内核项目为例，汗。。。）
首先签出远程版本库
git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 (svn checkout)
clone的这个本地版本甚至包括全部历史
这个远程版本对应的默认称呼是origin
如果远程有分支的话呢？
git checkout -b branch origin/branch （svn switch url）
这样就让远程分支对应本地的一个分支了
还可以给你本地版本库增加远程分支
git remote add name url
查看远程版本库
git remote 后边可以跟show/add等等
更新的话是
git pull (svn update)
这个实际上是git fetch + git merge, 就是从远程版本库里抓下更新，然后再与本地合并
也可以在git pull后边用url指定版本库地址和分支,或者直接用remote add指定的那个名字
然后做前边二到四的各种工作
最后签入远程版本库
git push name master
把本地的变化推入name指定的远程版本库的master分支
这里有个很重要的问题，远程的这个版本库不应该有自己的工作拷贝,否则那个拷贝会过期因而造成迷惑。
最好的实践，是这个远程版本库是空的，没有工作拷贝，只有版本信息(bare版本库)
这个远程版本库，可以起到同Svn中中央版本库一样的作用，只不过，你可以在本地进行频繁commit,只有都做完了，再去进行push,这个好处是不言而喻的。
至于如何建立并维护远程版本库，属于系统管理员的工作范畴，之后有空做将深入探讨
本文基本以这里的资料为参考，感兴趣可继续研究。
在ruby社区里，Git的使用占到了88%的比例，而Svn只有7.5%.......来源看这里
那么还等什么，为了不被别人耻笑，赶紧学习Git吧。
Git号称是分布式版本控制系统，这是什么？暂且不管，一起来用用看，如果你有Svn的使用基础，学起来会更快
零，介绍你自己给git
git config --global user.name "lilu"
git config --global user.email "[email protected]"
为什么呢，因为git可以使用从mail来的Patch去工作，这样作者和提交者不一定是同一人，这是细节不用了解。。。。
一，开始项目
在你的项目根目录下
git init （svnadmin create)
然后，如果要把全部文件都加入版本库,就
git add . (svn import)
但是，一般我们不会把所有文件都加入，那么以rails项目为例，可以在根目录下建立个叫.gitignore的文件，里边放如下内容
log/*.log
tmp/**/*
这样就不会加入log和tmp下的内容了,记得不要忘记修改.gitignore后也要提交这个文件
现在向版本库的提交
git commit -m "初始化项目"
-m后边跟的是注释
二，在项目里工作
用git工作,一定要小步走(当然任何版本控制系统都是如此)。
一个规则：如果你不能把你每次提交的注释缩短成一句话，说明你太久没有提交了。
检查你的文件状态
git status (svn status)
查看你的文件有什么变化
git diff (svn diff | less)
查看某版本和路径的变化
git diff rev path (svn diff -rrev path)
增加你的修改(git status里提示的)
git add file1 newfile2 newfolder3 (svn add file)
当然也可以 rm/mv 之类
最后，提交你的工作
git commit -m "xxx"
每次都git add你做过修改的文件很麻烦（svn就不用）,git有办法避免
git commit -a -m "xxx" （svn commit)
这样就自动提交做过修改的文件了，不需要git add file(当然新建文件和目录还是需要add)
看你以前都做过什么
git log (svn log | less)
加参数-nx可以看最后的x次修改
看文件的变化情况
git blame file (svn blame file)
观察整个版本库
git show rev:path/to/file (svn cat url)
git show rev:path/to/directory (svn list url)
git show rev (svn diff -crev url)
三，如何应对错误
你做了修改，但不想提交，可以把他们扔掉
git reset --hard
恢复单个文件
git checkout myfile.txt (svn revert myfile.txt)
有些文件忘了提交
git reset --soft HEAD^
然后add并commit
写错了注释
git commit --amend
可以更改上一个提交的注释，这一点比Svn强太多了！
四，稍微进阶一点的知识
版本号
git的版本号是用的16进制字串(SHA1 id)，看起来很吓人，但其实还比较好用
首先你可以用HEAD标注最新的版本，然后HEAD^就是上一级的版本，然后HEAD^^......也可以HEAD～n，就可以往前追溯n个版本
其次你不用写全那个16进制串，可以就写头几个数字，只要是独一的就能自动匹配
还有更多可研究的方法和窍门，总之使用起来不比Svn的递增数字版本号差就是了.
如何写注释
一般在社区的规则是第一行用一句话来概括修改的主要内容(不超过50个字符),然后是一个空行，最后是详细的修改原因和细节，如果有必要
空行的原因是第一行往往会成为邮件的标题，或者显示在可视化工具的列表里，比如gitk
提交时可以有多个-m，每一个都会独立成一个段落，善用这点
分支和合并
之前介绍过svn的分支与合并，见这里和这里,基本概念就不重复了
新建分支
git branch feature_x (svn copy http://example.com/svn/trunk http://example.com/svn/branches/feature_x)
查看现有分支
git branch (svn list http://example.com/svn/branches/)
feature_x
* master
带*的表示现有分支
转换分支
git checkout feature_x (svn switch http://example.com/svn/branches/feature_x)
合并分支回主干
先切回主干
git checkout master
然后合并
git merge feature_x (svn merge -r rev:HEAD http://example.com/svn/branches/feature_x)
git的merge又一次体现了比Svn的优越性，她可以保留每个分支的全部历史！还可以自动追踪已合并的分支并保证不重复
我们在svn的文里说过的选取合并(cherry-picking)也有了直接支持
git cherry-pick rev (svn merge -c rev url)
如果没有冲突，合并会自动提交
删除分支
git branch -d feature_x
标注版本(Tag)
非常简单
git tag v1.0.0 (svn copy http://example.com/svn/trunk http://example.com/svn/tags/name)
git的tag功能比Svn的简单copy强大很多，可以用-a命名，还可以有注释，权限跟踪什么的
推荐你用tag代替默认的那些每个版本的md5 id给别人看
五，分布式版本控制系统(DVCS)
相信到这里，你会有一个疑问。
没错，我们到现在为止做的一切，都在本地！
不需要上网，不需要远程服务器！
这也就是SVN和Git最大的区别，Git的版本库完全是在本地的，就连分支，也可以只属于本地
上边所讲的内容，都是只有自己一个人开发项目时所需要的
那么，如何和别人共享版本库并且互相同步对方的内容呢？请往下看
六，在远程版本库上工作
假设你为某个项目工作，此项目有git版本库的公开地址(以linux 2.6内核项目为例，汗。。。）
首先签出远程版本库
git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 (svn checkout)
clone的这个本地版本甚至包括全部历史
这个远程版本对应的默认称呼是origin
如果远程有分支的话呢？
git checkout -b branch origin/branch （svn switch url）
这样就让远程分支对应本地的一个分支了
还可以给你本地版本库增加远程分支
git remote add name url
查看远程版本库
git remote 后边可以跟show/add等等
更新的话是
git pull (svn update)
这个实际上是git fetch + git merge, 就是从远程版本库里抓下更新，然后再与本地合并
也可以在git pull后边用url指定版本库地址和分支,或者直接用remote add指定的那个名字
然后做前边二到四的各种工作
最后签入远程版本库
git push name master
把本地的变化推入name指定的远程版本库的master分支
这里有个很重要的问题，远程的这个版本库不应该有自己的工作拷贝,否则那个拷贝会过期因而造成迷惑。
最好的实践，是这个远程版本库是空的，没有工作拷贝，只有版本信息(bare版本库)
这个远程版本库，可以起到同Svn中中央版本库一样的作用，只不过，你可以在本地进行频繁commit,只有都做完了，再去进行push,这个好处是不言而喻的。
至于如何建立并维护远程版本库，属于系统管理员的工作范畴，之后有空做将深入探讨
本文基本以这里的资料为参考，感兴趣可继续研究。
相关阅读 更多 +
