git常用命令整理

1.git init
git init:       创建空的git仓库。

2.git clone
git clone --bared:      只clone .git仓库，而不会clone working directory和staging area.

3.git add
git add:        根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等.
合并分支时，如果有冲突。在解决了所有文件里的所有冲突后，运行git add将把它们标记为已解决状态（实际上就是来一次快照保存到暂存区域）。因为一旦暂存，就表示冲突已经解决。
git add -i:     Git就进入了一个交互式的shell模式.
git add -p:     实现部分文件暂存.
git mergetool:  调用一个可视化的合并工具并引导你解决所有冲突

4.git commit
git commit --amend:     只想修改最近一次提交说明,此命令将使用当前的暂存区域快照提交。如果刚才提交完没有作任何改动，直接运行此命令的话，相当于有机会重新编辑提交说明，但将要提交的文件快照和之前的一样。

5.git config
git config:     修改或显示配置文件。
git config --global:修改全局配置(当前用户的配置，配置文件位于$HOME).
git config --system:表示修改系统全局配置，配置文件位于/etc/gitconfig。显示配置文件使用--list。

6.git diff

git diff:显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异。

git diff --check: 把可能的多余白字符列出来。

git diff --cached 或 --staged:  已经暂存起来的文件和上次提交时的快照之间的差异.
git diff --clour diff:  语法高亮
git diff -ignore-space-at-eol:  忽略行尾的whitespace
git diff -ignore-space-change:  忽略行尾的whitespace，并且认为所有的whitespace都是一样的
git diff -ignore-all-space  比较两行的时候，完全忽略whitespace。这样，即使是一行有很多whitespaces，另一行文字一样但是没有whitespace

7.git apply
git apply:相当于patch(1)命令，不过git-apply专门用来apply那些用git-diff生成的补丁
git apply --check:不真正打补丁，而只是检查补丁是否能完美的打上
git apply -v verbose模式

git apply -R reverse模式,也就是拉出这个补丁来

8.git log

git log -p:     按补丁格式显示每个更新之间的差异。
git log --stat: 显示每次更新的文件修改统计信息。
git log --shortstat:只显示 --stat 中最后的行数修改添加移除统计。
git log --name-only:仅在提交信息后显示已修改的文件清单。
git log --name-status:显示新增、修改、删除的文件清单。
git log --abbrev-commit:仅显示 SHA-1 的前几个字符，而非所有的 40 个字符。
git log --relative-date:使用较短的相对时间显示（比如，“2 weeks ago”）。
git log --graph:显示 ASCII 图形表示的分支合并历史。
git log -(n):仅显示最近的 n 条提交
git log --since, --after 仅显示指定时间之后的提交。
git log --until, --before 仅显示指定时间之前的提交。
git log --author 仅显示指定作者相关的提交。
git log --committer 仅显示指定提交者相关的提交。
git log --pretty:使用其他格式显示历史提交信息。可用的选项包括short，full，fuller,oneline(将每个提交放在一行显示)和format（后跟指定格式)等.

git log --pretty=format:"%h - %an, %ar : %s"
常用的格式占位符写法及其代表的意义。
选项    说明
%H      提交对象（commit）的完整哈希字串
%h      提交对象的简短哈希字串
%T      树对象（tree）的完整哈希字串
%t      树对象的简短哈希字串
%P      父对象（parent）的完整哈希字串
%p      父对象的简短哈希字串
%an     作者（author）的名字
%ae     作者的电子邮件地址
%ad     作者修订日期（可以用 -date= 选项定制格式）
%ar     作者修订日期，按多久以前的方式显示
%cn     提交者(committer)的名字
%ce     提交者的电子邮件地址
%cd     提交日期
%cr     提交日期，按多久以前的方式显示
%s      提交说明
作者指的是实际作出修改的人，提交者指的是最后将此工作成果提交到仓库的人。所以，当你为某个项目发布补丁，然后某个核心成员将你的补丁并入项目时，你就是作者，而那个核心成员就是提交者。

git log --graph:
        可以看到开头多出一些 ASCII 字符串表示的简单图形，形象地展示了每个提交所在的分支及其分化衍合情况。

