git advanced application 2

 

Create new empty branch

Occasionally, you may want to keep branches that have no common ancestor with your code. For example keep the generated documentation on these branches or something. If you need to create a branch that does not use the current repository as a parent commit, you can create an empty branch as follows:

git symbolic-ref HEAD refs/heads/newbranch 
rm .git/index 
git clean -fdx 
<do work> 
git add your files 
git commit -m 'Initial commit'

Advanced branching and merging

Get assistance with conflict resolution during the merge process

git will add all changes that can be automatically merged into the index, so git diff will only show the conflicting parts. It uses an uncommon syntax:

$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,5 @@@
++<<<<<<< HEAD:file.txt
 +Hello world
++=======
+ Goodbye
++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

Recall that after we resolve the conflict, the resulting commit will have two parents instead of one: one parent will become HEAD, the tip of the current branch; the other parent will become the tip of another branch, temporarily MERGE_HEAD exists.

During the merge process, three versions of each file are kept in the index. Each of the three "file stages" represents a different version of the file:

$ git show :1:file.txt  # 两个分支共同祖先中的版本.
$ git show :2:file.txt  # HEAD中的版本.
$ git show :3:file.txt  # MERGE_HEAD中的版本.

When you use git diff to show conflicts, it performs a three-way diff between the work tree, stage 2, and stage 3, showing only those that are on both sides Chunks (in other words, when a chunk's merge result is only from stage 2, it is not displayed; the same is true for stage 3).

The above diff result shows the difference of file.txt in the working tree, staging 2 and staging 3. git does not prefix each line with a single '+' or '-', instead it uses two columns to show the difference : The first column is used to show the difference between the first parent commit and the working directory file copy, and the second column is used to show the difference between the second parent commit and the working file copy. (See "COMBINED DIFF FORMAT" in git diff-files "Get this format details.)

After resolving conflicts intuitively (but before updating the index), the diff output will look like this:

$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,1 @@@
- Hello world
-Goodbye
++Goodbye world

The output above shows that the conflict-resolved version removes "Hello world" provided by the first parent version and "Goodbye" provided by the second parent version, and then adds "Goodbye world" which is not present in either parent version .

Some special diff options allow you to diff the working directory with any of the three staging:

$ git diff -1 file.txt      # 与暂存1进行比较
$ git diff --base file.txt          # 与上相同
$ git diff -2 file.txt      # 与暂存2进行比较
$ git diff --ours file.txt          # 与上相同
$ git diff -3 file.txt      # 与暂存3进行比较
$ git diff --theirs file.txt    # 与上相同.

The git log and gitk commands also provide special assistance for merge operations:

$ git log --merge
$ gitk --merge

This will show all commits that only exist in HEAD or only in MERGE_HEAD, and those that touch unmerged files.

You can also use git mergetool , which allows you to merge files using external tools like emacs or kdiff3.

After every time you resolve the conflict, you should update the index:

$ git add file.txt

After the index update is complete, git-diff (by default) no longer shows differences for that file, so the different staging versions of that file are "folded" together.

Multiplexing

You can merge multiple heads at once by simply listing them as arguments to git merge . For example,

$ git merge scott/master rick/master tom/master

Equivalent to:

$ git merge scott/master
$ git merge rick/master
$ git merge tom/master

subtree

There are times when you want to import content from other independent development projects into your own project. You can simply pull content from other projects, provided there are no path conflicts.

Problems arise if there are conflicting files. Possible examples include Makefiles and some other standard filenames. You can choose to merge these conflicting files, but more often you don't want to merge them. A better solution The solution is to merge the external project as a subdirectory. This is not supported by the recursive merge strategy, so a simple pull is useless.

In this case, what you need is a subtree merge strategy.

In this example below, we assume you have a repository at /path/to/B (or a URL if you want). You want to merge the master branch of that repository into the dir-B sub of your current repository Under contents.

下面就是你所需要的命令序列:

$ git remote add -f Bproject /path/to/B (1)
$ git merge -s ours --no-commit Bproject/master (2)
$ git read-tree --prefix=dir-B/ -u Bproject/master (3)
$ git commit -m "Merge B project as our subdirectory" (4)
$ git pull -s subtree Bproject master (5)

子树合并的好处就是它并没有给你仓库的用户增加太多的管理负担. 它兼容于较老(版本号小于1.5.2)的客户端, 克隆完成之后马上可以得到代码.

然而, 如果你使用子模块(submodule), 你可以选择不传输这些子模块对象. 这可能在子树合并过程中造成问题.

译者注: submodule是Git的另一种将别的仓库嵌入到本地仓库方法.

另外, 若你需要修改内嵌外部项目的内容, 使用子模块方式可以更容易地提交你的修改.

 

查找问题的利器 - Git Bisect

假设你在项目的'2.6.18'版上面工作, 但是你当前的代码(master)崩溃(crash)了. 有时解决这种问题的最好办法是: 手工逐步恢复(brute-force regression)项目历史,　找出是哪个提交(commit)导致了这个问题. 但是 linkgit:git-bisect1 可以更好帮你解决这个问题:

$ git bisect start
$ git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]

如果你现在运行"git branch",　会发现你现在所在的是"no branch"(译者注:这是进行git bisect的一种状态). 这时分支指向提交（commit):"69543", 此提交刚好是在"v2.6.18"和“master"中间的位置. 现在在这个分支里,　编译并测试项目代码, 查看它是否崩溃(crash). 假设它这次崩溃了, 那么运行下面的命令:

