代码管理工具：git

起步

配置

Git 自带一个git config的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置：

1. /etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。 如果在执行git config时带上--system选项，那么它就会读写该文件中的配置变量。 （由于它是系统配置文件，因此你需要管理员或超级用户权限来修改它。）
   2.~/.gitconfig 或 ~/.config/git/config文件：只针对当前用户。 你可以传递--global选项让 Git 读写此文件，这会对你系统上所有的仓库生效。
2. 当前使用仓库的 Git 目录中的 config 文件（即.git/config）：针对该仓库。 你可以传递--local选项让 Git 强制读写此文件，虽然默认情况下用的就是它。（当然，你需要进入某个 Git 仓库中才能让该选项生效。）

每一个级别会覆盖上一级别的配置，所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。

# 查看所有的配置以及它们所在的文件
$ git config --list --show-origin
# 编辑Git配置文件
$ git config -e [--global]
# 设置提交代码时的用户信息
$ git config [--global] user.name "[name]"
$ git config [--global] user.email "[email address]"
# 配置默认文本编辑器，当 Git 需要你输入信息时会调用它。 如果未配置，Git 会使用操作系统默认的文本编辑器。
$ git config [--global] core.editor emacs
# 提交时换行符转化为LF，检出分支不做转换。统一使用LF以确保Linux和Windows均可兼容
$ git config [--global] core.autocrlf input
# 配置GIT不自动转换文件权限，保留项目文件原始的执行权限
$ git config [--global] core.fileMode false
# 配置GIT不使用ssl验证，否则本地需要配置ssl相关
$ git config [--global] http.sslVerify false
#配置git的longpaths，解决git clone代码报文件名过长问题
$ git config [--global] core.longpaths true

# 来检查 Git 的某一项配置
$ git config <key>

解决git每次提交和拉取代码需要输入用户名和密码问题
输入以下命令行：

$ git config --global credential.helper store

获取帮助

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

此外，如果你不需要全面的手册，只需要可用选项的快速参考，那么可以用 -h 选项获得更简明的 “help”

$ git add -h

Git基础

工作区域

• Directory： 使用Git管理的一个目录，也就是一个仓库，包含我们的工作空间和Git的管理空间
• Workspace：工作区，本地代码存放的地方
• Index/Stage：暂存区，用于临时存放改动，事实上它只是一个文件，保存即将提交到文件列表信息
• Repository： 仓库区(本地仓库)，就是安全存放数据的位置，这里有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本。
• Remote：远程仓库，托管代码的服务器，可以简单认为是你项目组中的一台电脑用于远程数据交换

工作流程

git

• add：添加文件内容至索引

• commit：记录变更到仓库

• push ：更新远程引用和相关的对象

  • git push -u [remote] [本地分支名/commit]:[远程分支名]
    • commit可以是HEAD 或者 如master~3的commit指针
    • 强制推送--force-with-lease

• checkout：切换分支或恢复工作区文件

  # 恢复暂存区的指定文件到工作区
  $ git checkout [file]
  # 恢复暂存区的所有文件到工作区
  $ git checkout .
  # 恢复某个commit的指定文件到暂存区和工作区
  $ git checkout [commit] [file]
  # 恢复某个branch的n个版本之前的指定文件到暂存区和工作区
  $ git checkout [branch][~n] [file]
  

• reset：重置当前 HEAD指针 到指定状态，同时重置暂存区

  # 重置暂存区的指定文件，与上一次commit保持一致，但工作区不变
  $ git reset [file]
  # 重置暂存区与工作区，与上一次commit保持一致
  $ git reset --hard
  # 重置当前分支的指针为指定commit，同时重置暂存区，但工作区不变
  $ git reset [commit]
  # 重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致
  $ git reset --hard [commit]
  # 重置当前HEAD为指定commit，但保持暂存区和工作区不变
  $ git reset --keep [commit]
  

  • 删除本地提交记录的最后一条或最后N条记录：git reset --hard HEAD~1
  • 删除提交记录中的某几条：
    1. 使用命令查看提交的记录： git log
    2. 找到相应的提交ID
    3. 执行命令：git rebase -i 提交ID
    4. 进入到一个页面。
    5. 使用cw命令将行首的pick替换为drop（注意每完成一个替换操作，需要按下Esc键退出vi的编辑模式）。
       命令详解：
       • pick(p)：保留该commit
       • reword(r)：保留该commit，但我需要修改该commit 的注释
       • edit(e)：保留该commit，但我要停下来修改该提交(不仅仅修改注释)
       • squash(s)：将该commit与前一个commit合并
       • fixup(f)：将该commit和前一个commit合并，但我不要保留该提交的注释信息
       • exec(x)：执行shell命令
       • drop(d)：丢弃该commit
    6. 检查确认后，按wq保存并退出
    7. 遇到(|REBASE-m)问题的解决方法：git rebase --continue