git log --since=2.weeks:
        按照时间作限制的选项,列出所有最近两周内的提交.你可以给出各种时间格式，比如说具体的某一天（“2008-01-15”），或者是多久以前（“2 years 1 day 3 minutes ago”）。
git log --until:

git log --author:
        显示指定作者的提交。

git log --grep:
        搜索提交说明中的关键字,
--all-match:
        如果要得到同时满足这两个选项搜索条件的提交，就须--all-match选项。

git log master..experiment:
        让Git显示所有可从experiment分支中获得而不能从master分支中获得的提交
git log origin/master..HEAD:
        查看你将把什么推送到远程,这条命令显示任何在你当前分支上而不在远程origin 上的提交。如果你运行git push 并且的你的当前分支正在跟踪origin/master，被该命令列出的提交就是将被传输到服务器上的提交。
git log origin/master..:
        将得到和上面的例子一样的结果——Git使用HEAD 来代替不存在的一边.可以留空语法中的一边来让Git来假定它是HEAD.

git log refA..refB:
git log ^refA refB:
git log refB --not refA:
        Git允许在引用前使用^字符或者--not指明你不希望提交被包含其中的分支。因此上面三个命令是等同的.

git log master...experiment:
        查看master或者experiment中包含的但不是两者共有的引用.三点范围选择语法，这个可以指定被两个引用中的一个包含但又不被两者同时包含的分支,

git log --left-right master...experiment:
        显示每个提交到底处于哪一侧的分支。这使得数据更加有用。

9.git branch
git branch testing:     新建一个testing 分支
git branch --merge:     从branch清单中筛选出已经与当前分支合并的分支
git branch --no-merged: 从branch清单中筛选出还没有与当前分支合并的分支
git branch -v:          查看各个分支最后一个提交对象的信息
git branch -a:          列出所有分支，包括remote和local branches,前面有*的表示，当前所在的branch
git branch -r:          列出远程branches
git branch -d branch:   删除branch
git branch -D branch:   强制删除branch

10.git checkout
git checkout -b [本地分支名] [远程名]/[远程分支名]:
        设定跟踪分支,本地跟踪远程分支。跟踪分支是一种和远程分支有直接联系的本地分支。在跟踪分支里输入 git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。反过来，在这些分支里运行 git pull 会获取所有远程索引，并把它们的数据都合并到本地分支中来

git checkout -b sf origin/serverfix:
        要为本地分支设定不同于远程分支的名字，只需在前个版本的命令里换个名字,现在你的本地分支sf会自动向origin/serverfix 推送和抓取数据了。
git checkout --track [远程名]/[远程分支名]:
        设定跟踪分支,本地跟踪远程分支.本地和远程的分支名称相同。
git checkout -- <file>:         取消对文件file(只被修改，未暂存与提交)的修改。
git checkout branch-name:       切换到branch-name
git checkout -b new-branch master:从master建立新的new-branch，并同时切换过去new-branch
git checkout -b newbranch:      由现在的分支为基础，建立新的branch
git checkout -b newbranch origin:由origin的基础，建立新的branch
git checkout filename:          还原档案到Repository状态
git checkout xxxx:              将所有档案都checkout出来(xxxx是commit的编号前四位).
git checkout HEAD:              将所有档案都checkout出来(最后一次commit的版本)，注意，若有修改的档案都会被还原到上一版

11.git merge
git merge branch-name:  把branch-name merge到当前branch上.

git merge --squash branch-name:把branch-name分支上的所有更改全拿来应用到当前分支。

git merge --no-commit branch-name: 无需自动生成和记录（合并）提交。

12.git show
git show commit名称:    显示更详细的commit信息
git show 分支名称:      显示分支信息
git show HEAD^:         查看HEAD的父母的信息
git show HEAD^^:        查看HEAD的父母的父母的信息
git show HEAD~5:        查看HEAD上溯5代的信息
git show HEAD^1:        查看HEAD的第一个父母
git show HEAD^2:        查看HEAD的第二个父母
git show tag:           查看相应标签的版本信息，并连同显示打标签时的提交对象。
用^表示commont的parent：

13.git archive
git archive -v tag:
        从本地git仓库中提取某个版本的源码,-v表示--verbose，tag可以是git tag -l列出的tags中的一个，也可以是其他Rev ID例如HEAD等.
