【git】git常用操作
1、 获取帮助
有这三种方法
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
2、 取得项目的git仓库
-
初始化一个新仓库
git init
用Xcode的同学就不要勾选Xcode自带的git了。//TODO:如果勾选了会怎样，测试一下
* 克隆一个仓库
```
git clone [url]
(不像其他CVS的`checkout`)如克隆Ruby语言的git代码仓库Grit:
```
$ git clone git://github.com/schacon/grit.git
这会在当前目录下创建一个名为`grit`的目录，其中包含一个 `.git `的目录，用于保存下载下来的所有版本记录，然后从中取出最新版本的文件拷贝。如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：
```
$ git clone git://github.com/schacon/grit.git mygrit
3、 记录每次更新到仓库
请记住，工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指本来就被纳入版本控制管理的文件，在上次快照中有它们的记录，工作一段时间后，它们的状态可能是未更新，已修改或者已放入暂存区。剩下的属于未跟踪文件。它们既没有上次更新时的快照，也不在当前的暂存区域。初始化一个新仓库时，每个新建的文件自然都属于未跟踪。初次克隆某个仓库时，工作目录中的所有文件都属于已跟踪文件，且状态为未修改。在编辑过某些文件之后，Git 将这些文件标为已修改。我们逐步把这些修改过的文件放到暂存区域，直到最后一次性提交所有这些暂存起来的文件，如此重复。所以使用 Git 时的文件状态变化周期如图所示。
文件状态生命周期
图中，灰色箭头属于未跟踪状态，红色箭头属于已跟踪状态，这是文件的两大状态。
-
检查当前文件状态
git status
* 跟踪新文件
```
git add
在git add 后面可以指明要跟踪的文件或目录路径。
-
暂存已修改文件
git add
`git add`是个多功能命令，根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等
* 查看已暂存和未暂存的更新
`git status`列出修改过的文件,`git diff`查看具体修改了什么地方.若要看已经暂存起来的文件和上次提交时的快照之间的差异，可以用 `git diff --cached `命令.（Git 1.6.1 及更高版本还允许使用 `git diff --staged`，效果是相同的，但更好记些。）请注意，单单 `git diff `不过是显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异。所以有时候你一下子暂存了所有更新过的文件后，运行 `git diff` 后却什么也没有，就是这个原因。
* 提交更新
```
git commit -m "提交说明"
-
跳过使用暂存区域
尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。Git 提供了一个跳过使用暂存区域的方式，只要在提交的时候，给git commit加上-a选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过git add步骤：
git commit -a -m "提交说明"
* 移除文件
* 从git仓库和工作目录中移除
```
git rm
如果只是简单地从工作目录中手工删除文件，那么运行 git status 时就会在 “Changes not staged for commit” 部分（也就是未暂存清单）看到此次删除事件，这说明我们需要把此次删除事件记录到git中，运行 git rm记录此次移除文件的操作即可。如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f（译注：即 force 的首字母），以防误删除文件后丢失修改的内容。
* 仅从git仓库中移除
用 --cached 选项即可：
```
git rm --cached 文件名
或者目录名，如：
```
$ git rm log/\*.log
上面使用了glob模式，注意到星号 `*` 之前的反斜杠 `\`，因为 Git 有它自己的文件模式扩展匹配方式，所以我们不用 shell 来帮忙展开（译注：实际上不加反斜杠也可以运行，只不过按照 shell 扩展的话，仅仅删除指定目录下的文件而不会递归匹配。上面的例子本来就指定了目录，所以效果等同，但下面的例子就会用递归方式匹配，所以必须加反斜杠。）。此命令删除所有 `log/ `目录下扩展名为 `.log `的文件。类似的比如：
```
$ git rm *~
会递归删除当前目录及其子目录中所有 ~ 结尾的文件。
* 移动文件
`不像其他的 VCS 系统，Git 并不跟踪文件移动操作。`奇特的是，重命名需要用`mv`操作，要在 Git 中对文件改名，可以这么做：
```
$ git mv file_from file_to
它会恰如预期般正常工作。实际上，即便此时查看状态信息，也会明白无误地看到关于重命名操作的说明：
```
$ git mv README.txt README
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.txt -> README
其实，运行 git mv 就相当于运行了下面三条命令：
```
$ mv README.txt README
$ git rm README.txt
$ git add README
4、 查看提交历史
git log
学习具体参数的用法，参见
5、 分支
创建分支
$ git branch testing
切换分支
$ git checkout testing
创建并切换分支
$ git checkout -b iss53
相当于
$ git branch iss53
$ git checkout iss53
合并分支
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
README | 1 -
1 file changed, 1 deletion(-)
删除分支
$ git branch -d hotfix
Deleted branch hotfix (was 3a0874c).
更多分支的内容,参见
6、 撤销操作
-
修改最后一次提交信息
git commit --amend
运行此命令，会进入文本编辑状态，编辑上一次的提交信息。 如：如果刚才提交时忘了暂存某些修改，可以先补上暂存操作，然后再运行 `--amend` 提交：
```
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
上面的三条命令最终只是产生一个提交，第二个提交命令修正了第一个的提交内容。
-
取消已经暂存的文件(将其从staged状态变为modified状态)
git reset HEAD <file>...
* 抛弃文件修改（将其还原到上一个版本）
```
git checkout -- <file>...
在用这条命令前，请务必确定真的不再需要保留刚才的修改。如果只是想回退版本，同时保留刚才的修改以便将来继续工作，可以用 stashing 和分支来处理，应该会更好些。
回退到某个版本
git reset --hard 02c4b5b310d638c4d1e14f758aa56afdd4c49322
7、 远程仓库的使用
-
查看当前的远程库
git remote
用`git remote -v`可以显示对应的克隆地址，其中v是verbose的缩写。
* 添加远程库
```
git remote add [shortname] [url]
-
从远程仓库抓取数据
$ git fetch [remote-name]
如果设置了某个分支用于跟踪某个远端仓库的分支，可以使用 `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
* remote origin
URL: git://github.com/schacon/ticgit.git
Remote branch merged with 'git pull' while on branch master
master
Tracked remote branches
master
ticgit
除了对应的克隆地址外，它还给出了许多额外的信息。它友善地告诉你如果是在 `master` 分支，就可以用 `git pull `命令抓取数据合并到本地。另外还列出了所有处于跟踪状态中的远端分支。
* 远程仓库的删除和重命名
在新版 Git 中可以用 `git remote rename `命令修改某个远程仓库在本地的简称，比如想把 `pb` 改成 `paul`，可以这么运行：
```
$ git remote rename pb paul
$ git remote
origin
paul
注意，对远程仓库的重命名，也会使对应的分支名称发生变化，原来的 `pb/master` 分支现在成了 `paul/master`。
碰到远端仓库服务器迁移，或者原来的克隆镜像不再使用，又或者某个参与者不再贡献代码，那么需要移除对应的远端仓库，可以运行 `git remote rm `命令
```
$ git remote rm paul
$ git remote
origin
####8、 打标签
Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。一般我们都建议使用含附注型的标签，以便保留相关信息；当然，如果只是临时性加注标签，或者不需要旁注额外信息，用轻量级标签也没问题。
* 列出已有标签
列出现有标签的命令非常简单，直接运行 git tag 即可：
$ git tag
v0.1
v1.3
我们可以用特定的搜索模式列出符合条件的标签。在 Git 自身项目仓库中，有着超过 240 个标签，如果你只对 1.4.2 系列的版本感兴趣，可以运行下面的命令：
$ git tag -l 'v1.4.2.*'
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4
* 含附注的标签
创建一个含附注类型的标签非常简单，用 `-a `（译注：取 `annotated` 的首字母）指定标签名字即可：
```
$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
v0.1
v1.3
v1.4
而 -m 选项则指定了对应的标签说明，Git 会将此说明一同保存在标签对象中。如果没有给出该选项，Git 会启动文本编辑软件供你输入标签说明。
可以使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。
```
$ git show v1.4
tag v1.4
Tagger: Scott Chacon schacon@gee-mail.com
Date: Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon schacon@gee-mail.com
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
* 签署标签
如果你有自己的私钥，还可以用 GPG 来签署标签，只需要把之前的 `-a` 改为 `-s` （译注： 取 `signed` 的首字母）即可：
```
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gee-mail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
-
轻量级标签
轻量级标签实际上就是一个保存着对应提交对象的校验和信息的文件。要创建这样的标签，一个-a，-s或-m选项都不用，直接给出标签名字即可：
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
* 验证标签
可以使用 git tag -v [tag-name] （译注：取 verify 的首字母）的方式验证已经签署的标签。此命令会调用 GPG 来验证签名，所以你需要有签署者的公钥，存放在 keyring 中，才能验证：
```
git tag -v v1.4.2.1
object 883653babd8ee7ea23e6a5c392bb739348b1eb61
type commit
tag v1.4.2.1
tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700
GIT 1.4.2.1
Minor fixes since 1.4.2, including git-mv and git-http with alternates.
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Good signature from "Junio C Hamano <junkio@cox.net>"
gpg: aka "[jpeg image of size 1513]"
Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
-
后期加注标签
你甚至可以在后期对早先的某次提交加注标签。比如在下面展示的提交历史中：
$ 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
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
- [new tag] v1.5 -> v1.5
如果要一次推送所有本地新增的标签上去，可以使用 `--tags `选项：
```
$ git push origin --tags
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
* [new tag] v0.1 -> v0.1
* [new tag] v1.2 -> v1.2
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw
* [new tag] v1.5 -> v1.5