• fetch：从另外一个仓库下载对象和引用

  • git fetch [remote] [远程分支名]:[本地分支名]

• pull：获取并整合另外的仓库或一个本地分支

  • git pull [remote] [远程分支名]:[本地分支名]

• diff：显示提交之间、提交和工作区之间等的差异

• branch：分支相关

# 新建一个commit，用来撤销指定commit
# 后者的所有变化都将被前者抵消，并且应用到当前分支
$ git revert [commit]
#暂时将未提交的变化移除，稍后再移入
$ git stash
$ git stash pop

# 显示暂存区和工作区的差异
$ git diff
# 显示暂存区和上一个commit的差异
$ git diff --cached [file]
# 显示工作区与指定分支最新提交之间的差异
$ git diff [branch]
# 显示工作区与当前分支最新commit之间的差异
$ git diff HEAD
# 显示两次提交之间的差异
$ git diff [first-branch]...[second-branch]
# 显示今天你写了多少行代码
$ git diff --shortstat "@{0 day ago}"
# 显示某次提交的元数据和内容变化
$ git show [commit]
# 显示某次提交发生变化的文件
$ git show --name-only [commit]
# 显示某次提交时，某个文件的内容
$ git show [commit]:[filename]
# 显示当前分支的最近几次提交
$ git reflog

文件状态

• Untracked：未跟踪，文件在文件夹中，但是没有加到暂存区或仓库区，不参与版本控制。通过git add 加入暂存区，状态变为Staged。
• Unmodify：文件已经加入仓库区，但未修改，即仓库区中的文件快照内容与工作区文件夹中完全一致。这类文件有两类去处：
  1. 如果文件被修改，则变为Modified；
  2. 如果使用git rm移除仓库区和暂存区，则称为Untracked文件。
• Modified：文件已修改，但没有进行其他操作。这类文件也有两类去处：
  1. 通过git add加入暂存区，变为Staged状态
  2. 使用git checkout恢复仓库区的文件快照，覆盖当前修改，返回到unmodify状态
• Staged：暂存状态。
  1. 执行git commit将暂存区同步到仓库中，此时若仓库中的文件与本地文件一致，则文件变为Unmodify状态；
  2. 执行git reset HEAD <filename>取消暂存，文件状态为Modified

获取Git仓库

通常有两种获取 Git 项目仓库的方式：

1. 将尚未进行版本控制的本地目录转换为 Git 仓库；
2. 从其它服务器克隆一个已存在的 Git 仓库。

两种方式都会在你的本地机器上得到一个工作就绪的 Git 仓库。

在已存在目录中初始化仓库

如果你有一个尚未进行版本控制的项目目录，想要用 Git 来控制它，那么首先需要进入该项目目录中。

# 在当前目录新建一个Git代码库
$ git init
# 新建一个目录，将其初始化为Git代码库
$ git init [project-name]

该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。 但是，在这个时候，我们仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪。 (参见Git 内部原理来了解更多关于到底 .git 文件夹中包含了哪些文件的信息。)

如果在一个已存在文件的文件夹（而非空文件夹）中进行版本控制，你应该开始追踪这些文件并进行初始提交。 可以通过git add命令来指定所需的文件来进行追踪，然后执行 git commit ：

$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'

现在，你已经得到了一个存在被追踪文件与初始提交的 Git 仓库。

克隆现有的仓库

如果你想获得一份已经存在了的 Git 仓库的拷贝，比如说，你想为某个开源项目贡献自己的一份力，这时就要用到git clone命令。

# 下载一个项目和它的整个代码历史
$ git clone [url]

Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成你的工作所需要文件。 当你执行git clone命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。 事实上，如果你的服务器的磁盘坏掉了，你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库（虽然可能会丢失某些服务器端的钩子（hook）设置，但是所有版本的数据仍在，详见在服务器上搭建 Git ）。