git archive -v HEAD | (cd ../linux-HEAD/ && tar xf -):导出最新的代码:

14.git remote
git remote:     查看当前配置有哪些远程仓库，列出每个远程库的简短名字。
git remote -v:  查看当前配置有哪些远程仓库,并显示对应的克隆地址.
git remote add name url:添加一个新的远程仓库，可以指定一个简单的名字，以便将来引用
git remote rm remote-repo:移除远程仓库
git remote push +master:master ：强制使用本地的master分支覆盖远程master分支

git remote show [remote-name]:
        查看某个远程仓库的详细信息.它告诉我们，运行 git push 时缺省推送的分支是什么。它还显示了有哪些远端分支还没有同步到本地，哪些已同步到本地的远端分支在远端服务器上已被删除，以及运行git pull时将自动合并哪些分支.

git remote rename paul pb:
        命令修改某个远程仓库的简短名称，对远程仓库的重命名，也会使对应的分支名称发生变化，如原来的pb/master分支现在成了paul/master。

在克隆完某个项目后，至少可以看到一个名为 origin 的远程库，Git 默认使用这个名字来标识你所克隆的原始仓库.我们用 (远程仓库名)/(分支名) 这样的形式表示远程分支。

15.git fetch
git fetch origin:       同步远程服务器上的数据到本地。该命令首先找到 origin 是哪个服务器，从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 origin/master 的指针移到它最新的位置上.fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准>备好了，才能手工合并从远程仓库抓取数据，

git fetch [remote-name][branch-name]:
        抓取远程仓库的指定分支.在fetch操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。如果要把该内容合并到当前分支，可以运行git merge origin/serverfix。

git fetch [remote-name]:
        此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支，一探究竟。

16.git pull
git pull:       从远程仓库分支中获得更新,pull命令包含两个操作：从远端分支中取出改动，然后合并到当前分支中。相当于git fetch+ git merge。当git clone之后，直接git pull它会自动匹配一个正确的remote url，因为在.git/config文件里配置了[branch "master"]

17.git push
git push [远程名] [本地分支]:[远程分支]:        将本地的分支内容推送到远程的指定分支上。如果省略[本地分支]，那就等于“在这里提取空白然后把它变成[远程分支]”,相当于删除远程分支。如：git push origin:serverfix表示在服务器上删除serverfix 分支.

git push origin serverfix:serferfix:    上传我本地的serverfix分支到远程仓库中去，仍旧称它为 serverfix 分支.
git push origin serverfix:      同上，取出我在本地的serverfix分支，推送到远程仓库的 serverfix 分支中去
git push origin serverfix:awesomebranch:        把本地的serverfix分支推送到远程的awesomebranch分支.
git push origin master:         把本地的master分支推送到origin服务器上（再次说明下，克隆操作会自动使用默认的master和origin名字）

git push origin [tagname]:      默认情况下，git push 并不会把标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库.
git push origin --tags:         一次推送所有本地新增的标签上去.

18.git reset
git reset HEAD <file>:  取消file的暂存
git reset HEAD^:        删除最近的commit
git reset --mixed:      staged与commited都会清除，但是modified不会清除,默认为该模式。
git reset --hard:       modified，staged，commited都会清除.
git reset --soft:       commited被清除，modified，staged还在.
git reset --hard HEAD~4:        将最新的4次提交全部重置，就像没有提交过一样
git-gc --prune:         擦除提交历史

19.git revert
git revert:     只是修改了commit，修改后再次提交。

git revert与git reset的区别：
git reset:      是还原到指定的版本上，这将扔掉指定版本之后的版本
git revert:     是提交一个新的版本将需要revert的版本的内容再反向修改回去，版本会递增，不影响之前提交的内容

20.git tag
Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说>明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。

git tag v1.0:   建立轻量级的标签

git tag -a [name]  -m [“xxxx”]:         创建一个含附注类型的标签非常简单，用 -a （取 annotated 的首字母）指定标签名字.建立含注释的标签会产生一个标签对象
git tag -a v1.4 -m 'my version 1.4':    同上。

