git untracked

转自pro git ,如果你遇到untracked file这个错误，不懂什么意思，就该看看pro git的前面几章，不会花很多时间，但会弄懂原理，自己好排错。了解git status和git add的多功能用途。这里只是摘抄，方便自己查看。

总结：

1.不管暂存之前有多少状态，文件最终的状态是暂存staged，如果出现untrack或者not update的状态，就输入git add filename—— 那些未必暂存的文件。直到所有文件都是Changes to be committed:状态。staged状态下的文件，都是Changes to be commited的

2.git diff 查看的是add前和add后的差异

3.git diff --cache or git diff --staged查看的是add后的和commit后的差异。 commit提交的是在暂存区域的快照，还没add到staged区域的文件是不会被commit的。

4.注意：修改文件后，第一次add是让这个修改被跟踪，第二次add才是把文件加入到暂存区域中

跳过暂存步骤的办法，commit加-a

这样，你修改一个文件后，只需要add一下，然后输入

git commit -a

就可以了。

5.除了git merge，还可以用git rebase。它的原理是回到两个分支(你所在的分支和你想要衍合进去的分支)的共同祖先,提取你所在分支每次提交时产生的差异(diff),把这些差异分别保存到临时文件里,然后从当前分支转换到你需要衍合入的分支,依序施用每一个差异补丁文件

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

记录每次更新到仓库（查看更新状态命令：git status）

 2.2.1 检查当前文件状态

要确定哪些文件当前处于什么状态,可以用 git status 命令。如果在克隆仓库之后立即
执行此命令,会看到类似这样的输出:

图
2.1: 文件的状态变化周期
$ git status
# On branch master
nothing to commit (working directory clean)
这说明你现在的工作目录相当干净。换句话说,当前没有任何跟踪着的文件,也没有任何
文件在上次提交后更改过。此外,上面的信息还表明,当前目录下没有出现任何处于未跟踪
的新文件,否则 Git 会在这里列出来。最后,该命令还显示了当前所在的分支是 master,
这是默认的分支名称,实际是可以修改的,现在不必多虑。下一章我们就会详细讨论分支和
引用。
现在让我们用 vim 编辑一个新文件 README,保存退出后运行 git status 会看到该文件
出现在未跟踪文件列表中:
$ vim README
$ git status
# On branch master
# Untracked files:
#
(use "git add <file>..." to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use "git add" to track)
就是在“Untracked files”这行下面。Git 不会自动将之纳入跟踪范围,除非你明明白
白地告诉它这么做,因而不用担心把临时文件什么的也归入版本管理。不过现在我们确实想
要跟踪管理 README 这个文件。

2.2.2 跟踪新文件

使用命令 git add 开始跟踪一个新文件。所以,要跟踪 README 文件,运行:
$ git add README
 
Scott Chacon Pro Git
此时再运行 git status 命令,会看到 README 文件已被跟踪,并处于暂存状态:
$ git status
# On branch master
# Changes to be committed:
#
(use "git reset HEAD <file>..." to unstage)
#
# new file:
README
#
只要在 “Changes to be committed” 这行下面的,就说明是已暂存状态。如果此时提
交,那么该文件此时此刻的版本将被留存在历史记录中。你可能会想起之前我们使用 git
init 后就运行了 git add 命令,开始跟踪当前目录下的文件。git add 后可以接要跟踪的
文件或目录的路径。如果是目录的话,就说明要递归跟踪所有该目录下的文件。

2.2.3 暂存已修改文件