$ git clone https://github.com/libgit2/libgit2

这会在当前目录下创建一个名为 “libgit2” 的目录，并在这个目录下初始化一个.git文件夹， 从远程仓库拉取下所有数据放入 .git 文件夹，然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 libgit2 文件夹，你会发现所有的项目文件已经在里面了，准备就绪等待后续的开发和使用。

如果你想在克隆远程仓库的时候，自定义本地仓库的名字，你可以通过额外的参数指定新的目录名：

$ git clone https://github.com/libgit2/libgit2 mylibgit

这会执行与上一条命令相同的操作，但目标目录名变为了 mylibgit。
Git 支持多种数据传输协议。 上面的例子使用的是https:// 协议，不过你也可以使用git://协议或者使用 SSH 传输协议，比如user@server:path/to/repo.git。在服务器上搭建 Git 将会介绍所有这些协议在服务器端如何配置使用，以及各种方式之间的利弊。

查看信息

git status

git status命令的输出十分详细，但其用语有些繁琐。 Git 有一个选项可以帮你缩短状态命令的输出，这样可以以简洁的方式查看更改。 如果你使用git status -s命令或git status --short命令，你将得到一种格式更为紧凑的输出。

# 显示有变更的文件
$ git status
# 状态简览
$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

新添加的未跟踪文件前面有 ?? 标记，新添加到暂存区中的文件前面有 A 标记，修改过的文件前面有 M 标记。 输出中有两栏，左栏指明了暂存区的状态，右栏指明了工作区的状态。例如，上面的状态报告显示： README文件在工作区已修改但尚未暂存，而 lib/simplegit.rb文件已修改且已暂存。Rakefile文件已修改，暂存后又作了修改，因此该文件的修改中既有已暂存的部分，又有未暂存的部分。

git log

默认不加参数，git log显示如下：

• commit 哈希id
• 提交的Author信息
• 提交的日期和时间
• commit info信息

参考

显示参数

