Git基础-取得项目的Git仓库
有两种取得 Git 项目仓库的方法。第一种是在现存的目录下，通过导入所有文件来创建新的 Git 仓库。第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来。
1.在目录中初始化新仓库
要对现有的某个项目开始用Git管理，只需要此项目所在的目录，执行:
$ git init初始化后，在当前目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。不过目前，仅仅是按照既有的结构框架初始化好了里边所有的文件和目录，但我们还没有开始跟踪管理项目中的任何一个文件。
如果当前目录下有几个文件想要纳入版本控制，需要先用
git add 命令告诉 Git 开始对这些文件进行跟踪，然后提交：
$ git add *.c $ git add README $ git commit -m 'initial project version'
2.从现有仓库克隆
如果想对某个开源项目出一份力，可以先把该项目的 Git 仓库复制一份出来，这就需要用到
git clone 命令。如果你熟悉其他的 VCS 比如 Subversion，你可能已经注意到这里使用的是 clone 而不是
checkout。这是个非常重要的差别，Git 收取的是项目历史的所有数据（每一个文件的每一个版本），服务器上有的数据克隆之后本地也都有了。实际上，即便服务器的磁盘发生故障，用任何一个克隆出来的客户端都可以重建服务器上的仓库，回到当初克隆时的状态（虽然可能会丢失某些服务器端的挂钩设置，但所有版本的数据仍旧还在，有关细节请参考第四章）。
克隆仓库的命令格式为 git clone [url]。比如，要克隆 Ruby 语言的 Git 代码仓库 Grit，可以用下面的命令：
$ git clone https://github.com/huangjun-best/lunbo
grit的目录，其中包含一个
.git 的目录，用于保存下载下来的所有版本记录，然后从中取出最新版本的文件拷贝。如果进入这个新建的 grit 目录，你会看到项目中的所有文件已经在里边了，准备好后续的开发和使用。如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：$ git clone https://github.com/huangjun-best/lunbo turnpic唯一的差别就是，现在新建的目录成了
mygrit，其他的都和上边的一样。git:// 协议，不过你也可以用
http(s):// 或者 user@server:/path.git 表示的 SSH 传输协议。
Git基础-记录每次更新到仓库
记录每次更新到仓库信息
现在我们手上已经有了一个真实项目的 Git 仓库，并从这个仓库中取出了所有文件的工作拷贝。接下来，对这些文件作些修改，在完成了一个阶段的目标之后，提交本次更新到仓库。
请记住，工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指本来就被纳入版本控制管理的文件，在上次快照中有它们的记录，工作一段时间后，它们的状态可能是未更新，已修改或者已放入暂存区。而所有其他文件都属于未跟踪文件。它们既没有上次更新时的快照，也不在当前的暂存区域。初次克隆某个仓库时，工作目录中的所有文件都属于已跟踪文件，且状态为未修改。
在编辑过某些文件之后，Git 将这些文件标为已修改。我们逐步把这些修改过的文件放到暂存区域，直到最后一次性提交所有这些暂存起来的文件，如此重复。所以使用 Git 时的文件状态变化周期如图 所示。
$ git status On branch master nothing to commit, working directory clean跟踪新文件
使用命令 git add 开始跟踪一个新文件。所以，要跟踪 README 文件，运行：
$ git add README
$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README.txt
git add 的潜台词就是把目标文件快照放入暂存区域，也就是 add file into staged area，同时未曾跟踪过的文件标记为需要跟踪。这样就好理解后续 add 操作的实际意义了。需要注意的是每次更改或者新增文件在git add前后使用git status状态是不一样的）
忽略某些文件
一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。我们可以创建一个名为.gitignore的文件，列出要忽略的文件模式。来看一个实际的例子：(当然如果在windows当中无法新建这个文件，可以在git shell中使用 touch .gitignore新建这个文件，然后使用vi .gitignore编辑)
$ cat .gitignore *.[la] *~第一行告诉 Git 忽略所有以
.o 或 .a 结尾的文件。一般这类对象文件和存档文件都是编译过程中出现的，我们用不着跟踪它们的版本。第二行告诉 Git 忽略所有以波浪符（~）结尾的文件，许多文本编辑软件（比如 Emacs）都用这样的文件名保存副本。此外，你可能还需要忽略
log，tmp 或者 pid 目录，以及自动生成的文档等等。要养成一开始就设置好
.gitignore 文件的习惯，以免将来误提交这类无用的文件。
文件 .gitignore 的格式规范如下：
＃ 开头的行都会被 Git 忽略。/）说明要忽略的是目录。!）取反。要查看尚未暂存的文件更新了哪些部分，不加参数直接输入
git diff：
若要看已经暂存起来的文件和上次提交时的快照之间的差异，可以用
git diff --cached 命令。（Git 1.6.1 及更高版本还允许使用 git diff --staged，效果是相同的，但更好记些。
提交更新
现在的暂存区域已经准备妥当可以提交了。在此之前，请一定要确认还有什么修改过的或新建的文件还没有
git add 过，否则提交的时候不会记录这些还没暂存起来的变化。所以，每次准备提交前，先用 git status 看下，是不是都已暂存起来了，然后再运行提交命令
git commit：
$ git commit这种方式会启动文本编辑器以便输入本次提交的说明。（默认会启用 shell 的环境变量
$EDITOR 所指定的软件，一般都是 vim 或 emacs。当然也可以按照之前介绍的方式，使用
git config --global core.editor 命令设定你喜欢的编辑软件。）
可以看到，默认的提交消息包含最后一次运行 git status 的输出，放在注释行里，另外开头还有一空行，供你输入提交说明。你完全可以去掉这些注释行，不过留着也没关系，多少能帮你回想起这次更新的内容有哪些。（如果觉得这还不够，可以用
-v 选项将修改差异的每一行都包含到注释中来。）退出编辑器时，Git 会丢掉注释行，将说明内容和本次更新提交到仓库。
另外也可以用 -m 参数后跟提交说明的方式，在一行命令中提交更新：
$ git commit -m '0.0.1 demo' [master 42070f1] 0.0.1 demo 3 files changed, 3 insertions(+) create mode 100644 .gitignore create mode 100644 README.txt create mode 100644 log.txt跳过使用暂存区域
git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过
git add 步骤：移除文件
要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。可以用
git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 “Changes not staged for commit” 部分（也就是未暂存清单）看到：
最后提交的时候，该文件就不再纳入版本管理了。如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项
-f（译注：即 force 的首字母），以防误删除文件后丢失修改的内容。
另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。比如一些大型日志文件或者一堆
.a 编译文件，不小心纳入仓库后，要移除跟踪但不删除文件，以便稍后在 .gitignore 文件中补上，用
--cached 选项即可：
$ git rm --cached readme.txt后面可以列出文件或者目录的名字，也可以使用 glob 模式。比方说：
$ git rm log/\*.log移动文件
mv 命令时一定会困惑不已。要在 Git 中对文件改名，可以这么做：$ git mv file_from file_to其实，运行
git mv 就相当于运行了下面三条命令：
$ mv README.txt README $ git rm README.txt $ git add README查看提交历史
git log 命令查看。
git log 有许多选项可以帮助你搜寻感兴趣的提交，接下来我们介绍些最常用的。
我们常用 -p 选项展开显示每次提交的内容差异，用
-2 则仅显示最近的两次更新：
git log 还提供了许多摘要选项可以用，比如
--stat，仅显示简要的增改行数统计：format，可以定制要显示的记录格式，这样的输出便于后期编程提取分析，像这样：
限制输出长度
另外还有按照时间作限制的选项，比如
--since 和 --until。下面的命令列出所有最近两周内的提交：
$ git log --since=2.weeks还可以给出若干搜索条件，列出符合的提交。用
--author 选项显示指定作者的提交，用 --grep 选项搜索提交说明中的关键字。（请注意，如果要得到同时满足这两个选项搜索条件的提交，就必须用
--all-match 选项。否则，满足任意一个条件的提交都会被匹配出来）
有时候图形化工具更容易展示历史提交的变化，随 Git 一同发布的 gitk 就是这样一种工具。它是用 Tcl/Tk 写成的，基本上相当于
git log 命令的可视化版本，凡是 git log 可以用的选项也都能用在 gitk 上。在项目工作目录中输入 gitk 命令后
Git基础-撤销操作
修改最后一次提交
有时候我们提交完了才发现漏掉了几个文件没有加，或者提交信息写错了。想要撤消刚才的提交操作，可以使用
--amend 选项重新提交：
$ git commit --amend
此命令将使用当前的暂存区域快照提交。如果刚才提交完没有作任何改动，直接运行此命令的话，相当于有机会重新编辑提交说明，但将要提交的文件快照和之前的一样。
启动文本编辑器后，会看到上次提交时的说明，编辑它确认没问题后保存退出，就会使用新的提交说明覆盖刚才失误的提交。
如果刚才提交时忘了暂存某些修改，可以先补上暂存操作，然后再运行 --amend 提交：
$ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend取消已经暂存的文件
查看文件状态的时候就提示了该如何撤消，所以不需要死记硬背。来看下面的例子，有两个修改过的文件，我们想要分开提交，但不小心用
git add . 全加到了暂存区域。该如何撤消暂存其中的一个文件呢？其实，git status 的命令输出已经告诉了我们该怎么做：就在 “Changes to be committed” 下面，括号中有提示，可以使用
git reset HEAD <file>... 的方式取消暂存。好吧，我们来试试取消暂存 benchmarks.rb 文件：
$ git reset HEAD benchmarks.rb取消对文件的修改
git status 同样提示了具体的撤消方法，接着上面的例子，现在未暂存区域看起来像这样：
$ git checkout -- benchmarks.rb
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README.txt
要查看当前配置有哪些远程仓库，可以用 git remote 命令，它会列出每个远程库的简短名字。在克隆完某个项目后，至少可以看到一个名为 origin 的远程库，Git 默认使用这个名字来标识你所克隆的原始仓库：
$ git remote origin也可以加上
-v 选项（译注：此为 --verbose 的简写，取首字母），显示对应的克隆地址：
$ git remote -v origin http://github.com/huangjun-best/lunbo (fetch) origin http://github.com/huangjun-best/lunbo (push)添加远程仓库
要添加一个新的远程仓库，可以指定一个简单的名字，以便将来引用，运行 git remote add [shortname] [url]：
$ git remote add pb http://github.com/huangjun-best/lunbo huangjun_best@IDEA-PC /d/wamp/www/gitproject/lunbo (master) $ git remote -v origin http://github.com/huangjun-best/lunbo (fetch) origin http://github.com/huangjun-best/lunbo (push) pb http://github.com/huangjun-best/lunbo (fetch) pb http://github.com/huangjun-best/lunbo (push)现在可以用字符串
pb 指代对应的仓库地址了。比如说，要抓取所有 Paul 有的，但本地仓库没有的信息，可以运行
git fetch pb：正如之前所看到的，可以用下面的命令从远程仓库抓取数据到本地：
$ git fetch [remote-name]如果是克隆了一个仓库，此命令会自动将远程仓库归于 origin 名下。所以，
git fetch origin 会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新（或是上次 fetch 以来别人提交的更新）。有一点很重要，需要记住，fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并。
如果设置了某个分支用于跟踪某个远端仓库的分支，可以使用 git pull 命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支。在日常工作中我们经常这么用，既快且好。实际上，默认情况下
git clone 命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master 分支（假设远程仓库确实有 master 分支）。所以一般我们运行
git pull，目的都是要从原始克隆的远端仓库中抓取数据后，合并到工作目录中的当前分支。
git push [remote-name] [branch-name]。如果要把本地的 master 分支推送到 origin 服务器上（再次说明下，克隆操作会自动使用默认的 master 和 origin 名字），可以运行下面的命令：
$ git push origin master只有在所克隆的服务器上有写权限，或者同一时刻没有其他人在推数据，这条命令才会如期完成任务。如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，合并到自己的项目中，然后才可以再次推送。
查看远程仓库信息
我们可以通过命令 git remote show [remote-name] 查看某个远程仓库的详细信息，比如要看所克隆的
origin 仓库，可以运行：
$ git remote show origin远程仓库的删除和重命名
在新版 Git 中可以用 git remote rename 命令修改某个远程仓库在本地的简称，比如想把
pb 改成 paul，可以这么运行：
$ git remote rename pb paul碰到远端仓库服务器迁移，或者原来的克隆镜像不再使用，又或者某个参与者不再贡献代码，那么需要移除对应的远端仓库，可以运行
git remote rm 命令：
$ git remote rm paul
列出已有的标签
列出现有标签的命令非常简单，直接运行 git tag 即可：
$ git tag新建标签
Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。一般我们都建议使用含附注型的标签，以便保留相关信息；当然，如果只是临时性加注标签，或者不需要旁注额外信息，用轻量级标签也没问题。
含附注的标签
创建一个含附注类型的标签非常简单，用 -a （译注：取 annotated 的首字母）指定标签名字即可：
$ git tag -a v1.4 -m 'my version 1.4'而
-m 选项则指定了对应的标签说明，Git 会将此说明一同保存在标签对象中。如果没有给出该选项，Git 会启动文本编辑软件供你输入标签说明。
可以使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。
签署标签
如果你有自己的私钥，还可以用 GPG 来签署标签，只需要把之前的 -a 改为
-s （译注： 取 signed 的首字母）即可：
轻量级标签
轻量级标签实际上就是一个保存着对应提交对象的校验和信息的文件。要创建这样的标签，一个
-a，-s 或 -m 选项都不用，直接给出标签名字即可：
$ git tag v1.4-lw验证标签
可以使用 git tag -v [tag-name] （译注：取
verify 的首字母）的方式验证已经签署的标签。此命令会调用 GPG 来验证签名，所以你需要有签署者的公钥，存放在 keyring 中，才能验证：
若是没有签署者的公钥，会报告类似下面这样的错误：
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A gpg: Can't check signature: public key not found error: could not verify the tag 'v1.4.2.1'后期加标注
$ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c3261057305bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme我们忘了在提交 “updated rakefile” 后为此项目打上版本号 v1.2，没关系，现在也能做。只要在打标签的时候跟上对应提交对象的校验和（或前几位字符）即可：
$ git tag -a v1.2 9fceb02分享标注
默认情况下，git push 并不会把标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。其命令格式如同推送分支，运行
git push origin [tagname] 即可：
$ git push origin v1.5--tags 选项：
$ git push origin --tags原文地址：http://blog.csdn.net/huangjun_best/article/details/42457637
