0f4505c1e2
converted tabs to spaces also. but these commits is limited in the zh version. the reason I did this: - long lines is prone to conflict - the use of tab disturbs the indentation when switching editors without proper tab space setting, which you may never get it right. so why not give up and use spaces instead. those changes is limited to the zh translation. Merge remote-tracking branch 'upstream/gh-pages' into gh-pages Conflicts: .gitignore _layouts/zh_reference.html zh/basic/index.html zh/branching/index.html zh/creating/index.html zh/index.html zh/inspect/index.html zh/remotes/index.html
83 lines
3.7 KiB
HTML
83 lines
3.7 KiB
HTML
---
|
||
layout: zh_reference
|
||
---
|
||
<div class="box">
|
||
<h2>Git 手册简介</h2>
|
||
<div class="block">
|
||
<p>
|
||
本站为 Git 参考手册。目的是为学习与记忆 Git 使用中最重要、最普遍的命令提供快速翻阅。
|
||
这些命令以你可能需要的操作类型划分，并且将提供日常使用中需要的一些常用的命令以及参数。
|
||
</p>
|
||
<p>
|
||
每个章节都有到下一个章节的链接，所以本手册也可以当作一个入门指导。
|
||
每个页面还有一个深度 Git 文档阅读的链接，比如官方的使用手册页面或者 <a href="http://progit.org">《Pro Git》</a>
|
||
书中的相关章节，以便于你学习了解更多的 Git 命令。首先，我们要从如何以 Git 的思维方式管理源代码开始。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="box">
|
||
<h2>如何以 Git 的方式思考</h2>
|
||
<div class="block">
|
||
<p>
|
||
懂得 Git，第一件重要的事情就是要知道它与 Subversion、Perforce 或者任何你用过的版本控制工具都有着很大的差别。
|
||
通常，忘掉你预想的版本控制方式，改以 Git 的方式思考，能够帮助你更好地学习 Git。
|
||
</p>
|
||
|
||
<p>
|
||
让我们从头开始。假设你正在设计一个新的源代码管理系统。在你使用某个工具之前，是如何完成基本的源码版本控制工作的呢？
|
||
十有八九，你只是在项目到达某些阶段的时候，对项目做一份拷贝。
|
||
</p>
|
||
|
||
<pre> $ cp -R project project.bak </pre>
|
||
|
||
<p>
|
||
这样，你就可以在事情变得一团糟的时候很方便的返回到之前的状态，或者通过对比当前的项目与之前的拷贝，看看自己在之后的工作中，都做了哪些修改。
|
||
</p>
|
||
|
||
<p>
|
||
如果你有点偏执，你可能会经常作上面说的事情，或许还会给项目拷贝加个日期：
|
||
</p>
|
||
|
||
<pre> $ cp -R project project.2010-06-01.bak </pre>
|
||
|
||
<p>
|
||
如此，你就有了一堆项目在各个阶段的快照，来作比较、查看。使用这种模式，你还可以有效地与人分享项目变更。
|
||
如果你会在项目到达一定阶段的时候给它打个包，丢到自己的网站上，那其他的开发者们，就能很方便地下载它，做点改动，并给你补丁回馈。
|
||
</p>
|
||
|
||
<pre>
|
||
$ wget http://sample.com/project.2010-06-01.zip
|
||
$ unzip project.2010-06-01.zip
|
||
$ cp -R project.2010-06-01 project-my-copy
|
||
$ cd project-my-copy
|
||
$ (做了某些修改)
|
||
$ diff project-my-copy project.2010-06-01 > change.patch
|
||
$ (通过E-mail发送修改补丁)</pre>
|
||
|
||
<p>
|
||
以此方式，原先的开发者就能将其他人的改动应用到他的项目中去，其他开发者也能了解你做的变更。其实这便是许多开源项目采用过多年的协作方式。
|
||
</p>
|
||
|
||
<p>
|
||
这办法其实很好使，所以假设我们现在想要写个工具，让这个办法更快、更简单。
|
||
我们与其实现一个工具以记录每个文件的版本，可能不如去实现个工具以使创建、储存项目的快照更加方便，不用每次都去人肉作整个项目的拷贝。
|
||
</p>
|
||
|
||
<p>
|
||
这就是 Git 的精要所在。你通过 <code>git commit</code>告诉 Git 你想保存一份项目快照，
|
||
Git 就会为你的项目中的各个文件的当前状态存一份记录。之后，绝大部分的 Git 命令都围绕这些记录展开。
|
||
比如查看它们的区别（diff），提取它们的内容，等等。
|
||
</p>
|
||
|
||
<center><img src="./images/snapshots.png"/></center>
|
||
|
||
<p>
|
||
如果你将 Git 看作一个排序、对比以及合并项目更新的工具，那就容易理解状况和正确做事了。
|
||
</p>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<p><a href="/zh/creating">接下来：获取与创建项目»</a></p>
|