• --oneline 将每个commit的信息缩短为一行
• --graph会绘制一个 ASCII 图像来展示提交历史的分支结构，类似于一个树形结构，很方便很好看
• --stat：显示每次更新的修改文件的统计信息，每个提交都列出了修改过的文件，以及其中添加和移除的行数，并在最后列出所有增减行数小计。
• --shortstat：只显示--stat中最后的行数添加修改删除统计
• -p 按补丁显示每个更新间的差异，也可以显示指定文件相关的每一次diff,比–stat命令信息更全
• --name-only：只显示修改的文件清单
• --name-status：显示新增、修改和删除的文件清单
• --relative-date：使用较短的相对时间显示（例如：“two weeks ago”）
• --abbrev-commit：仅显示SHA-1哈希值的前几个字符，而非所有的40个字符
• —pretty＝：使用其他格式显示历史提交信息，可选项有：oneline,short,medium,full,fuller,email,raw以及format:<string>,默认为medium，如：
  • --pretty=oneline：一行显示，只显示哈希值和提交说明（--online本身也可以作为单独的属性）
  • --pretty=format:" "：控制显示的格式，如：
    • %H 提交对象（commit）的完整哈希字串
    • %h 提交对象的简短哈希字串
    • %T 树对象（tree）的完整哈希字串
    • %t 树对象的简短哈希字串
    • %P 父对象（parent）的完整哈希字串
    • %p 父对象的简短哈希字串
    • %an 作者（author）的名字
    • %ae 作者的电子邮件地址
    • %ad 作者修订日期（可以用 -date= 选项定制格式）
    • %ar 作者修订日期，按多久以前的方式显示
    • %cn 提交者(committer)的名字
    • %ce 提交者的电子邮件地址
    • %cd 提交日期（可以用 -date= 选项定制格式）
    • %cr 提交日期，按多久以前的方式显示
    • %s 提交说明
    • 带颜色的--pretty=format:" "，以这句为例：
      %Cred%h%Creset -%C(yellow)%d%Cblue %s %Cgreen(%cd) %C(bold blue)<%an>
      它的效果是：[%Cred%h] [%Creset -] [%C(yellow)%d ] [%Cblue%s] [%Cgreen(%cd)] [%C(bold blue)<%an>]
      然后就是很明显能得到的规律了：一个颜色＋一个内容 (颜色以％C开头，后边接几种颜色，还可以设置字体，如果要设置字体的话，要一块加个括号
      能设置的颜色值包括：reset（默认的灰色），normal, black, red, green, yellow, blue, magenta, cyan, white.
      字体属性则有bold, dim, ul, blink, reverse.
      内容可以是占位元字符，也可以是直接显示的普通字符
  • --date= (relative|local|default|iso|rfc|short|raw)：定制后边如果出现%ad或%cd时的日期格式
    有几个默认选项：
    - --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版本2.6.0以上），比如–date=format:‘%Y-%m-%d %H:%M:%S’ 会格式化成：2016-01-13 11:32:13，其他的格式化占位符如下：
    %a：Abbreviated weekday name
    %A：Full weekday name
    %b：Abbreviated month name
    %B：Full month name
    %c：Date and time representation appropriate for locale
    %d：Day of month as decimal number (01 – 31)
    %H： Hour in 24-hour format (00 – 23)
    %I：Hour in 12-hour format (01 – 12)
    %j：Day of year as decimal number (001 – 366)
    %m：Month as decimal number (01 – 12)
    %M：Minute as decimal number (00 – 59)
    %p：Current locale’s A.M./P.M. indicator for 12-hour clock
    %S：Second as decimal number (00 – 59)
    %U：Week of year as decimal number, with Sunday as first day of week (00 – 53)
    %w：Weekday as decimal number (0 – 6; Sunday is 0)
    %W：Week of year as decimal number, with Monday as first day of week (00 – 53)
    %x：Date representation for current locale
    %X：Time representation for current locale
    %y：Year without century, as decimal number (00 – 99)
    %Y：Year with century, as decimal number
    %z, %Z：Either the time-zone name or time zone abbreviation, depending on registry settings; no characters if time zone is unknown
    %%：Percent sign

筛选参数

• -n 限定前n次提交
• --author="作者"用来过滤commit,限定输出给定的用户
• --after '日-月-年'和--before '日-月-年' 限定指定日期范围的log
• --decoreate 显示对应commit所属的branch和tag信息
• -S [keyword] 根据关键词搜索提交历史
• --merges或者--no-merges控制是否显示merge的commit

按数量
    -n：显示前n条log
按日期
    --after=
        比如git log --after="2014-7-1”，显示2014年7月1号之后的commit(包含7月1号)
        后边的日期还可以用相对时间表示，比如"1 week ago"和”yesterday"，比如git log --after="yesterday"
        这里的格式可以是什么？
    --before=
        同上
        另外这两条命令可以同时使用表示时间段，比如git log --after="2014-7-1" --before="2014-7-4"
        另外--since --until和 --after --before是一个意思，都可以用
按作者
    --author=
        比如git log --author=“John"，显示John贡献的commit
        注意：作者名不需要精确匹配，只需要包含就行了
        而且：可以使用正则表达式，比如git log --author="John|Mary”，搜索Marry和John贡献的commit
        而且：这个--author不仅包含名还包含email, 所以你可以用这个搜索email
按commit描述
    --grep=
        比如：git log --grep="JRA-224"
        而且：可以传入-i用来忽略大小写
        注意：如果想同时使用--grep和--author，必须在附加一个--all-match参数
按文件
    - -（空格）或［没有］
        有时你可能只对某个文件的修改感兴趣, 你只想查看跟某个文件相关的历史信息, 你只需要插入你感兴趣文件的路径［对，是路径，所以经常是不太好用］就可以了
        比如：git log -- foo.py bar.py ，只返回和foo.py或bar.py相关的commit
        这里的--是告诉Git后面的参数是文件路径而不是branch的名字. 如果后面的文件路径不会和某个branch产生混淆, 你可以省略- -，比如git log foo.py 
        另外，后边的路径还支持正则，比如：git log  *install.md 是，指定项目路径下的所有以install.md结尾的文件的提交历史
        另外，文件名应该放到参数的最后位置，通常在前面加上--并用空格隔开表示是文件
        另外，git log file/ 查看file文件夹下所有文件的提交记录
按分支
    - -
        --branchName branchName为任意一个分支名字，查看某个分支上的提交记录
        需要放到参数中的最后位置处
        如果分支名与文件名相同，系统会提示错 误，可通过--选项来指定给定的参数是分支名还是文件名
            比如：在当前分支中有一个名为v1的文件，同时还存在一个名为v1的分支
            git log v1 -- 此时的v1代表的是分支名字（－－后边是空的）
            git log -- v1 此时的v1代表的是名为v1的文件
            git log v1 －－ v1 代表v1分支下的v1文件
按内容
    -S"<string>"、-G"<string>"
        有时你想搜索和新增或删除某行代码相关的commit. 可以使用这条命令
        假设你想知道Hello, World!这句话是什么时候加入到项目里去的，可以用：git log -S"Hello,World!"
        另外：如果你想使用正则表达式去匹配而不是字符串, 那么你可以使用-G代替-S.
        这是一个非常有用的debug工具, 使用他你可以定位所有跟某行代码相关的commit. 甚至可以查看某行是什么时候被copy的, 什么时候移到另外一个文件中去的
        注：-S后没有"="，与查询内容之间也没有空格符
按范围
    git log <since>..<until>
        这个命令可以查看某个范围的commit
        这个命令非常有用当你使用branch做为range参数的时候. 能很方便的显示2个branch之间的不同
        比如：git log master..feature，master..feature这个range包含了在feature有而在master没有的所有commit，同样，如果是feature..master包含所有master有但是feature没有的commit
        另外，如果是三个点，表示或的意思：git log master...test 查询master或test分支中的提交记录
过滤掉merge commit
    --no-merges
        默认情况下git log会输出merge commit.  你可以通过--no-merges标记来过滤掉merge commit，git log --no-merges
        另外，如果你只对merge commit感兴趣可以使用—merges，git log --merges
按标签tag
    git log v1.0
        直接这样是查询标签之前的commit
        加两个点git log v1.0.. 查询从v1.0以后的提交历史记录(不包含v1.0)
按commit
    git log commit ：查询commit之前的记录，包含commit
    git log commit1 commit2：查询commit1与commit2之间的记录，包括commit1和commit2
    git log commit1..commit2：同上，但是不包括commit1
        其中，commit可以是提交哈希值的简写模式，也可以使用HEAD代替
            HEAD代表最后一次提交，HEAD^为最后一个提交的父提交，等同于HEAD～1
            HEAD～2代表倒数第二次提交

# 显示某个commit之后的所有变动，每个commit占据一行
$ git log [tag] HEAD --pretty=format:%s
# 显示某个commit之后的所有变动，其"提交说明"必须符合搜索条件
$ git log [tag] HEAD --grep feature
# 显示某个文件的版本历史，包括文件改名
$ git log --follow [file]
$ git whatchanged [file]
# 按补丁显示每个更新间的差异，也可以显示指定文件相关的每一次diff,比--stat命令信息更全
$ git log -p [file]
# 显示过去5次提交
$ git log -5 --pretty --oneline
# 显示所有提交过的用户，按提交次数排序
$ git shortlog -sn
# 显示指定文件是什么人在什么时间修改过
$ git blame [file]

记录每次更新到仓库

工作目录下的每一个文件都不外乎这两种状态：已跟踪 或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后， 它们的状态可能是未修改，已修改或已放入暂存区。简而言之，已跟踪的文件就是 Git 已经知道的文件。

工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态，因为 Git 刚刚检出了它们， 而你尚未编辑过它们。
编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 在工作时，你可以选择性地将这些修改过的文件放入暂存区，然后提交所有已暂存的修改，如此反复。

跟踪新文件

# 添加指定文件到暂存区
$ git add [file1] [file2] ...
# 添加指定目录到暂存区，包括子目录
$ git add [dir]
# 添加当前目录的所有文件到暂存区
$ git add .
# 添加每个变化前，都会要求确认
# 对于同一个文件的多处变化，可以实现分次提交
$ git add -p

例子：

$ git add README
#此时再运行 git status 命令，会看到`README`文件已被跟踪，并处于暂存状态：
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

    new file:   README

只要在Changes to be committed这行下面的，就说明是已暂存状态。 如果此时提交，那么该文件在你运行git add 时的版本将被留存在后续的历史记录中。 git add命令使用文件或目录的路径作为参数；如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。

暂存已修改的文件

现在我们来修改一个已被跟踪的文件。 如果你修改了一个名为 CONTRIBUTING.md 的已被跟踪的文件，然后运行 git status 命令，会看到下面内容：

$ 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

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

文件CONTRIBUTING.md出现在Changes not staged for commit这行下面，说明已跟踪文件的内容发生了变化，但还没有放到暂存区。 要暂存这次更新，需要运行git add 命令。 这是个多功能命令： 可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。 将这个命令理解为**“精确地将内容添加到下一次提交中”**而不是“将一个文件添加到项目中”要更加合适。 现在让我们运行git add将CONTRIBUTING.md放到暂存区，然后再看看git status的输出：

$ git add CONTRIBUTING.md
$ 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
    modified:   CONTRIBUTING.md

如果此时再次修改CONTRIBUTING.md文件，CONTRIBUTING.md 文件同时出现在暂存区和非暂存区:

$ vim CONTRIBUTING.md
$ 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
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

实际上 Git 只不过暂存了你运行 git add命令时的版本。 如果你现在提交，CONTRIBUTING.md 的版本是你最后一次运行 git add 命令时的那个版本，而不是你运行 git commit 时，在工作目录中的当前版本。 所以，运行了git add之后又作了修订的文件，需要重新运行git add把最新版本重新暂存起来：

$ git add CONTRIBUTING.md
$ 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
    modified:   CONTRIBUTING.md

取消暂存

#将文件移出暂存区
$ git reset HEAD <file>...

撤销对文件的修改

#对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它
$ git checkout -- <file>

忽略文件

一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。 在这种情况下，我们可以创建一个名为.gitignore的文件，列出要忽略的文件的模式。
文件 .gitignore 的格式规范如下：

• 所有空行或者以#开头的行都会被 Git 忽略。
• 可以使用标准的 glob 模式匹配，它会递归地应用在整个工作区中。 例如foldername会匹配*/foldername、*/*/foldername
• 匹配模式可以以/开头防止递归。
• 匹配模式可以以/结尾指定目录。
• 要忽略指定模式以外的文件或目录，可以在模式前加上叹号!取反。
• 所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。
  • 星号*匹配零个或多个任意字符；
  • [abc]匹配任何一个列在方括号中的字符；
  • 问号?只匹配一个任意字符；
  • 如果在方括号中使用短划线分隔两个字符， 表示所有在这两个字符范围内的都可以匹配（比如[0-9]表示匹配所有0 到9的数字）。
  • 使用两个星号**表示匹配任意中间目录(多级目录)，比如a/**/z可以匹配a/z 、 a/b/z 或 a/b/c/z 等。

查看已暂存和未暂存的修改

此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。 也就是修改之后还没有暂存起来的变化内容。

#比较工作目录中当前文件和暂存区域快照之间的差异,也就是修改之后还没有暂存起来的变化内容
$ git diff
#比对已暂存文件与最后一次提交的文件差异
$ git diff --staged [file]
# 显示暂存区和最后一次提交的差异 （ --staged 和 --cached 是同义词）
$ git diff --cached [file]
# 显示工作区与当前分支最新commit之间的差异
$ git diff HEAD
# 显示两次提交之间的差异
$ git diff [first-branch]...[second-branch]
# 显示今天你写了多少行代码
$ git diff --shortstat "@{0 day ago}"

提交/撤销 更新

# 提交暂存区到仓库区
$ git commit -m [message]
# 提交暂存区的指定文件到仓库区
$ git commit [file1] [file2] ... -m [message]

要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤：

# 提交工作区自上次commit之后的变化，直接到仓库区
$ git commit -a
# 提交时显示所有diff信息
$ git commit -v

重新提交上一次提交使用--amend

# 使用一次新的commit，替代上一次提交
# 如果代码没有任何新变化，则用来改写上一次commit的提交信息
$ git commit --amend -m [message]
# 重做上一次commit，并包括指定文件的新变化
$ git commit --amend [file1] [file2] ...

移除文件

要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 “Changes not staged for commit” 部分（也就是 未暂存清单）。

如果要删除之前修改过或已经放到暂存区的文件，则必须使用强制删除选项 -f（译注：即 force 的首字母）。 这是一种安全特性，用于防止误删尚未添加到快照的数据，这样的数据不能被 Git 恢复。

另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。 换句话说，你想让文件保留在磁盘，但是并不想让 Git 继续跟踪。 当你忘记添加 .gitignore 文件，不小心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时，这一做法尤其有用。 为达到这一目的，使用 --cached 选项：

# 删除工作区文件，并且将这次删除放入暂存区
$ git rm [-f] [file1] [file2] ...
# 停止追踪指定文件，但该文件会保留在工作区
$ git rm --cached [file]
# git rm 命令后面可以列出文件或者目录的名字，也可以使用 glob 模式。比如：
$ git rm log/\*.log
#注意到星号 * 之前的反斜杠 \， 因为 Git 有它自己的文件模式扩展匹配方式，所以我们不用 shell 来帮忙展开。 此命令删除 log/ 目录下扩展名为 .log 的所有文件。 

移动文件

# 改名文件，并且将这个改名放入暂存区
$ git mv [file-original] [file-renamed]

远程仓库

添加远程仓库

#添加一个新的远程 Git 仓库，同时指定一个方便使用的简写
$ git remote add <shortname> <url>

查看远程仓库

# 显示所有远程仓库的简写及其链接
$ git remote -v
# 显示某个远程仓库的信息
$ git remote show [remote]

如果你已经克隆了自己的仓库，那么至少应该能看到origin——这是 Git 给你克隆的仓库服务器的默认名字。

$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin	https://github.com/schacon/ticgit (fetch)
origin	https://github.com/schacon/ticgit (push)
pb	https://github.com/paulboone/ticgit (fetch)
pb	https://github.com/paulboone/ticgit (push)

现在你可以在命令行中使用简写pb来代替整个 URL。

从远程仓库中抓取和拉取

#下载远程仓库的所有变动， 执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看。
$ git fetch [remote] [远程分支名]:[本地分支名]

# 取回远程仓库的变化，并与本地分支合并,相当于从远程仓库获得最新版本并merge到本地。
$ git pull [remote] [远程分支名]:[本地分支名]

上述命令其实相当于git fetch 加 git merge

推送到远程仓库

# 上传本地指定分支到远程仓库
$ git push [remote] [本地分支名]:[远程分支名]
# 强行推送当前分支到远程仓库，即使有冲突
$ git push [remote] --force
# 推送所有分支到远程仓库
$ git push [remote] --all

远程仓库的重命名与移除

# 修改一个远程仓库的简写名
$ git remote rename pb paul
#解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。
$ git remote rm [remote]

标签

列出标签

# 列出所有tag
$ git tag
# 按照通配符列出标签需要-l或--list
$ git tag -l "v1.8*"
# 查看tag信息
$ git show [tag]

创建标签

Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）。

轻量标签很像一个不会改变的分支——它只是某个特定提交的引用。

附注标签是存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。 通常会建议创建附注标签，这样你可以拥有以上所有信息。但是如果你只是想用一个临时的标签， 或者因为某些原因不想要保存这些信息，那么也可以用轻量标签。

附注标签

# 新建一个tag在当前commit
$ git tag -a [tag] -m "message"
# 新建一个tag在指定commit
$ git tag -a [tag] -m "message" [commit]

-m 选项指定了一条将会存储在标签中的信息。
通过使用 git show 命令可以看到标签信息和与之对应的提交信息：

轻量标签

另一种给提交打标签的方式是使用轻量标签。 轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。 创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字：

# 新建一个tag在当前commit
$ git tag [tag]
# 新建一个tag在指定commit
$ git tag [tag] [commit]

删除标签

# 删除本地tag
$ git tag -d [tag]
# 删除远程tag,下面这种操作的含义是，将冒号前面的空值推送到远程标签名，从而高效地删除它。
$ git push [remote] :refs/tags/<tagName>
# 第二种更直观的删除远程标签的方式是：
$ git push [remote] --delete <tagname>

# 提交指定tag
$ git push [remote] [tag]
# 提交所有tag
$ git push [remote] --tags
# 新建一个分支，指向某个tag
$ git checkout -b [branch] [tag]

分支

查看分支

# 列出所有本地分支
$ git branch
# 显示每一个分支最后一次提交的详细信息
$ git branch -v
# 查看已经合并到当前分支的分支
$ git branch --merged
# 查看尚未合并到当前分支的分支
$ git branch --no-merged
# 列出所有远程分支
$ git branch -r
# 列出所有本地分支和远程分支
$ git branch -a

新建分支

# 新建一个分支，但依然停留在当前分支
$ git branch [branch-name]
# 新建一个分支，指向指定commit
$ git branch [branch] [commit]

跟踪分支

从一个远程跟踪分支检出一个本地分支会自动创建所谓的“跟踪分支”（它跟踪的分支叫做“上游分支”）。 跟踪分支是与远程分支有直接关系的本地分支。 如果在一个跟踪分支上输入 git pull，Git 能自动地识别去哪个服务器上抓取、合并到哪个分支。

当克隆一个仓库时，它通常会自动地创建一个跟踪origin/master的master分支。 然而，如果你愿意的话可以设置其他的跟踪分支，或是一个在其他远程仓库上的跟踪分支，又或者不跟踪master分支。 最简单的实例就是像之前看到的那样，运行git checkout -b <branch> <remote>/<branch>。

# 从远程分支检出一个本地分支
$ git checkout -b <branch> <remote>/<branch>
$ git checkout --track <remote>/<branch>
# 新建一个分支，与指定的远程分支建立追踪关系
$ git branch --track [branch] [remote/branch]

设置已有的本地分支跟踪一个刚刚拉取下来的远程分支，或者想要修改正在跟踪的上游分支， 你可以在任意时间使用-u或--set-upstream-to选项运行git branch来显式地设置。

# 建立追踪关系，在现有分支与指定的远程分支之间
$ git branch --set-upstream [branch] [remote/branch]

切换分支

# 切换到指定分支，并更新工作区
$ git checkout [branch-name]
# 切换到上一个分支
$ git checkout -

新建并切换分支

$ git checkout -b [branch]

是下面两条命令的简写：

$ git branch [branch]
$ git checkout [branch]

删除分支

# 删除分支
$ git branch -d [branch-name]
# 删除远程分支
$ git push [remote] --delete [branch-name]
$ git branch -dr [remote/branch]

分支命名

$ git branch -m 原分支名称 新分支名称

分支的合并

# 合并指定分支到当前分支
$ git merge [branch]
# 出现fatal: 拒绝合并无关的历史时，可以使用如下命令
$ git merge [branch] --allow-unrelated-histories
# 选择一个commit，合并进当前分支
$ git cherry-pick [commit]

遇到冲突时的分支合并

有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。
此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:      index.html

no changes added to commit (use "git add" and/or "git commit -a")

任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段，看起来像下面这个样子：

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> iss53:index.html

由=======来分割冲突的两部分。为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个，或者你也可以自行合并这些内容。 例如，你可以通过把这段内容换成下面的样子来解决冲突：

<div id="footer">
please contact us at email.support@github.com
</div>

上述的冲突解决方案仅保留了其中一个分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除了。 在你解决了所有文件里的冲突之后，对每个文件使用git add命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。

如果你想使用图形化工具来解决冲突，你可以运行git mergetool，该命令会为你启动一个合适的可视化合并工具，并带领你一步一步解决这些冲突：

$ git mergetool

子模块

添加子模块

git submodule add <url> <path>

• url 为想要添加的子模块路径
• path 为子模块存放的本地路径

命令执行完会自动生成 .gitmodules里的内容并clone子模块代码

子模块初始化

git submodule init

读取.gitmodules文件并初始化本地配置文件.git/config和.git/module

更新子模块

git submodule update --remote

不带--remote的update只会在本地没有子模块或它的文件夹为空时才有效

删除子模块

git submodule deinit <path> #如果添加上参数 -f，则子模块工作区内即使有本地的修改，也会被移除:
git rm <path> #自动在.gitmodules中删除了子模块相关内容

其中<path>表示submodule的路径

clone时子模块初始化

clone父仓库时加上--recursive，会自动初始化并更新仓库中的每一个子模块

git clone --recursive

等效的做法

git clone 
git submodule update --init --recursive

重设子模块地址

git submodule set-url <path> <url>

• path 子模块本地路径
• url 子模块url地址

其他

# 生成一个可供发布的压缩包
$ git archive

github 令牌

$ git remote set-url [remote] https://<your_token>@github.com/<USERNAME>/<REPO>.git

将<your_token>换成你自己得到的令牌。<USERNAME>是你自己github的用户名，<REPO>是你的项目名称。