git串烧精品文

git

三种状态

• 已提交 (committed)
• 已修改 (modified)
• 已暂存 (staged)

引入git项目的三个工作区域的概念：Git仓库、工作目录、暂存区域

基本的git工作流程如下：

• 在工作目录中修改文件
• 暂存文件，将文件的快照放入暂存区域
• 提交更新，找到暂存区域的文件，将快照永久性存储到git仓库目录

git的命令行解析

新建一个git仓库

git init 即可新建一个本地仓库，然后就可以在这个仓库中进行代码版本控制，使用命令git add进行将暂存文件，最后使用git committ -m ""进行文件的提交

git clone url可以克隆远程的git仓库到自己本地使用

现在我们手上有了一个真实项目的 Git 仓库，并从这个仓库中取出了所有文件的工作拷贝。 接下来，对这些文件做些修改，在完成了一个阶段的目标之后，提交本次更新到仓库。

工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。 工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。

• 检查当前文件状态

  git status 可以看到当前的文件状态，文件所处的分支名称。如果觉得git status的输出log太过繁琐，可以使用 git status -s 或者 git status --short进行简化输出

• 跟踪新文件，如果有一个文件尚未被跟踪，可以使用git add 进行文件的跟踪添加

  注意：在使用了git add之后如果对文件又进行了修改，需要再对文件进行一次git add操作，才能把文件放至暂存区。

• 忽略文件，一般我们总有一些文件无需纳入git的管理，也不希望他们总出现在未跟踪列表，我们可以使用.gitignore

• 查看文件作了哪些修改 git diff 这个命令比较的是当前文件和暂存区域快照之间的差异

  如要查看已经暂存的将要添加到下次提交里的内容，可以使用git diff --cached 在git1.6.1以及更高的版本中也允许使用git diff --staged 效果相同，但是更好记

• 提交更新，暂存区的内容可以通过git commit 进行提交，如果没有使用-m指定相应的提交说明，则会打开文本编辑器进行说明的填写。git commit -a 可以跳过暂存，把所有跟踪过的文件进行提交。

• 当出现了，许多不希望进行管理的文件被添加到了暂存区中，我们可以使用git rm --cache fileName 进行暂存区的删除，不影响本地文件。

• git中可以使用重命名操作，即git mv filename_from filename_to，在本质上， 相当于git作了以下三个操作

  • mv README.md README
  • git rm README.md
  • git add README

• 查看提交历史 git log， 在不添加任何操作的时候，git log将会把所有的改变列出，可以添加操作，进行特殊操作：git log -p 用来提示每次做的修改。

• git log --stat 选项在每次提交的下面列出所有被修改过的文件、有多少文件被修改了以及被修改过的文件的哪些行被移除或是添加了。 在每次提交的最后还有一个总结。

但最有意思的是 format，可以定制要显示的记录格式。 这样的输出对后期提取分析格外有用 — 因为你知道输出的格式不会随着 Git 的更新而发生改变：

git log --pretty=format 常用的选项 列出了常用的格式占位符写法及其代表的意义。

选项	说明
%H	提交对象（commit）的完整哈希字串
%h	提交对象的简短哈希字串
%T	树对象（tree）的完整哈希字串
%t	树对象的简短哈希字串
%P	父对象（parent）的完整哈希字串
%p	父对象的简短哈希字串
%an	作者（author）的名字
%ae	作者的电子邮件地址
%ad	作者修订日期（可以用 --date= 选项定制格式）
%ar	作者修订日期，按多久以前的方式显示
%cn	提交者（committer）的名字
%ce	提交者的电子邮件地址
%cd	提交日期
%cr	提交日期，按多久以前的方式显示
%s	提交说明

你一定奇怪 作者和 提交者之间究竟有何差别， 其实作者指的是实际作出修改的人，提交者指的是最后将此工作成果提交到仓库的人。 所以，当你为某个项目发布补丁，然后某个核心成员将你的补丁并入项目时，你就是作者，而那个核心成员就是提交者。