git tag -l 'v1.4.2.*':          列出1.4.2系列的所有标签.
git tag -s v1.5 -m 'my signed 1.5 tag':         用 GPG 来签署标签，只需要把之前的 -a 改为 -s （取 signed 的首字母）
git tag -v [tag-name]:  验证已经签署的标签。此命令会调用 GPG 来验证签名，所以你需要有签署者的公钥，存放在 keyring 中，才能验证.

git tag -a v1.2 9fceb02:        为指定提交打上标签.只要在打标签的时候跟上对应提交对象的校验和（或前几位字符）即可.

21.git bisect
git bisect start:       启动
git bisect good good_commit:    指定好的版本。可以用tag表示，也可以用那20byte的前2个byte表示
git bisect bad:         指定有bug的版本。
git bisect reset:       重设你的HEAD到你开始前的地方

git bisect start HEAD v1.0:     列出已知的错误提交,已知的正确提交
git bisect run test-error.sh:
        如果你有一个脚本会在工程正常时返回0，错误时返回非0的话，你可以完全自动地执行git bisect。首先你需要提供已知的错误和正确提交来告诉它二分查找的范围。这样会自动地在每一个检出的提交里运行test-error.sh直到Git找出第一个破损的提交。你也可以运行像make或者make tests或>者任何你所拥有的来为你执行自动化的测试。

22.git format patch
git format-patch -2 -o ~/patch/:        使用最后两次创建patch，并将创建好的ptach放入~/patch/目录下.
git format-patch:       是用于把当前的git目录中的commit生成的patch文件，并组织成UNI--cover-letterX mailbox的邮件格式.
git format-patch --cc:  后指定的是邮件的抄送接收人
git format-patch -n:    表示只处理最后n次commit

git format-patch -M:    允许git检查是否有对文件重命名的提交

git format-patch --cover-letter 生成"总结"patch.  In addition to the patches, generate a cover letter file containing the shortlog and the overall diffstat. You can fill in a description in the file before sending it out.

23.git send-email
git send-email --to xxx@xxx --to xxx@xx --cc xxx@xxx --bcc xx@xx ~/patch:
        发送patch，分别表示目标用户，抄送，密送。
git send-email: 把刚才生成的patch文件直接以email的方式发送出去，要用这个命令需要保证正确配置了SMTP服务器的相关信息。用git直接生成patch邮件发送到邮件列表是一个很方便的方式，而且可以保证发出来的邮件有比较统一的格式，方便别人来审阅你的patch。

--[no-]chain-reply-to
           If this is set, each email will be sent as a reply to the previous email sent. If disabled with "--no-chain-reply-to", all emails after the first will be sent as replies to the first email sent. When using this, it is recommended that the first file given be an overview of the entire patch series. Disabled by default, but the sendemail.chainreplyto configuration variable can be used to enable it.

--[no-]thread
               If this is set, the In-Reply-To and References headers will be added to each email sent. Whether each mail refers to the previous email (deep threading per git format-patch wording) or to the first email (shallow threading) is governed by "--[no-]chain-reply-to".
               If disabled with "--no-thread", those headers will not be added (unless specified with --in-reply-to). Default is the value of the sendemail.thread configuration value; if that is unspecified, default to --thread.

               It is up to the user to ensure that no In-Reply-To header already exists when git send-email is asked to add it (especially note that git format-patch can be configured to do the threading itself). Failure to do so may not produce the expected result in the recipient’s MUA.

--annotate
           Review and edit each patch you’re about to send. See the CONFIGURATION section for sendemail.multiedit.

使用smtp发送邮件：

git config file应有如下内容.
[sendmail]
        smtpencryption = tls
        smtppass       = xxxx
        smtpserver     = smtp.gmail.com
        smptuser = [e-mail]
        smtpserverport = 587

git send-email *patch: 使用imap协议将patch作为邮件依次发到指定的imap服务器的文件夹中。

使用imap发送邮件：

git config file应有如下内容，如果你的imap服务器没有启用SSL，就无需配置最后两行。

[imap]  folder = "[Gmail]/Drafts"  host = imaps://imap.gmail.com  user = [e-mail]  pass = p4ssw0rd  port = 993  sslverify = false