$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings

现在git自动签出(checkout)一个更老的版本. 继续这样做, 用"git bisect good","git bisect bad"告诉git每次签出的版本是否没有问题; 你现在可以注意一下当前的签出的版本, 你会发现git在用"二分查找(binary search)方法"签出"bad"和"good"之间的一个版本(commit or revison).

在这个项目(case)中, 经过13次尝试, 找出了导致问题的提交(guilty commit). 你可以用 git show 命令查看这个提交(commit), 找出是谁做的修改，然后写邮件给TA. 最后, 运行:

$ git bisect reset

这会到你之前(执行git bisect start之前)的状态.

注意: git-bisect 每次所选择签出的版本, 只是一个建议; 如果你有更好的想法, 也可以去试试手工选择一个不同的版本.

运行: $ git bisect visualize

这会运行gitk, 界面上会标识出"git bisect"命令自动选择的提交(commit). 你可以选择一个相邻的提交(commit), 记住它的SHA串值, 用下面的命令把它签出来:

$ git reset --hard fb47ddb2db...

然后进行测试, 再根据测试結果执行”bisect good"或是"bisect bad"; 就这样反复执行, 直到找出问题为止.

译者注: 关于"git bisect start"后的分支状态, 译文和原文不一致. 原文是说执行"git bisect start"后会创建一个名为"bisect"的分支, 但是实际情况却是处于"no branch"的状态.

 

查找问题的利器 - Git Blame

如果你要查看文件的每个部分是谁修改的, 那么 git blame 就是不二选择. 只要运行'git blame [filename]', 你就会得到整个文件的每一行的详细修改信息:包括SHA串,日期和作者:

译者注: Git采用SHA1做为hash签名算法, 在本书中,作者为了表达方便,常常使用SHA来代指SHA1. 如果没有特别说明, 本书中的SHA就是SHA1的代称. $ git blame sha1_file.c ... 0fcfd160 (Linus Torvalds 2005-04-18 13:04:43 -0700 8) */ 0fcfd160 (Linus Torvalds 2005-04-18 13:04:43 -0700 9) #include "cache.h" 1f688557 (Junio C Hamano 2005-06-27 03:35:33 -0700 10) #include "delta.h" a733cb60 (Linus Torvalds 2005-06-28 14:21:02 -0700 11) #include "pack.h" 8e440259 (Peter Eriksen 2006-04-02 14:44:09 +0200 12) #include "blob.h" 8e440259 (Peter Eriksen 2006-04-02 14:44:09 +0200 13) #include "commit.h" 8e440259 (Peter Eriksen 2006-04-02 14:44:09 +0200 14) #include "tag.h" 8e440259 (Peter Eriksen 2006-04-02 14:44:09 +0200 15) #include "tree.h" f35a6d3b (Linus Torvalds 2007-04-09 21:20:29 -0700 16) #include "refs.h" 70f5d5d3 (Nicolas Pitre 2008-02-28 00:25:19 -0500 17) #include "pack-revindex.h"628522ec (Junio C Hamano 2007-12-29 02:05:47 -0800 18) #include "sha1-lookup.h" ...

