git教程回顾

教程：https://mijingo.com/git-essentials
http://rogerdudler.github.io/git-guide/index.zh.html
working tree：
What is the Working Tree in Git?
The Working Tree in Git is a directory (and its files and subdirectories) on your file system that is associated with a repository.

It’s full of the files you edit, where you add new files, and from which you remove unneeded files. Any changes to the Working Tree are noted by the Index (see below), and show up as modified files.

When you open the files for a project that is being managed as a Git repository then you are access the Working Tree.

Working tree vs working directory

Working tree 并不一定是当前工作目录：
所以提出Working tree概念代替working directory。

This was done to improve consistency and avoid ambiguity. As explained in the commit that changed this behavior:

Working directory can be easily confused with the current directory.

So this change was made to better disambiguate between the working tree, meaning the location where your repository has been checked out, and a the current working directory where you are running the git status command, wich may be somewhere beneath your working tree (or perhaps not, if you set GIT_WORK_TREE environment variable).

GIT_WORK_TREE is the location of the root of the working directory for a non-bare repository. If --git-dir or GIT_DIR is specified but none of --work-tree, GIT_WORK_TREE or core.worktree is specified, the current working directory is regarded as the top level of your working tree.

What is a bare Git repository?
The standard way of initializing a new Git repository is to run git init. The directory in which you do this will be become the Working Tree for the repository.

As part of the initialization process, Git creates a .git directory (which his hidden by default because of the . in the name) that contains the repository itself. This is brains of the repository; it’s where Git tracks your changes, stores commit objects, refs, etc. You probably only rarely interact with that hidden directory.

Okay, so all of this is to lay the groundwork for understanding a bare Git repository. What the heck is it?

A bare Git repository is a repository that is created without a Working Tree. Go ahead and create one to see.

git init --bare .

Run ls on that directory and you won’t see a Working Tree but just the contents of what is typically in the .git directory.

Why this setup?

A bare Git repository is typically used as a Remote Repository that is sharing a repository among several different people. You don’t do work right inside the remote repository so there’s no Working Tree (the files in your project that you edit), just bare repository data.

And that’s it.

index（staged） working tree的快照

head

git add
DESCRIPTION
This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit. It typically adds the current content of existing paths as a whole, but with some options it can also be used to add content with only part of the changes made to the working tree files applied, or remove paths that do not exist in the working tree anymore.

The “index” holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Thus after making any changes to the working tree, and before running the commit command, you must use the add command to add any new or modified files to the index.

This command can be performed multiple times before a commit. It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run git add again to add the new content to the index.

The git status command can be used to obtain a summary of which files have changes that are staged for the next commit.

The git add command will not add ignored files by default. If any ignored files were explicitly specified on the command line, git add will fail with a list of ignored files.
（在命令行上显示添加已忽略的文件将导致添加失败）Ignored files reached by directory recursion or filename globbing performed by Git (quote your globs before the shell) will be silently ignored（递归和在shell端通配符导致的添加将会默默的忽略掉）. The git add command can be used to add ignored files with the -f (force) option.

Please see git-commit[1] for alternative ways to add content to a commit.

git rm
DESCRIPTION
Remove files from the index, or from the working tree and the index. git rm will not remove a file from just your working directory(不会只删除working directory的，不删除index中的). (There is no option to remove a file only from the working tree and yet keep it in the index; use /bin/rm if you want to do that.) The files being removed have to be identical to the tip of the branch（不懂）, and no updates to their contents can be staged in the index, though that default behavior can be overridden with the -f option. When --cached is given, the staged content has to match either the tip of the branch or the file on disk, allowing the file to be removed from just the index.

git-status - Show the working tree status
DESCRIPTION
Displays paths that have differences between the index file and the current HEAD commit（1）, paths that have differences between the working tree and the index file（2）, and paths in the working tree that are not tracked by Git（3） (and are not ignored by gitignore[5]). The first are what you would commit by running git commit; the second and third are what you could commit by running git add before running git commit.

git-diff - Show changes between commits, commit and working tree, etc

SYNOPSIS

git diff [<options>] [<commit>] [--] [<path>…​]
git diff [<options>] --cached [<commit>] [--] [<path>…​]
git diff [<options>] <commit> <commit> [--] [<path>…​]
git diff [<options>] <blob> <blob>
git diff [<options>] --no-index [--] <path> <path>

DESCRIPTION
Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes between two blob objects, or changes between two files on disk.

工作目录 vs 暂存区

$ git diff <filename>

意义：查看文件在工作目录与暂存区的差别。如果还没 add 进暂存区，则查看文件自身修改前后的差别。也可查看和另一分支的区别。

$ git diff <branch> <filename>

暂存区 vs Git仓库

git diff --cached <filename>

意义：表示查看已经 add 进暂存区但是尚未 commit 的内容同最新一次 commit 时的内容的差异。 也可以指定仓库版本：

git diff --cached <commit> <filename>

工作目录 vs Git仓库

git diff <commit> <filename>

意义：查看工作目录同Git仓库指定 commit 的内容的差异。
=HEAD 时：查看工作目录同最近一次 commit 的内容的差异。
Git仓库 vs Git仓库

git diff <commit> <commit>

意义：Git仓库任意两次 commit 之间的差别。

扩展：

1. 以上命令可以不指定 ，则对全部文件操作。 以上命令涉及和 Git仓库 对比的，均可指定 commit 的版本。

2. HEAD 最近一次 commit

3. HEAD^ 上次提交

4. HEAD~100 上100次提交 每次提交产生的哈希值

.gitignore

https://git-scm.com/docs/gitignore

.gitignore 配置文件用于配置不需要加入版本管理的文件，配置好该文件可以为我们的版本管理带来很大的便利，以下是个人对于配置 .gitignore 的一些心得。

1、配置语法：

文件 .gitignore 的格式规范如下：

所有空行或者以 ＃ 开头的行都会被 Git 忽略。

可以使用标准的 glob 模式匹配。

匹配模式可以以（/）开头防止递归。

匹配模式可以以（/）结尾指定目录。

要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。

所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。 星号（）匹配零个或多个任意字符；[abc]匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）。 使用两个星号（) 表示匹配任意中间目录，比如a/**/z 可以匹配 a/z, a/b/z 或 a/b/c/z等。

2、示例：

# no .a files
*.a

# but do track lib.a, even though you're ignoring .a files above
!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO
/TODO

# ignore all files in the build/ directory
build/

# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

# ignore all .pdf files in the doc/ directory
doc/**/*.pdf

GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表，你可以在这里 找到它.