git send-email --to $mail-address --no-chain-reply-to --thread --annotate ../patch/*

24.git rm

git rm:         从Git 中移除某个文件，就必须要从已跟踪文件清单中移除，然后提交。git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
git rm -f:      如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f（即 force 的首字母），以防误删除文件后丢失修改的内容。
git rm --cached readme.txt:
        我们想把文件从 Git 仓库中删除，但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。

25.git mv
git mv README.txt README:       移动或修改名字

26.rebase
它的原理是回到两个分支最近的共同祖先，根据当前分支后续的历次提交对象，生成一系列文件补丁，然后以基底分支最后一个提交对象为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象，从而改写提交历史，使它成为当前分支分支的直接下游

git rebase --onto master server client:
        取出 client 分支，找出 client 分支和 server 分支的共同祖先之后的变化，然后把它们在 master 上重演一遍
git rebase [主分支] [特性分支]:
        命令会先取出特性分支 server，然后在主分支master上重演

一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作

27.git stash
储藏可以获取你工作目录的中间状态——也就是你修改过的被追踪的文件和暂存的变更——并将它保存到一个未完结变更的堆栈中，随时可以重新应用。

git stash list: 查看现有的储藏
git stash apply:重新应用你刚刚实施的储藏。
git stash apply stash@{2}: 应用更早的储藏，可以通过名字指定它。如果你不指明，Git 默认使用最近的储藏并尝试应用它.
git stash apply --index: 对文件的变更被重新应用，但是被暂存的文件没有重新被暂存。
git stash drop: 你希望移除的储藏的名字：        一处目标储藏。
apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上。要移除它，你可以运行
git stash pop:  重新应用储藏，同时立刻将其从堆栈中移走。
git stash branch testchanges:
        如果你储藏了一些工作，暂时不去理会，然后继续在你储藏工作的分支上工作，你在重新应用工作时可能会碰到一些问题。如果尝试应用的变更是针对一个你那之后修改过的文件，你会碰到一个归并冲突并且必须去化解它。如果你想用更方便的方法来重新检验你储藏的变更，你可以运行 git stash branch，这会创建一个新的分支，检出你储藏工作时的所处的提交，重新应用你的工作，如果成功，将会丢弃储藏。

27.git blame
git blame -L 12,22 simplegit.rb:        显示simplegit.rb文件12,22行的出处。如果你在追踪代码中的缺陷想知道这是什么时候为什么被引进来的，文件标注会是你的最佳工具。它会显示文件中对每一行进行修改的最近一次提交。因此，如果你发现自己代码中的一个方法存在缺陷，你可以用git blame来标注文件，查看那个方法的每一行分别是由谁在哪一天修改的。
git blame -C:   如果代码片段是从其他地方拷贝过来的话,Git会分析你在标注的文件然后尝试找出它的原始出处.

28.git submodule
git submodule add:      将外部项目加为子模块
git submodule add git://github.com/chneukirchen/rack.git rack:
        现在在项目里的rack子目录下有了一个 Rack 项目。你可以进入那个子目录，进行变更，加入你自己的远程可写仓库来推送你的变更，从原始仓库拉取和归并等等。.gitmodules文件。这是一个配置文件，保存了项目URL和你拉取到的本地子目录.

29.git cat-file
git cat-file -p:        输出数据的内容
git cat-file -t:        让Git返回任何对象的类型
git cat-file -s:        让Git返回任何对象的大小

30.git request-pull

git request-pull branch-name url：branch-name为本地特性分支开始前的原始分支，url是请求对方来抓取的git仓库url.

31.git mailinfo

git mailinfo msg patch < /path/filename.eml

分析邮件，把xommit log写到msg文件，补丁写道patch文件，其他信息打印到标准输出

32.

git使用一段时间之后，仓库会越来越大，需要隔一段时间就手工（或自动，可用git config配置）执行命令来优化:

git-gc

git-prune

git-fsck

33. git clean

Remove untracked files from the working tree

git clean -f -d  remove directories

git clean -f -X remove ignored files

git clean -f -x remove ignored as well as non-ignored files

Note the case difference on the X for the two latter commands.

If clean.requireForce is set to "true" (the default) in your configuration, then unless you specify -fnothing will actually happen, with a recent enough version of git.

34. git reflog

管理reflog信息，可用于恢复历史状态

git reflog show  <ref> 显示ref对应的修改历史

git reset --hard <ref>@{n} 去重置到ref的前n次改变