现在我们修改下之前已跟踪过的文件 benchmarks.rb,然后再次运行 status 命令,会看
到这样的状态报告:
$ git status
# On branch master
# Changes to be committed:
#
(use "git reset HEAD <file>..." to unstage)
#
# new file:
README
#
# Changed but not updated:
#
(use "git add <file>..." to update what will be committed)
#
# modified:
benchmarks.rb
#
文件 benchmarks.rb 出现在 “Changed but not updated” 这行下面,说明已跟踪文件
的内容发生了变化,但还没有放到暂存区。要暂存这次更新,需要运行 git add 命令(这
是个多功能命令,根据目标文件的状态不同,此命令的效果也不同:可以用它开始跟踪新文
件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态
等)。现在让我们运行 git add 将 benchmarks.rb 放到暂存区,然后再看看 git status
的输出:
$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#
(use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb

git diff（查看文件具体修改）

实际上 git status 的显示比较简单,仅仅是列出了修改过的文件,如果要查看具体修改
了什么地方,可以用 git diff 命令。现在,它已经
能回答我们的两个问题了:当前作的哪些更新还没有暂存?有哪些更新已经暂存起来准备好
了下次提交? git diff 会使用文件补丁的格式显示具体添加和删除的行。
假如再次修改 README 文件后暂存,然后编辑 benchmarks.rb 文件后先别暂存,运行
status 命令,会看到:
$ git status
# On branch master
# Changes to be committed:
#
(use "git reset HEAD <file>..." to unstage)
#
# new file:
README
#
# Changed but not updated:
#
(use "git add <file>..." to update what will be committed)
#
# modified:
#
 

此命令比较的是工作目录中当前文件和暂存区域快照之间的差异,也就是修改之后还没有
暂存起来的变化内容。
若要看已经暂存起来的文件和上次提交时的快照之间的差异,可以用 git diff --cached
命令。(Git 1.6.1 及更高版本还允许使用 git diff --staged,效果是相同的,但更好记
些。)来看看实际的效果:

请注意,单单 git diff 不过是显示还没有暂存起来的改动,而不是这次工作和上次提交
之间的差异。所以有时候你一下子暂存了所有更新过的文件后,运行 git diff 后却什么也
没有,就是这个原因。

冲突的合并

有时候合并操作并不会如此顺利。如果你修改了两个待合并分支里同一个文件的同一部
分，Git 就无法干净地把两者合到一起（译注：逻辑上说，这种问题只能由人来解决）。如
果你在解决问题 #53 的过程中修改了 hotfix 中修改的部分，将得到类似下面的结果：
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Git 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲
突，可以用 git status 查阅：
 
3.2节 基本的分支与合并
[master*]$ git status
index.html: needs merge
# On branch master
# Changed but not updated:
#
(use "git add <file>..." to update what will be committed)
#
(use "git checkout -- <file>..." to discard changes in working directory)
#
# unmerged:
index.html
#
任何包含未解决冲突的文件都会以未合并（unmerged）状态列出。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
可以看到 ======= 隔开的上半部分，是 HEAD（即 master 分支，在运行 merge 命令时
检出的分支）中的内容，下半部分是在 iss53 分支中的内容。解决冲突的办法无非是二者
选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
<div id="footer">
please contact us at email.support@github.com
</div>
这个解决方案各采纳了两个分支中的一部分内容，而且我还删除了 <<<<<<<，=======，
和>>>>>>> 这些行。在解决了所有文件里的所有冲突后，运行 git add 将把它们标记为已
解决（resolved）。因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工
具来解决这些问题，不妨运行 git mergetool，它会调用一个可视化的合并工具并引导你解
决所有冲突：
$ git mergetool
merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
Merging the files: index.html
Normal merge conflict for 'index.html':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (opendiff):
  
如果不想用默认的合并工具（Git 为我默认选择了 opendiff，因为我在 Mac 上运行了该
命令），你可以在上方“merge tool candidates（候选合并工具）”里找到可用的合并工
具列表，输入你想用的工具名。我们将在第七章讨论怎样改变环境中的默认值。
退出合并工具以后，Git 会询问你合并是否成功。如果回答是，它会为你把相关文件暂存
起来，以表明状态为已解决。
再运行一次 git status 来确认所有冲突都已解决：
$ git status
# On branch master
# Changes to be committed:
#
(use "git reset HEAD <file>..." to unstage)
#
# modified:
index.html
#
如果觉得满意了，并且确认所有冲突都已解决，也就是进入了缓存区，就可以用 git
commit 来完成这次合并提交。提交的记录差不多是这样：
Merge branch 'iss53'
Conflicts:
index.html
#
# It looks like you may be committing a MERGE.
# If this is not correct, please remove the file
# .git/MERGE_HEAD
# and try again.
#
如果想给将来看这次合并的人一些方便，可以修改该信息，提供更多合并细节。比如你都
作了哪些改动，以及这么做的原因。有时候裁决冲突的理由并不直接或明显，有必要略加注
解。