如果文件被修改了(reverted),或是编译(build)失败了; 这个命令就可以大展身手了.

你也可以用"-L"参数在命令(blame)中指定开始和结束行:

$>git blame -L 160,+10 sha1_file.c 
ace1534d (Junio C Hamano 2005-05-07 00:38:04 -0700       160)}
ace1534d (Junio C Hamano 2005-05-07 00:38:04 -0700       161)
0fcfd160 (Linus Torvalds 2005-04-18 13:04:43 -0700       162)/*
0fcfd160 (Linus Torvalds 2005-04-18 13:04:43 -0700       163) * NOTE! This returns a statically allocate
790296fd (Jim Meyering   2008-01-03 15:18:07 +0100       164) * careful about using it. Do an "xstrdup()
0fcfd160 (Linus Torvalds 2005-04-18 13:04:43 -0700       165) * filename.
ace1534d (Junio C Hamano 2005-05-07 00:38:04 -0700       166) *
ace1534d (Junio C Hamano 2005-05-07 00:38:04 -0700       167) * Also note that this returns the location
ace1534d (Junio C Hamano 2005-05-07 00:38:04 -0700       168) * SHA1 file can happen from any alternate 
d19938ab (Junio C Hamano 2005-05-09 17:57:56 -0700       169) * DB_ENVIRONMENT environment variable if i

Git和Email

向一个项目提交补丁

如果你只做了少量的改动, 最简单的提交方法就是把它们做成补丁(patch)用邮件发出去:

首先, 使用git format-patch; 例如:

$ git format-patch origin

这会在当前目录生成一系统编号的补丁文件, 每一个补丁文件都包含了当前分支和origin/HEAD之间的差异内容.

然后你可以手工把这些文件导入你的Email客户端. 但是如果你需要一次发送很多补丁, 你可能会更喜欢使用git send-email脚本去自动完成这个工作. 在发送之前, 应当先到项目的邮件列表上咨询一下项目管理者, 了解他们管理这些补丁的方式.

向一个项目中导入补丁

Git也提供了一个名为git am的工具(am是"apply mailbox"的缩写)去应用那些通过Email寄来的系列补丁. 你只需要按顺序把所有包含补丁的消息存入单个的mailbox文件, 比如说"patches.mbox", 然后运行

$ git am -3 patches.mbox

Git会按照顺序应用每一个补丁; 如果发生了冲突, git会停下来让你手工解决冲突从而完成合并. ("-3"选项会让git执行合并操作; 如果你更喜欢中止并且不改动你的工作树和索引, 你可以省略"-3"选项.)

在解决冲突和更新索引之后, 你不需要再创建一个新提交, 只需要运行

$ git am --resolved

这时git会为你创建一个提交, 然后继续应用mailbox中余下的补丁.

最后的效果是, git产生了一系列提交, 每个提交是原来mailbox中的一个补丁, 补丁中的作者信息和提交日志也一并被记录下来.

 

找回丢失的对象

译者注: 原书这里只有两个链接： Recovering Lost Commits Blog Post，　 Recovering Corrupted Blobs by Linus

我根据第一个链接，整理了一篇博文，并把它做为原书补充。

在玩git的过程中，常有失误的时候，有时把需要的东东给删了。 不过没有关系，git给了我们一层安全网，让们能有机会把失去的东东给找回来。

Let's go!

准备

我们先创建一个用以实验的仓库，在里面创建了若干个提交和分支。 BTW：你可以直接把下面的命令复制到shell里执行。

mkdir recovery;cd recovery
git init
touch file
git add file
git commit -m "First commit"
echo "Hello World" > file
git add .
git commit -m "Greetings"
git branch cool_branch　
git checkout cool_branch
echo "What up world?" > cool_file
git add .
git commit -m "Now that was cool"
git checkout master
echo "What does that mean?" >> file

恢复已删除分支提交

现在repo里有两个branch

$ git branch
cool_branch
* master

存储当前仓库未提交的改动

$ git stash save "temp save"
Saved working directory and index state On master: temp save
HEAD is now at e3c9b6b Greetings

删除一个分支

$ git branch -D cool_branch
Deleted branch cool_branch (was 2e43cd5).

$ git branch
 * master

用git fsck --lost-found命令找出刚才删除的分支里面的提交对象。

$git fsck --lost-found
  dangling commit 2e43cd56ee4fb08664cd843cd32836b54fbf594a

用git show命令查看一个找到的对象的内容，看是否为我们所找的。

git show 2e43cd56ee4fb08664cd843cd32836b54fbf594a

  commit 2e43cd56ee4fb08664cd843cd32836b54fbf594a
  Author: liuhui <liuhui998[#]gmail.com>
  Date:   Sat Oct 23 12:53:50 2010 +0800

  Now that was cool

  diff --git a/cool_file b/cool_file
  new file mode 100644
  index 0000000..79c2b89
  --- /dev/null
  +++ b/cool_file
  @@ -0,0 +1 @@
  +What up world?

这个提交对象确实是我们在前面删除的分支的内容；下面我们就要考虑一下要如何来恢复它了。

使用git rebase　进行恢复

  $git rebase 2e43cd56ee4fb08664cd843cd32836b54fbf594a
  First, rewinding head to replay your work on top of it...
  Fast-forwarded master to 2e43cd56ee4fb08664cd843cd32836b54fbf594a.

现在我们用git log命令看一下，看看它有没有恢复:

  $ git log

  commit 2e43cd56ee4fb08664cd843cd32836b54fbf594a
  Author: liuhui <liuhui998[#]gmail.com>
  Date:   Sat Oct 23 12:53:50 2010 +0800

  Now that was cool

  commit e3c9b6b967e6e8c762b500202b146f514af2cb05
  Author: liuhui <liuhui998[#]gmail.com>
  Date:   Sat Oct 23 12:53:50 2010 +0800

  Greetings

  commit 5e90516a4a369be01b54323eb8b2660545051764
  Author: liuhui <liuhui998[#]gmail.com>
  Date:   Sat Oct 23 12:53:50 2010 +0800

  First commit

提交是找回来，但是分支没有办法找回来：

  liuhui@liuhui:~/work/test/git/recovery$ git branch
  * master

使用git merge　进行恢复

我们把刚才的恢复的提交删除

  $ git reset --hard HEAD^
  HEAD is now at e3c9b6b Greetings

再把刚删的提交给找回来：

  git fsck --lost-found
  dangling commit 2e43cd56ee4fb08664cd843cd32836b54fbf594a

不过这回我们用是合并命令进行恢复：

  $ git merge 2e43cd56ee4fb08664cd843cd32836b54fbf594a
  Updating e3c9b6b..2e43cd5
  Fast-forward
  cool_file |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 cool_file

git stash的恢复

前面我们用git stash把没有提交的内容进行了存储，如果这个存储不小心删了怎么办呢？

当前repo里有的存储： $ git stash list stash@{0}: On master: temp save

把它们清空： $git stash clear liuhui@liuhui:~/work/test/git/recovery$ git stash list

再用git fsck --lost-found找回来： $git fsck --lost-found dangling commit 674c0618ca7d0c251902f0953987ff71860cb067

用git show看一下回来的内容对不对：

$git show 674c0618ca7d0c251902f0953987ff71860cb067

commit 674c0618ca7d0c251902f0953987ff71860cb067
Merge: e3c9b6b 2b2b41e
Author: liuhui <liuhui998[#]gmail.com>
Date:   Sat Oct 23 13:44:49 2010 +0800

    On master: temp save

diff --cc file
index 557db03,557db03..f2a8bf3
--- a/file
+++ b/file
@@@ -1,1 -1,1 +1,2 @@@
  Hello World
  ++What does that mean?

看起来没有问题，好的，那么我就把它恢复了吧：

$ git merge 674c0618ca7d0c251902f0953987ff71860cb067
Merge made by recursive.
 file |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

备注

这篇文章主要内容来自这里：The illustrated guide to recovering lost commits with Git,我做了一些整理的工作。

如果对于文中的一些命令不熟，可以参考Git Community Book中文版

其实这里最重要的一个命令就是：git fsck --lost-found，因为git中把commit删了后，并不是真正的删除，而是变成了悬空对象（dangling commit）。我们只要把把这悬空对象（dangling commit）找出来，用git rebase也好，用git merge也行就能把它们给恢复。