• 使用git reset HEAD 可以取消暂存
• 如果不想保留尚未暂存的更改，可以使用git checkout -- filename会使用快照问价进行此文件的覆盖，将会丢失所有修改。

查看远程仓库：

• 使用git remote -v可以看到远端git仓库所使用的简写和URL
• git remote add 添加一个新的远程 Git 仓库
• 从远程仓库中获得数据，可以执行：git fetch [remote-name]
• 如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。 所以，git fetch origin 会抓取克隆（或上一次抓取）后新推送的所有工作。 必须注意 git fetch 命令会将数据拉取到你的本地仓库——它并不会自动合并或修改你当前的工作。 当准备好时你必须手动将其合并入你的工作。
• git remote show origin 可以显示远程仓库origin的细节
• git remote rename 修改git远程仓库名称，同时也会把分支名称修改

打标签

• 使用git tag可以列出已有的标签名称
• 使用git tag -a tagNum 进行标签附加
• 默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到共享服务器上。 这个过程就像共享远程分支一样——你可以运行 git push origin [tagname]。

Git分支

当使用 git commit 进行提交操作时，Git 会先计算每一个子目录（本例中只有项目根目录）的校验和，然后在 Git 仓库中这些校验和保存为树对象。 随后，Git 便会创建一个提交对象，它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。如此一来，Git 就可以在需要的时候重现此次保存的快照。

现在，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照）、一个树对象（记录着目录结构和 blob 对象索引）以及一个提交对象（包含着指向前述树对象的指针和所有提交信息）。

做些修改后再次提交，那么这次产生的提交对象会包含一个指向上次提交对象（父对象）的指针。

分支创建

Git 是怎么创建新分支的呢？ 很简单，它只是为你创建了一个可以移动的新的指针。 比如，创建一个 testing 分支， 你需要使用 git branch 命令：

$ git branch testing

这会在当前所在的提交对象上创建一个指针。

那么，Git 又是怎么知道当前在哪一个分支上呢？ 也很简单，它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git 中，它是一个指针，指向当前所在的本地分支（译注：将 HEAD 想象为当前分支的别名）。 在本例中，你仍然在 master分支上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。

你可以简单地使用 git log 命令查看各个分支当前所指的对象。 提供这一功能的参数是 --decorate。

$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project

正如你所见，当前 “master” 和 “testing” 分支均指向校验和以 f30ab 开头的提交对象。

分支切换

要切换到一个已存在的分支，你需要使用 git checkout 命令。 我们现在切换到新创建的 testing 分支去：

$ git checkout testing

这样 HEAD 就指向 testing 分支了。

那么，这样的实现方式会给我们带来什么好处呢？ 现在不妨再提交一次：

$ vim test.rb
$ git commit -a -m 'made a change'

如图所示，你的 testing 分支向前移动了，但是 master 分支却没有，它仍然指向运行 git checkout 时所指的对象。 这就有意思了，现在我们切换回 master 分支看看：

$ git checkout master

这条命令做了两件事。 一是使 HEAD 指回 master 分支，二是将工作目录恢复成 master 分支所指向的快照内容。 也就是说，你现在做修改的话，项目将始于一个较旧的版本。 本质上来讲，这就是忽略 testing 分支所做的修改，以便于向另一个方向进行开发。

那么，Git 又是怎么知道当前在哪一个分支上呢？ 也很简单，它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git 中，它是一个指针，指向当前所在的本地分支（译注：将 HEAD 想象为当前分支的别名）。 在本例中，你仍然在 master分支上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。

我们不妨再稍微做些修改并提交：

$ vim test.rb
$ git commit -a -m 'made other changes'

现在，这个项目的提交历史已经产生了分叉（参见 项目分叉历史）。 因为刚才你创建了一个新分支，并切换过去进行了一些工作，随后又切换回 master 分支进行了另外一些工作。 上述两次改动针对的是不同分支：你可以在不同分支间不断地来回切换和工作，并在时机成熟时将它们合并起来。 而所有这些工作，你需要的命令只有 branch、checkout 和 commit。

