用Git撤销任何操作
任何版本控制系统的一个最有的用特性就是“撤销 (undo)”你的错误操作的能力。在 Git 里，“撤销” 蕴含了不少略有差别的功能。
当你进行一次新的提交的时候，Git 会保存你代码库在那个特定时间点的快照；之后，你可以利用 Git 返回到你的项目的一个早期版本。
在本篇博文里，我会讲解某些你需要“撤销”已做出的修改的常见场景，以及利用 Git 进行这些操作的最佳方法。
撤销一个“已公开”的改变
场景: 你已经执行了 git push, 把你的修改发送到了 GitHub，现在你意识到这些 commit 的其中一个是有问题的，你需要撤销那一个 commit.
方法: git revert <SHA>
原理: git revert 会产生一个新的 commit，它和指定 SHA 对应的 commit 是相反的（或者说是反转的）。如果原先的 commit 是“物质”，新的 commit 就是“反物质” — 任何从原先的 commit 里删除的内容会在新的 commit 里被加回去，任何在原先的 commit 里加入的内容会在新的 commit 里被删除。
这是 Git 最安全、最基本的撤销场景，因为它并不会改变历史 — 所以你现在可以 git push 新的“反转” commit 来抵消你错误提交的 commit。
修正最后一个 commit 消息
场景: 你在最后一条 commit 消息里有个笔误，已经执行了 git commit -m "Fxies bug #42"，但在 git push 之前你意识到消息应该是 “Fixes bug #42″。
方法: git commit --amend 或 git commit --amend -m "Fixes bug #42"
原理: git commit --amend 会用一个新的 commit 更新并替换最近的 commit ，这个新的 commit 会把任何修改内容和上一个 commit 的内容结合起来。如果当前没有提出任何修改，这个操作就只会把上次的 commit 消息重写一遍。
撤销“本地的”修改
场景: 一只猫从键盘上走过，无意中保存了修改，然后破坏了编辑器。不过，你还没有 commit 这些修改。你想要恢复被修改文件里的所有内容 — 就像上次 commit 的时候一模一样。
方法: git checkout -- <bad filename>
原理: git checkout 会把工作目录里的文件修改到 Git 之前记录的某个状态。你可以提供一个你想返回的分支名或特定 SHA ，或者在缺省情况下，Git 会认为你希望 checkout 的是 HEAD，当前 checkout 分支的最后一次 commit。
记住：你用这种方法“撤销”的任何修改真的会完全消失。因为它们从来没有被提交过，所以之后 Git 也无法帮助我们恢复它们。你要确保自己了解你在这个操作里扔掉的东西是什么！（也许可以先利用 git diff 确认一下）
重置“本地的”修改
场景: 你在本地提交了一些东西（还没有 push），但是所有这些东西都很糟糕，你希望撤销前面的三次提交 — 就像它们从来没有发生过一样。
方法: git reset <last good SHA> 或 git reset --hard <last good SHA>
原理: git reset 会把你的代码库历史返回到指定的 SHA 状态。 这样就像是这些提交从来没有发生过。缺省情况下， git reset 会保留工作目录。这样，提交是没有了，但是修改内容还在磁盘上。这是一种安全的选择，但通常我们会希望一步就“撤销”提交以及修改内容 — 这就是 --hard 选项的功能。
在撤销“本地修改”之后再恢复
场景: 你提交了几个 commit，然后用 git reset --hard 撤销了这些修改（见上一段），接着你又意识到：你希望还原这些修改！
方法: git reflog 和 git reset 或 git checkout
原理: git reflog 对于恢复项目历史是一个超棒的资源。你可以恢复几乎 任何东西 — 任何你 commit 过的东西 — 只要通过 reflog。
你可能已经熟悉了 git log 命令，它会显示 commit 的列表。 git reflog 也是类似的，不过它显示的是一个 HEAD 发生改变的时间列表.
一些注意事项：
它涉及的只是 HEAD的改变。在你切换分支、用git commit进行提交、以及用git reset撤销 commit 时，HEAD会改变，但当你用git checkout -- <bad filename>撤销时（正如我们在前面讲到的情况），HEAD 并不会改变 — 如前所述，这些修改从来没有被提交过，因此 reflog 也无法帮助我们恢复它们。git reflog不会永远保持。Git 会定期清理那些 “用不到的” 对象。不要指望几个月前的提交还一直躺在那里。- 你的
reflog就是你的，只是你的。你不能用git reflog来恢复另一个开发者没有 push 过的 commit。
那么…你怎么利用 reflog 来“恢复”之前“撤销”的 commit 呢？它取决于你想做到的到底是什么：
- 如果你希望准确地恢复项目的历史到某个时间点，用
git reset --hard <SHA> - 如果你希望重建工作目录里的一个或多个文件，让它们恢复到某个时间点的状态，用
git checkout <SHA> -- <filename> - 如果你希望把这些 commit 里的某一个重新提交到你的代码库里，用
git cherry-pick <SHA>
利用分支的另一种做法
场景: 你进行了一些提交，然后意识到你开始 check out 的是 master 分支。你希望这些提交进到另一个特性（feature）分支里。
方法: git branch feature, git reset --hard origin/master, and git checkout feature
原理: 你可能习惯了用 git checkout -b <name> 创建新的分支 — 这是创建新分支并马上 check out 的流行捷径 — 但是你不希望马上切换分支。这里， git branch feature 创建一个叫做 feature 的新分支并指向你最近的 commit，但还是让你 check out 在 master 分支上。
下一步，在提交任何新的 commit 之前，用 git reset --hard 把 master 分支倒回 origin/master 。不过别担心，那些 commit 还在 feature 分支里。
最后，用 git checkout 切换到新的 feature 分支，并且让你最近所有的工作成果都完好无损。
及时分支，省去繁琐
场景: 你在 master 分支的基础上创建了 feature 分支，但 master 分支已经滞后于 origin/master 很多。现在 master 分支已经和 origin/master 同步，你希望在 feature 上的提交是从现在开始，而不是也从滞后很多的地方开始。
方法: git checkout feature 和 git rebase master
原理: 要达到这个效果，你本来可以通过 git reset (不加 --hard, 这样可以在磁盘上保留修改) 和 git checkout -b <new branch name> 然后再重新提交修改，不过这样做的话，你就会失去提交历史。我们有更好的办法。
git rebase master 会做如下的事情：
- 首先它会找到你当前 check out 的分支和
master 分支的共同祖先。 - 然后它 reset 当前 check out 的分支到那个共同祖先，在一个临时保存区存放所有之前的提交。
- 然后它把当前 check out 的分支提到
master的末尾部分，并从临时保存区重新把存放的 commit 提交到master分支的最后一个 commit 之后。
大量的撤销/恢复
场景: 你向某个方向开始实现一个特性，但是半路你意识到另一个方案更好。你已经进行了十几次提交，但你现在只需要其中的一部分。你希望其他不需要的提交统统消失。
方法: git rebase -i <earlier SHA>
原理: -i 参数让 rebase 进入“交互模式”。它开始类似于前面讨论的 rebase，但在重新进行任何提交之前，它会暂停下来并允许你详细地修改每个提交。
rebase -i 会打开你的缺省文本编辑器，里面列出候选的提交。如下所示：
前面两列是键：第一个是选定的命令，对应第二列里的 SHA 确定的 commit。缺省情况下， rebase -i 假定每个 commit 都要通过 pick 命令被运用。
要丢弃一个 commit，只要在编辑器里删除那一行就行了。如果你不再需要项目里的那几个错误的提交，你可以删除上例中的1、3、4行。
如果你需要保留 commit 的内容，而是对 commit 消息进行编辑，你可以使用 reword 命令。 把第一列里的 pick 替换为 reword (或者直接用 r)。有人会觉得在这里直接重写 commit 消息就行了，但是这样不管用 —rebase -i 会忽略 SHA 列前面的任何东西。它后面的文本只是用来帮助我们记住 0835fe2 是干啥的。当你完成 rebase -i 的操作之后，你会被提示输入需要编写的任何 commit 消息。
如果你需要把两个 commit 合并到一起，你可以使用 squash 或 fixup 命令，如下所示：
squash 和 fixup 会“向上”合并 — 带有这两个命令的 commit 会被合并到它的前一个 commit 里。在这个例子里， 0835fe2 和 6943e85 会被合并成一个 commit， 38f5e4e 和 af67f82 会被合并成另一个。
如果你选择了 squash， Git 会提示我们给新合并的 commit 一个新的 commit 消息； fixup 则会把合并清单里第一个 commit 的消息直接给新合并的 commit 。 这里，你知道 af67f82 是一个“完了完了….” 的 commit，所以你会留着 38f5e4e as的 commit 消息，但你会给合并了 0835fe2 和 6943e85 的新 commit 编写一个新的消息。
在你保存并退出编辑器的时候，Git 会按从顶部到底部的顺序运用你的 commit。你可以通过在保存前修改 commit 顺序来改变运用的顺序。如果你愿意，你也可以通过如下安排把 af67f82 和 0835fe2 合并到一起：
修复更早期的 commit
场景: 你在一个更早期的 commit 里忘记了加入一个文件，如果更早的 commit 能包含这个忘记的文件就太棒了。你还没有 push，但这个 commit 不是最近的，所以你没法用 commit --amend.
方法: git commit --squash <SHA of the earlier commit> 和 git rebase --autosquash -i <even earlier SHA>
原理: git commit --squash 会创建一个新的 commit ，它带有一个 commit 消息，类似于 squash! Earlier commit。 (你也可以手工创建一个带有类似 commit 消息的 commit，但是 commit --squash 可以帮你省下输入的工作。)
如果你不想被提示为新合并的 commit 输入一条新的 commit 消息，你也可以利用 git commit --fixup 。在这个情况下，你很可能会用commit --fixup ，因为你只是希望在 rebase 的时候使用早期 commit 的 commit 消息。
rebase --autosquash -i 会激活一个交互式的 rebase 编辑器，但是编辑器打开的时候，在 commit 清单里任何 squash! 和 fixup! 的 commit 都已经配对到目标 commit 上了，如下所示：
在使用 --squash 和 --fixup 的时候，你可能不记得想要修正的 commit 的 SHA 了— 只记得它是前面第 1 个或第 5 个 commit。你会发现 Git 的 ^ 和 ~ 操作符特别好用。HEAD^ 是 HEAD 的前一个 commit。 HEAD~4 是 HEAD 往前第 4 个 – 或者一起算，倒数第 5 个 commit。
停止追踪一个文件
场景: 你偶然把 application.log 加到代码库里了，现在每次你运行应用，Git 都会报告在 application.log 里有未提交的修改。你把 *.login 放到了 .gitignore 文件里，可文件还是在代码库里 — 你怎么才能告诉 Git “撤销” 对这个文件的追踪呢？
方法: git rm --cached application.log
原理: 虽然 .gitignore 会阻止 Git 追踪文件的修改，甚至不关注文件是否存在，但这只是针对那些以前从来没有追踪过的文件。一旦有个文件被加入并提交了，Git 就会持续关注该文件的改变。类似地，如果你利用 git add -f 来强制或覆盖了 .gitignore， Git 还会持续追踪改变的情况。之后你就不必用-f 来添加这个文件了。
如果你希望从 Git 的追踪对象中删除那个本应忽略的文件， git rm --cached 会从追踪对象中删除它，但让文件在磁盘上保持原封不动。因为现在它已经被忽略了，你在 git status 里就不会再看见这个文件，也不会再偶然提交该文件的修改了。
这就是如何在 Git 里撤销任何操作的方法。要了解更多关于本文中用到的 Git 命令，请查看下面的有关文档：
Win7上Git安装及配置过程
Win7上Git安装及配置过程
| 文档名称 | Win7上Git安装及配置过程 |
| 创建时间 | 2012/8/20 |
| 修改时间 | 2012/8/20 |
| 创建人 | Baifx |
| 简介（收获） | 1、在win7上安装msysgit步骤；
2、在win7上安装TortoiseGit步骤； 3、在VS2010中集成Git方法和步骤(未)。 |
| 参考源 | Git的配置与使用
http://wenku.baidu.com/view/929d7b4e2e3f5727a5e962a8.html |
一、安装说明
1、Git在windows平台上安装说明。
Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。目前Git已经可以在windows下使用，主要方法有二：msysgit和Cygwin。Cygwin和Linux使用方法类似，Windows版本的Git提供了友好的GUI(图形界面)，安装后很快可以上手，此处我们主要讨论基于msysgit的Git安装和使用。
TortoiseGit是TortoiseSVN的Git版本，TortoiseGit用于迁移TortoiseSVN到TortoiseGit。一直以来Git在Windows平台没有好用GUI客户端，现在TortoiseGit的出现给Windows开发者带来福音。我们将在64位win7操作系统上安装Git，并使用GUI界面，则需同时安装msysGit和TortoiseGit。
2、阅读TortoiseGit官方安装说明：
http://code.google.com/p/tortoisegit/wiki/SetupHowTo
- For the latest version of TortoiseGit Windows XP SP3 or newer is required.
- Admin privileges for the installation
- msysGit is required by TortoiseGit
- You do not need to download the whole msysGit development package, the "Full installer for official Git for Windows" download package is sufficient
- msysGit 1.7.10+ is recommended for TortoiseGit 1.7.9+ (msysGit 1.7.10 adds utf-8 support and is compatible to *nix git)
- minimum compatible version is 1.6.1 (for TortoiseGit < 1.7.9 you should use msysGit 1.7.6)
Just download the setup package for your system and install it. If you are running a 64 bit system, you do not need to download and install the 32 bit version: The 32 bit shell extension is included in the 64 bit installer since TortoiseGit 1.7.3.0.
If you want to use TortoiseGit in a Win2K environment (only 1.6.5 and below support Win2K), please install GDI+ before you install TortoiseGit. However, running these old versions is not recommended (no utf-8 and separate-git-dir support).
Before upgrading you should read the ReleaseNotes.
Just download the setup package for your system and install it. The old version will be replaced automatically.
If you are upgrading from 1.7.3.0 or older and you have installed the 32-bit version on a 64-bit system you have to deinstall the 32-bit version first.
Common problems (installer aborts with an error message)
"This installation package is not supported by this processor type. Contact your product vendor."
This means you are trying to install the 64-bit version of TortoiseGit on a normal 32-bit operating system. You need to download and use the correct msi file for your OS. For normal 32-bit OS, make sure the msi filename does not have "64-bit" in it.
"Please wait while the installer finishes determining your disk space requirements."
Cleanup/empty the temp-directory (e.g. C:Users<your user>AppDataLocalTemp, C:User and Settings<your user>Local SettingsTemp, c:WindowsTemp).
由如上说明，我们寻找要下载的对应安装包，如下。
二、下载安装包
1、TortoiseGit下载地址：
http://code.google.com/p/tortoisegit/downloads/list
本次下载版本——TortoiseGit-1.7.12.0-64bit.msi
TortoiseGit 1.7.12.0 64bit
x64 Featured
2、msysgit下载地址：
http://code.google.com/p/msysgit/downloads/list
本次下载版本——Git-1.7.11-preview20120710.exe
Full installer for official Git for Windows 1.7.11
Featured Beta
三、安装过程
安装顺序：首先安装msysgit；然后安装TortoiseGit。
1、安装msysgit。
a、安装包下载完成后，双击进入安装界面，如下图：
b、两步next后选择安装目录，如下图：
c、next进入Git安装模块选择，默认，如下图：
d、next进入Git setup界面，“Select start menu folder”，默认，如下图：
e、next进入Git Setup界面，“Adjusting your PATH environment”，选择默认值“Use Git Bash only”，如下图所示：
f、next进入Git Setup界面，“Configuring the line ending conversions”，选择换行格式，选择“Checkout as-is, commit Unix-style line endings”，如下图所示：
g、next进入安装界面，完成安装，如下图所示：
这个时候已经可以使用git了， 打开Git Bash可以进入linux shell，可以使用git命令进行各种操作，由于大家都习惯使用图形界面的 TortoiseSVN，下面介绍使用 TortoiseSVN的类似软件TortoiseGit，使用习惯相同,大家应该比较容易使用。
2、安装TortoiseGit。
a、双击安装程序，进入安装界面，如下如所示：
b、两步next进入“Choose SSH Client”选择界面，选择“OpenSSH，Git default SSH Client”，如下图所示：
c、next进入“Custom Setup”界面，选择默认值，如下图所示：
d、next，进入“Ready to Install”界面，选择“Install”按钮开始安装过程，完成安装。如下图所示：
e、至此，TortoiseGit安装完成。在桌面空白处点击右键，右键菜单中会加入TortoiseGit快捷键，如下图所示：
f、选择“Settings”，进入“Settings-TortoiseGit”界面，选择“General”选项卡，设置本机器的git路径，如下图所示：
g、同时选择“Network”选项卡，设置SSH路径。SSH默认在安装Git时就安装了，在如下图所示的路径中。如下图所示：
h、选择“Git”选项卡，设置用户名、邮箱和key。如下图所示：
注：如果暂时在本地使用就只需将用户名和邮箱添加，而“Signing key”会自动生成。
至此，TortoiseGit设置完成。
3、下载代码。
a、桌面空白处右键，选择git clone添加版本库地址URL和本地文件夹。如下图所示：
点击ok即可下载一份新版本库。
Git tag简介
一、轻量级标签
我们可以用 git tag不带任何参数创建一个标签(tag)指定某个提交(commit):
$ git tag stable-1 1b2e1d63ff
这样，我们可以用stable-1 作为提交(commit) "1b2e1d63ff" 的代称(refer)。
前面这样创建的是一个“轻量级标签"，这种分支通常是从来不移动的。
如果你想为一个标签(tag)添加注释，或是为它添加一个签名(sign it cryptographically), 那么我们就需要创建一个 ”标签对象".
二、标签对象
如果有 "-a", "-s" 或是 "-u " 中间的一个命令参数被指定，那么就会创建 一个标签对象，并且需要一个标签消息(tag message). 如果没有"-m " 或是 "-F " 这些参数，那么就会启动一个编辑器来让用户输入标签消息(tag message).
当这样的一条命令执行后，一个新的对象被添加到Git对象库中，并且标签引用就指向了 一个标签对象，而不是指向一个提交(commit). 这样做的好处就是：你可以为一个标签 打处签名(sign), 方便你以后来查验这是不是一个正确的提交(commit).
下面是一个创建标签对象的例子:
$ git tag -a stable-1 1b2e1d63ff
标签对象可以指向任何对象，但是在通常情况下是一个提交(commit). (在Linux内核代 码中，第一个标签对象是指向一个树对象(tree),而不是指向一个提交(commit)).
三、签名的标签
如果你配有GPG key,那么你就很容易创建签名的标签.首先你要在你的 .git/config 或 ~.gitconfig里配好key.
下面是示例:
[user]
signingkey =
你也可以用命令行来配置:
$ git config (--global) user.signingkey
现在你可以直接用"-s" 参数来创“签名的标签”。
$ git tag -s stable-1 1b2e1d63ff
如果没有在配置文件中配GPG key,你可以用"-u“ 参数直接指定。
$ git tag -u
四、语法详解
语法
git tag [-a | -s | -u
Unless -f is given, the tag to be created must not yet exist in the .git/refs/tags/ directory.
If one of -a, -s, or -u
If -m
Otherwise just a tag reference for the SHA1 object name of the commit object is created (i.e. a lightweight tag).
A GnuPG signed tag object will be created when -s or -u
OPTIONS
-a
--annotate
Make an unsigned, annotated tag object
-s
--sign
Make a GPG-signed tag, using the default e-mail address’s key.
-u
--local-user=
Make a GPG-signed tag, using the given key.
-f
--force
Replace an existing tag with the given name (instead of failing)
-d
--delete
Delete existing tags with the given names.
-v
--verify
Verify the gpg signature of the given tag names.
-n
-l
--contains
Only list tags which contain the specified commit.
--points-at
Only list tags of the given object.
-m
--message=
Use the given tag message (instead of prompting). If multiple -m options are given, their values are concatenated as separate paragraphs. Implies -a if none of -a, -s, or -u
-F
--file=
Take the tag message from the given file. Use - to read the message from the standard input. Implies -a if none of -a, -s, or -u
--cleanup=
This option sets how the tag message is cleaned up. The
The name of the tag to create, delete, or describe. The new tag name must pass all checks defined by git-check-ref-format(1). Some of these checks may restrict the characters allowed in a tag name.
CONFIGURATION
By default, git tag in sign-with-default mode (-s) will use your committer identity (of the form "Your Name
[user]
signingkey =
DISCUSSION
On Re-tagging
What should you do when you tag a wrong commit and you would want to re-tag?
If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you’re done.
But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:
The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.
The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -fagain, as if you hadn’t already published the old one.
However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.
If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying:
Ok, I messed up, and I pushed out an earlier version tagged as X. I
then fixed something, and retagged the *fixed* tree as X again.
If you got the wrong tag, and want the new one, please delete
the old one and fetch the new one by doing:
git tag -d X
git fetch origin tag X
to get my updated tag.
You can test which tag you have by doing
git rev-parse X
which should return 0123456789abcdef.. if you have the new version.
Sorry for the inconvenience.
Does this seem a bit complicated? It should be. There is no way that it would be correct to just "fix" it automatically. People need to know that their tags might have been changed.
On Automatic following
If you are following somebody else’s tree, you are most likely using remote-tracking branches (refs/heads/origin in traditional layout, orrefs/remotes/origin/master in the separate-remote layout). You usually want the tags from the other end.
On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to get tags from there. This happens more often for people near the toplevel but not limited to them. Mere mortals when pulling from each other do not necessarily want to automatically get private anchor point tags from the other person.
Often, "please pull" messages on the mailing list just provide two pieces of information: a repo URL and a branch name; this is designed to be easily cut&pasted at the end of a git fetch command line:
Linus, please pull from
git://git..../proj.git master
to get the following updates...
becomes:
$ git pull git://git..../proj.git master
In such a case, you do not want to automatically follow the other person’s tags.
One important aspect of git is its distributed nature, which largely means there is no inherent "upstream" or "downstream" in the system. On the face of it, the above example might seem to indicate that the tag namespace is owned by the upper echelon of people and that tags only flow downwards, but that is not the case. It only shows that the usage pattern determines who are interested in whose tags.
A one-shot pull is a sign that a commit history is now crossing the boundary between one circle of people (e.g. "people who are primarily interested in the networking part of the kernel") who may have their own set of tags (e.g. "this is the third release candidate from the networking group to be proposed for general consumption with 2.6.21 release") to another circle of people (e.g. "people who integrate various subsystem improvements"). The latter are usually not interested in the detailed tags used internally in the former group (that is what "internal" means). That is why it is desirable not to follow tags automatically in this case.
It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking each other’s progress by having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.
On Backdating Tags
If you have imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able to specify the date to embed inside of the tag object; such data in the tag object affects, for example, the ordering of tags in the gitweb interface.
To set the date used in future tag objects, set the environment variable GIT_COMMITTER_DATE (see the later discussion of possible values; the most common form is "YYYY-MM-DD HH:MM").
For example:
$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
DATE FORMATS
The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables support the following date formats:
Git internal format
It is
RFC 2822
The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.
ISO 8601
Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well.
Note
In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY.
结束
http://blog.csdn.net/hudashi/article/details/7664468
Git常用命令列表
修改git-log的日期格式
git config log.date iso
git config --global log.date iso
--date=(relative|local|default|iso|rfc|short|raw) Only takes effect for dates shown in human-readable format, such as when using "--pretty". log.date config variable sets a default value for log command’s --date option. --date=relative shows dates relative to the current time, e.g. "2 hours ago". --date=local shows timestamps in user’s local timezone. --date=iso (or --date=iso8601) shows timestamps in ISO 8601 format. --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format, often found in E-mail messages. --date=short shows only date but not time, in YYYY-MM-DD format. --date=raw shows the date in the internal raw git format %s %z format. --date=default shows timestamps in the original timezone (either committer’s or author’s).
列出修改过的文件 ： git status
查看文件修改具体信息： git diff （是显示还没有暂存起来的改动）
查看已经暂存起来的文件和上次提交时的快照之间的差异 ：git diff –cached/–staged
提交 ： git commit -m “commit message”
跳过使用暂存区域的提交 ： git commit -a -m “commit message”
移除文件（从暂存区域移除）：git rm xx(连带从工作目录中删除指定的文件)
如果删除之前修改过并且已经放到暂存区域的话：git rm -f xx
把文件从Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中：git rm –cached xx
xx: 一个文件或者是目录，或者是glob模式
移动文件：git mv from_name to_name
查看提交历史：git log
显示每一次的提交的差异：git log -p
指定了显示差异的次数： git log -p -x （x为次数，整数）
显示简要的增改行数统计：git log –stat
自定义log格式：git log –pretty=(online,full,fuller,short,format)
[format:"options"]
option list:
%H 提交对象（commit）的完整哈希字串
%h 提交对象的简短哈希字串
%T 树对象（tree）的完整哈希字串
%t 树对象的简短哈希字串
%P 父对象（parent）的完整哈希字串
%p 父对象的简短哈希字串
%an 作者（author）的名字
%ae 作者的电子邮件地址
%ad 作者修订日期（可以用-date= 选项定制格式）
%ar 作者修订日期，按多久以前的方式显示
%cn 提交者(committer)的名字
%ce 提交者的电子邮件地址
%cd 提交日期
%cr 提交日期，按多久以前的方式显示
%s 提交说明
加入ASCII 字符串表示的简单图形：git log –pretty=(online,format) –graph
git log的详细选项：
-p 按补丁格式显示每个更新之间的差异。
–stat 显示每次更新的文件修改统计信息。
–shortstat 只显示–stat 中最后的行数修改添加移除统计。
–name-only 仅在提交信息后显示已修改的文件清单。
–name-status 显示新增、修改、删除的文件清单。
–abbrev-commit 仅显示SHA-1 的前几个字符，而非所有的40 个字符。
–relative-date 使用较短的相对时间显示（比如，“2 weeks ago”）。
–graph 显示ASCII 图形表示的分支合并历史。
–pretty 使用其他格式显示历史提交信息。可用的选项包括oneline，short，full，fuller 和format（后跟指定格式）
按照时间限制输出长度：git log –since=time, 如git log –since=2.weeks 最近两周内的提交，git log –since=“2012-11-26” 具体某一天的提交
更多：git log option
-(n) 仅显示最近的n 条提交
–since, –after 仅显示指定时间之后的提交。
–until, –before 仅显示指定时间之前的提交。
–author 仅显示指定作者相关的提交。
–committer 仅显示指定提交者相关的提交。
修改最后一次提交：git commit –amend(使用当前的暂存区域快照提交)
取消已经暂存的文件:git reset HEAD <file>…
取消对文件的修改:git checkout — file(危险:所有对文件的修改都没有了，因为我们刚刚把之前版本的文件复制过来重写了此文件。所以在用这条命令前，请务必确定真的不再需要保留刚才的修改)
列出每个远程库的简短名字:git remote
对应的克隆地址：git remote -v
添加远程仓库：git remote add [shortname] [url]
抓取所有一个远程库有的，但本地仓库没有的信息：git fetch shortname
抓取数据合并到本地：git pull shortname
从远程仓库抓取数据：git fetch [remote-name]（到远程仓库中拉取所有你本地仓库中还没有的数据）
推送数据到远程仓库：git push [remote-name] [branch-name]
查看远程仓库信息：git remote show [remote-name]
远程仓库的删除和重命名：git remote rename from_name to_name
移除对应的远端仓库:git remote rm shortname
列显已有的标签:git tag
指定某些 tag匹配：git tag -l ‘version’, 如 git tag -l ‘v 1.* ‘(l:list 不是1，2，3的1)
含附注的标签：git tag -a vx.x -m ‘description’ 如，git tag -a v1.0 -m ‘this is version 1.0′
查看相应标签的版本信息:git show tagName ,如git show v1.0
签署标签:git tag -s vx.x -m ‘description’ 如，git tag -s v1.1 -m ‘this is version 1.1′
轻量级标签:不使用-a -s等tag方式，git tag vx.x
验证标签:git tag -v tagname [v:verify]
后期加注标签:git tag -a vx.x hushnum,如git tag -a v1.3 asdec13 (对应提交对象的校验和)
分享标签:git push shortname tagname
一次推送所有（本地新增的）标签:git push shortname –tags
删除本地tag：git tag -d tag_name
删除远端tag: git push shortname :refs/tags/tag_name
Git版本恢复命令reset
reset命令有3种方式：
git reset --mixed：此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码，回退commit和index信息
git reset --soft：回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可
git reset --hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容
以下是一些reset的示例：
(1) 回退所有内容到上一个版本
git reset HEAD^
(2) 回退a.py这个文件的版本到上一个版本
git reset HEAD^ a.py
(3) 向前回退到第3个版本
git reset –soft HEAD~3
(4) 将本地的状态回退到和远程的一样
git reset –hard origin/master
(5) 回退到某个版本
git reset 057d
(7) 回退到上一次提交的状态，按照某一次的commit完全反向的进行一次commit
git revert HEAD
在本地开发了一个版本，然后加入某些代码， git commit 之后再 git push 与远程版本库同步，这时出现一个问题，在这次 git commit 之前的版本内容如何找回？
首先git log显示提交的历史
- commit ee50348120302b19318ab6a564d4092dd87a85ef
- Author: ShichaoXu <gudujianjsk@gmail.com>
- Date: Mon Jun 3 15:18:16 2013 +0800
- support for printf
- commit e7a5e492c742a7b68c07f124edd4b713122c0666
- Author: ShichaoXu <gudujianjsk@gmail.com>
- Date: Tue May 7 15:44:11 2013 +0800
- del file lib/2440slib.s init/2440init.s
- commit 5a05f002ef1dfbbf118b2ffd7b829159b727ce16
- Author: ShichaoXu <gudujianjsk@gmail.com>
- Date: Tue May 7 15:26:30 2013 +0800
- change file name lib/2440slib.s init/2440init.s to lib/2440slib.S init/2440init.S
- commit a948e62c9eabd54bfc4de3c4dfd14b4fc2bb48dd
- Author: ShichaoXu <gudujianjsk@gmail.com>
- Date: Tue May 7 15:06:17 2013 +0800
- add code for this project
- commit 59a902efdef8fb3dd47264df8a666de7026d1595
- Author: ShichaoXu <gudujianjsk@gmail.com>
- Date: Mon May 6 23:15:01 2013 -0700
- Initial commit
然后用
- ~/gun-ucos$$git reset --hard e7a5e492c742a7b68c07f124edd4b713122c0666
显示如下
- HEAD is now at e7a5e49 del file lib/2440slib.s init/2440init.s
此时正常回到git commit "support for printf" 之前的状态！
git 分支管理 branch
Git的分支管理是Git的神器。拥有了它就会使我么管理代码更加游刃有余。那么什么是Git的分支管理？为什么要使用Git的分支管理？Git分支管理怎么用？
GIT乱码解决方案汇总
在处理一个有中文文件名的项目时却出现文件名乱码的问题。
情况重现
- 在一个使用cygwin的bash提交的git项目中，已经完成了所有的提交，但使用TortoiseGit查看的时候，却发现仍有文件没有提交，甚至是有文件还处于未暂存的状态。于是使用TortoiseGit提交；
- 再次用cygwin下的git status查看，这次又发现了未提交的情况。再次用git commit命令行提交；
- 回到TortoiseGit下查看，问题又出现了！此时准备返回两次提交前的版本，却因为文件名乱码的问题，无法返回了！
乱码原因
搜索一番，发现git文件名、log乱码，是普遍问题，这其中有编码的原因，也有跨平台的原因。主要原因是Windows 系统中的Git对中文文件名采用不同的编码保存所致。
Windows系统中使用的msysGit，采用的是系统编码来保存文件名；而Cygwin中的Git默认采用UTF-8编码来保存文件名。如果两个软件同时对一个版本库进行操作，且都认为对方是使用自己使用的编码来保存文件，就会导致文件名编码混乱，无法识别。
这就导致，如果一直使用TortoiseGit（实际调用MsysGit）提交，那么中文文件名没问题；一直使用cygwin提交，中文文件名也没问题。但一定不能交叉使用。
分别设置LANG、LC_CTYPE、LC_ALL参数为同样的编码，问题依旧。
cygwin官方网站提到了非拉丁语文件名的问题，也许研究后能解决该吧：Chapter 2. Setting Up Cygwin
这里还有一篇讲解Linux系统编码文章：locale的设定及其LANG、LC_ALL、LANGUAGE环境变量的区别
官方终极解决方案
这个问题的官方终极解决方案，就是更新到msysGit1.7.10或更新版本。这个版本之后，msysGit和Git for Windows已经采用了UTF-8编码来保存文件名，不会再出现乱码的情况。安装和使用可参考这篇文章：使用Git、Git GUI和TortoiseGit
不幸的是，对于使用老版本msysGit提交的版本库，升级到msysGit1.7.10或者更高会出现编码问题。
有两篇文章介绍了这个问题的解决办法：
- 升級到 msysgit 1.7.10 的檔名亂碼處理方式（需要翻墙）
- upgrading to msysGit 1.7.10 (or higher)
下面的文章，是历史遗留，可以不看。若希望知其所以然，则不妨观之。
乱码情景对号入座和解决方案
乱码情景1
在cygwin中，使用git-add添加要提交的文件的时候，如果文件名是中文，会显示形如274\232\350\256\256\346\200\273\347\273\223.png的乱码。
解决方案：
在bash提示符下输入：
git config --global core.quotepath false
core.quotepath设为false的话，就不会对0×80以上的字符进行quote。中文显示正常。
乱码情景2
在MsysGit中，使用git log显示提交的中文log乱码。
解决方案：
设置git gui的界面编码
git config --global gui.encoding utf-8
设置 commit log 提交时使用 utf-8 编码，可避免服务器上乱码，同时与linux上的提交保持一致！
git config --global i18n.commitencoding utf-8
使得在 $ git log 时将 utf-8 编码转换成 gbk 编码，解决Msys bash中git log 乱码。
git config --global i18n.logoutputencoding gbk
使得 git log 可以正常显示中文（配合i18n.logoutputencoding = gbk)，在 /etc/profile 中添加：
export LESSCHARSET=utf-8
乱码情景3
在MsysGit自带的bash中，使用ls命令查看中文文件名乱码。cygwin没有这个问题。
解决方案：
使用 lls --show-control-chars 命令来强制使用控制台字符编码显示文件名，即可查看中文文件名。
为了方便使用，可以编辑 /etc/git-completion.bash ，新增一行 alias ls="ls --show-control-chars"
终极解决方案
终极的解决方案是通过修改git和TortoiseGit源码实现，有网友这么做了：让Windows下Git和TortoiseGit支持中文文件名/UTF-8，也可以直接访问这个开源的Google项目：utf8-git-on-windows。
如果不抗拒命令行的话，直接用Cygwin来提交Git库。因为Cygwin其实是一个在Windows平台上的模拟器，它完全模拟GNU/Linux的方式运行，所以Cygwin中的Git是采用UTF-8编码来保存中文的。
在操作git时，把区域设置修改为 中文GBK。这之后就可以进行git相关操作了。
在终端中跟windows保持一致
1
2
|
export LC_ALL=zh_CN.GBK; export LANG=zh_CN.GBK
terminal -> set charactor encoding -> gbk
|
切换回linux默认
1
2
|
export LC_ALL=en_US.utf8; export LANG=en_US.utf8
terminal -> set charactor encoding -> unicode(utf-8)
|
改变文件名的编码
如果已经造成乱码的恶果，还可以在utf8和gbk之间切换文件名。真的修改，而不是像上面那样修改显示的（解码的）效果。
git查看某个文件的修改历史
有时候在比对代码时，看到某些改动，但不清楚这个改动的作者和原因，也不知道对应的CR号，也就是说无从查到这些改动的具体原因了～
【注】：某个文件的改动是有限次的，而且每次代码修改的提交都会有commit描述，我们可以从这里进行入手；
一、切换到目录
首先切换到要查看的文件所在的目录：
cd packages/apps/Mms/src/com/android/mms/ui/
二、git log --pretty
然后使用下面的命令可列出文件的所有改动历史，注意，这里着眼于具体的一个文件，而不是git库，如果是库，那改动可多了去了～
git log --pretty=oneline 文件名
如：
root@ubuntu:android_src/packages/apps/Mms/src/com/android/mms/ui# git log --pretty=oneline MessageItem.java 27209385caf678abe878375a470f4edd67a2d806 fix cr 17973 to process force close when empty address contained in card 0e04b16f1dad7dc0a36e2235f7337bc656c365c7 display for 1970-1-1 e4abf3a213197491e0855e101117b59b5dc0160d HREF#13954 receive, store, and display wap push 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e HREF#16265_uim_show_time_error 350f9d34c35ab50bdb4b2d43fb3ff9780e6c73fa fix href#13617 and href#15149 715e32f97bd9d8ce4b5ba650b97ba4b137150456 Fix ANR from calling Contact.get() fd8357ff5febab0141e1beb8dd3b26f70416b108 Fix missing From field d130e2e6dc448fd80ecb70f0d31e3affb9888b9a fix bug 2112925: don't display zip file garbage content in MMS. 0e19f738c114f86d0d88825ee48966015fb48b6d Don't always show sent timestamp 52f854cbb75e8f9975c7e33216b828eb2f981095 Don't show Anonymous as the MMS sender 331864544ec51ba6807fc5471cc6d537b7fef198 add search capability 33a87f96f8c625aa10131a77a3968c97c4ec5a62 Remove all references to ContactInfoCache except those in Contact. 70c73e05a792832aa28da751cdaf3fa83a7b8113 Begin moving all conversation data behind a data model with a cache. 48da875f1beea835c6771977e5bd8a9aa3d4bc10 Begin adding UI unit tests to the Mms app. 66dde9460badebf8e740275cabde9cca256006eb Stop requiring a Context to be passed in to ContactInfoCache. 591d17e9a51bb9f829d6860dc7aa0bad25062cd5 auto import from //branches/cupcake_rel/...@138607 72735c62aba8fd2a9420a0f9f83d22543e3c164f auto import from //depot/cupcake/@135843 892f2c5bf965b1431ae107b602444a93f4aad4a3 auto import from //depot/cupcake/@135843 153ae99e0a7d626a24d61475eeb133249deb448c auto import from //depot/cupcake/@132589 abd7b2d90f7491075f1daba4b4cccdfc82f8ddd1 auto import from //depot/cupcake/@137055 59d72c57ce9c319b6cd43ce2ab36b7076c9e821f auto import from //branches/cupcake/...@132276 44cea74dc55e2459262d0d765ef4a69267dd09b0 auto import from //branches/cupcake/...@131421 0f236f55349f070ac94e12cca963847173393da8 Code drop from //branches/cupcake/...@124589 8eed706474910ccb978acda03e85d3261037da6e Initial Contribution
三、git show
如上所示，打印出来的就是针对文件MessageItem.java的所有的改动历史，每一行最前面的那一长串数字就是每次提交形成的哈希值，接下来使用git show即可显示具体的某次的改动的修改～
git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e
结果如下：
root@ubuntu:/android_src/packages/apps/Mms/src/com/android/mms/ui# git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e commit 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e Author: 某某某 <某某某的邮箱> Date: Thu Jan 6 01:50:31 2011 +0800 修改的描述（是该代码commit时所填） Signed-off-by: 某某某 <某某某的邮箱> diff --git a/src/com/android/mms/ui/MessageItem.java b/src/com/android/mms/ui/MessageItem.java index 0a0c4b7..55c3b27 100644 --- a/src/com/android/mms/ui/MessageItem.java +++ b/src/com/android/mms/ui/MessageItem.java + + 列出具体的改动 - -
这样就可以知道是谁做了修改，以及具体的修改代码～
那接下来不管是直接去找他交流还是研究代码，都有依据了～
Git .gitignore 設定與注意事項 – 以Zim操作為範例
Git 設定 .gitignore, 設定完成就都直接生效, 在測試時都很正常, 但是實際使用 卻沒有生效, 有點軌異.
環境
- Git 所管理的專案名稱、位置: /home/user/doc
下述範例是以 Zim 為主, Zim 是一套桌面的 Wiki 編輯器, 裡面寫的內容都會存成 txt 檔, .zim 的目錄下會存 “*.cache” 和 “zim 本身自己的設定值”.
Zim 在剛開始建立完成後, 就使用下述步驟:
- cd /home/user/doc
- git init
- git commit -a
- git push #一開始沒有設定 .gitignore, 所以會將 .zim/* 都 commit 進去
於每次開啟 Zim 後, 都會出現
modified: .zim/history.cache
modified: .zim/index.cache
造成 git commit -a 的麻煩 (因為多台電腦要同步時, index.cache / history.cache 都會出現需要 merge 的狀況), 所以想設定 .gitignore 來把它拿掉. (方便 git commit -a)
設定 .gitignore 位置、方法
設定 Git ignore 的方式都一樣, 有下面幾個地方可以設定, 依自己喜好 / 需求來設定即可.(設定位置)
- vim ~/.gitignore # 對所有 Git 的專案生效 (自己的 home 目錄下)
- vim doc/.gitignore # doc 是專案名稱, 用這個的好處是, 將 .gitignore commit 進去, 此 .gitignore 可以隨著專案到處走. (Git 管理的 Project 目錄下)
- vim doc/.git/info/exclude # 只有單獨於此處 .git 生效 (Project 的 .git/info/exclude 檔案)
- 這幾個地方都可以設定, 可以使用 * 等符號. 詳可見: gitignore(5) Manual Page
於 .zim 的狀況, 可以設定下述: (設定方法)
- 所有 . 開頭的目錄 / 檔案都不 commit
.*
- .zim 目錄內 的 所有 *.cache 都不 commit
.zim/*.cache
- 只有 .zim/history.cache, .zim/index.cache 不 commit
.zim/history.cache
.zim/index.cache
.gitignore 無法生效 的 問題修復
在測試狀況都是正常, 但是在 Zim 實際使用就有問題, 每次都出現 modified 的解法.
解法
- 因為第一次 commit 已經將 .zim/*.cache commit 進去了, 所以每次它都會去檢查, 造成都出現 modified 的狀況.
- git rm -f .zim/history.cache
- git rm -f .zim/index.cache
- git commit # 即可
- 再將 .gitignore 設定好, 就可以避免掉這些狀況囉~
範例 -我的 Zim 設定方式
- cd /home/user/doc
- vim .gitignore
.zim/*.cache
- git add .gitignore
- git commit
- git push
git建立远程仓库，让别人clone下来
首先, 如果你的ssh没有安装的话，要安装ssh服务端。ubuntu是很简单
sudo apt-get install openssh-server
1.建立你的git 目录。
ourunix@ubuntu:~$ mkdir testgit
ourunix@ubuntu:~$ cd testgit/
2.建立你的git仓库。
ourunix@ubuntu:~/testgit$ git init
Initialized empty Git repository in /home/wlp/testgit/.git/
3.添加你的需要的项目初始文件，这里我就只添加一张文档了。
ourunix@ubuntu:~/testgit$ echo "hello,git" > sayhi.txt
4.跟踪及提交到仓库。
ourunix@ubuntu:~/testgit$ git add sayhi.txt
ourunix@ubuntu:~/testgit$ git commit -m "2011.4.13" sayhi.txt
[master (root-commit) b87b535] 2011.4.13
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 sayhi.txt
5.在本地的git仓库"添加一个远程仓库",当然这个远程仓库还是你自己的这个目录。
ourunix@ubuntu:~/testgit$ git remote add origin ssh://你的用户名@你的IP/~/testgit/.git
这时候,本地的 .git/config 应该会改变
6.将本地的 master分支 ，跟踪到远程的分支
ourunix@ubuntu:~/testgit$ git push origin master
7.显示远程信息
ourunix@ubuntu:~/testgit$git remote show origin
8.利用其他局域网的电脑测试你的仓库
ourunix@ubuntu:~/test$ git clone ssh://你的用户名@你的IP/home/～/testgit/.git
Initialized empty Git repository in /home/wlp/test/git/.git/
xxx‘s password:
remote: Counting objects: 3, done.
Receiving objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
9. 大功告成
10. 修改远程分支地址
git remote set-url origin remote_git_address
支持博主
关于邵珠庆博客
文章标签
记事邵珠庆博客
最近文章
最近评论
- 发表在《中国翻墙网民状况调查》
- 发表在《教你如何简单获取新浪微博短地址接口》
- 发表在《教你如何简单获取新浪微博短地址接口》
- 发表在《教你如何简单获取新浪微博短地址接口》
- 发表在《教你如何简单获取新浪微博短地址接口》
博客日历
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
|---|---|---|---|---|---|---|
| « 8月 | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
目录分类
文章归档
- 2022年8月 (2)
- 2022年7月 (1)
- 2022年3月 (1)
- 2021年10月 (3)
- 2021年1月 (1)
- 2020年4月 (3)
- 2020年3月 (3)
- 2020年2月 (2)
- 2020年1月 (3)
- 2019年12月 (2)
- 2019年11月 (3)
- 2019年10月 (2)
- 2019年9月 (2)
- 2019年8月 (4)
- 2019年7月 (2)
- 2019年6月 (2)
- 2019年5月 (2)
- 2019年4月 (3)
- 2019年3月 (2)
- 2019年2月 (3)
- 2019年1月 (2)
- 2018年12月 (2)
- 2018年11月 (2)
- 2018年10月 (3)
- 2018年9月 (2)
- 2018年8月 (2)
- 2018年7月 (1)
- 2018年6月 (2)
- 2018年5月 (3)
- 2018年4月 (2)
- 2018年3月 (6)
- 2018年2月 (7)
- 2018年1月 (3)
- 2017年11月 (2)
- 2017年10月 (2)
- 2017年9月 (5)
- 2017年8月 (4)
- 2017年7月 (8)
- 2017年6月 (5)
- 2017年5月 (14)
- 2017年4月 (8)
- 2017年3月 (5)
- 2017年2月 (2)
- 2017年1月 (1)
- 2016年12月 (1)
- 2016年11月 (5)
- 2016年10月 (3)
- 2016年9月 (2)
- 2016年8月 (1)
- 2016年7月 (2)
- 2016年6月 (2)
- 2016年5月 (5)
- 2016年4月 (5)
- 2016年3月 (2)
- 2016年2月 (1)
- 2016年1月 (2)
- 2015年12月 (2)
- 2015年11月 (1)
- 2015年10月 (3)
- 2015年9月 (2)
- 2015年8月 (4)
- 2015年7月 (5)
- 2015年6月 (6)
- 2015年5月 (3)
- 2015年4月 (8)
- 2015年3月 (6)
- 2015年2月 (4)
- 2015年1月 (5)
- 2014年12月 (2)
- 2014年11月 (5)
- 2014年10月 (5)
- 2014年9月 (1)
- 2014年8月 (2)
- 2014年7月 (4)
- 2014年6月 (1)
- 2014年5月 (9)
- 2014年4月 (5)
- 2014年3月 (1)
- 2014年2月 (1)
- 2014年1月 (5)
- 2013年12月 (4)
- 2013年11月 (12)
- 2013年10月 (6)
- 2013年9月 (7)
- 2013年8月 (8)
- 2013年7月 (15)
- 2013年6月 (9)
- 2013年5月 (12)
- 2013年4月 (8)
- 2013年3月 (11)
- 2013年2月 (9)
- 2013年1月 (21)
- 2012年12月 (8)
- 2012年11月 (7)
- 2012年10月 (19)
- 2012年9月 (16)
- 2012年8月 (13)
- 2012年7月 (10)
- 2012年6月 (11)
- 2012年5月 (11)
- 2012年4月 (8)
- 2012年3月 (8)
- 2012年2月 (11)
- 2012年1月 (8)
- 2011年12月 (18)
- 2011年11月 (32)
- 2011年10月 (17)
- 2011年9月 (18)
- 2011年8月 (11)
- 2011年7月 (55)
- 2011年6月 (1)
- 2011年5月 (4)
- 2011年4月 (2)
- 2011年3月 (1)
- 2011年1月 (3)
- 2010年12月 (1)
- 2010年11月 (6)
- 2010年9月 (5)
- 2010年8月 (2)
- 2010年7月 (3)
- 2010年6月 (7)
- 2010年5月 (3)
- 2010年4月 (4)
- 2010年3月 (8)
- 2010年2月 (2)
- 2010年1月 (2)
- 2009年12月 (2)
- 2009年11月 (1)
- 2009年10月 (1)
- 2009年8月 (1)
- 2009年7月 (2)
- 2009年5月 (1)
- 2009年4月 (1)
- 2009年3月 (1)
- 2009年2月 (1)
- 2009年1月 (1)
- 2008年12月 (1)
- 2008年11月 (2)
- 2008年10月 (1)
- 2008年8月 (5)
- 2008年7月 (2)
- 2008年6月 (1)
- 2008年5月 (3)
- 2008年4月 (11)
- 2008年3月 (1)
- 2008年2月 (1)
- 2008年1月 (1)
- 2007年12月 (1)
- 2007年11月 (3)
- 2007年10月 (1)
- 2007年9月 (1)
- 2007年8月 (1)
- 2007年7月 (1)
- 2007年6月 (1)
- 2007年5月 (1)