你可以简单地使用 git log 命令查看分叉历史。 运行 git log --oneline --decorate --graph --all ，它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

由于 Git 的分支实质上仅是包含所指对象校验和（长度为 40 的 SHA-1 值字符串）的文件，所以它的创建和销毁都异常高效。 创建一个新分支就相当于往一个文件中写入 41 个字节（40 个字符和 1 个换行符），如此的简单能不快吗？

这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。 完成这样繁琐的过程通常需要好几秒钟，有时甚至需要好几分钟。所需时间的长短，完全取决于项目的规模。而在 Git 中，任何规模的项目都能在瞬间创建新分支。 同时，由于每次提交都会记录父对象，所以寻找恰当的合并基础（译注：即共同祖先）也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。

Git 分支 - 分支的新建与合并

实际工作流程中，可能出现的步骤：

• 开发某个应用
• 为实现某个新的需求，创建一个分支
• 在这个分支上开展工作

正在此时，你突然接到一个电话，说有个很严重的问题需要紧急修补。你将按照如下方式来处理：

• 切换到你的线上分支
• 为这个紧急任务新建一个认知，并在其中修复它
• 在测试通过之后，切回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。

新建分支

首先为了新需求，创建一个新的分支

git chekcout -b iss53 创建一个iss53的分支，git checkout -b 和下面两条指令的作用是一样的：git branch iss53 git checkout iss53

当在iss53分支上最初了修改，并且做出了一些提交，在这个过程中iss53分支不断的向前推进

现在你接到那个电话，有个紧急问题等待你来解决。 有了 Git 的帮助，你不必把这个紧急问题和 iss53的修改混在一起，你也不需要花大力气来还原关于 53# 问题的修改，然后再添加关于这个紧急问题的修改，最后将这个修改提交到线上分支。 你所要做的仅仅是切换回 master 分支。

git checkout master
git checkout -b hotfix
...

当完成修改后，在master上将hotfix合入

git checkout master
git merge hotfix

因为master是hotfix的直接祖先，因此只需要将master的指针向前移动一位即可。

在修复了hotfix问题，并且合入master之后，应该将hotfix分支进行删除：

git branch -d hotfix

然后需要回到iss53继续工作：

git checkout iss53

当iss53任务完成后，可以返回master分支，然后将iss53进行merge，

git checkout master
git merge iss53

由于master不是iss53的直接祖先，因此可能会发生merge冲突，由于其同一代码改动了相同的地方，产生了冲突。此时需要我们自己手动解决冲突。

此时 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 ..." 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 protected]div>
=======
<div id="footer">
 please contact us at [email protected]
div>
>>>>>>> iss53:index.html

这表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因为你在运行 merge 命令的时候已经检出到了这个分支）在这个区段的上半部分（======= 的上半部分），而 iss53 分支所指示的版本在 ======= 的下半部分。 为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个，或者你也可以自行合并这些内容。 例如，你可以通过把这段内容换成下面的样子来解决冲突：

<div id="footer">
please contact us at [email protected]
div>

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

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

$ git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html

Normal merge conflict for 'index.html':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (opendiff):

如果你想使用除默认工具（在这里 Git 使用 opendiff 做为默认的合并工具，因为作者在 Mac 上运行该程序）外的其他合并工具，你可以在 “下列工具中（one of the following tools）” 这句后面看到所有支持的合并工具。 然后输入你喜欢的工具名字就可以了。

分支管理

git branch在不加任何参数的时候可以得到当前所有分支的一个列表

注意 master 分支前的 * 字符：它代表现在检出的那一个分支（也就是说，当前 HEAD 指针所指向的分支）。 这意味着如果在这时候提交，master 分支将会随着新的工作向前移动。 如果需要查看每一个分支的最后一次提交，可以运行 git branch -v 命令：

$ git branch -v
  iss53   93b412c fix javascript issue
* master  7a98805 Merge branch 'iss53'
  testing 782fd34 add scott to the author list in the readmes