为了账号安全,请及时绑定邮箱和手机立即绑定

Git 中级用户的25个提示

标签:
C

我使用 Git 大约已经有18个月时间,自认为能很好地驾驭它了。但是当我们请到 GitHub 的 Scott Chacon 来到 LVS 公司(一个博彩/游戏软件供应商/开发商)做专场培训时,我在第一天就学到了大量的东西。

由于有些人总是对使用 Git 自我感觉良好,因此,我想分享一些我从社区获取到的 Git 精品,这样就可能会帮助那些人无需浪费大量研究时间而直接找到答案。

图片描述

基本提示

1.安装之后第一步

安装 Git 之后,你要做的第一件事情就是去配置你的名字和邮箱,因为每一次提交都需要这些信息:

$ git config --global user.name "Some One"
$ git config --global user.email "someone@gmail.com"

2.Git 是以指针为基础

存储在 git 中的所有东西都包含在一个文件中。当你提交的时候,git 会创建一个包含提交消息和相关数据的文件(名称、邮件、日期/时间、上一次提交等等),并将其链接到一个树形文件。树形文件包含一个对象列表或者其它树。对象或二进制大数据对象(BLOB)是提交的真正内容(一个文件,如果你愿意,虽然文件名没有存储在对象中,但会存储在树中)。所有这些文件都以对象的 SHA-1 哈希为文件名进行存储。

分支和标签只是一些文件,这些文件包含(基本上)一个指向提交的 SHA-1 哈希值。使用这些引用在灵活性和速度上均有大幅提升,创建一个新的分支就和创建一个文件一样简单,只是这个文件带有分支名称和一个包含指向提交(你从这个提交建立分支)的SHA-1哈希值。当然,当你使用 Git 命令行工具(或一个图形用户界面)时,你永远也不会这么做,但它就是这么简单。

你可能已经听说过对 HEAD 的引用。它只是一个包含 SHA-1 引用的文件,这个引用指向你当前的提交。如果你正在解决一个合并冲突问题,查看一下 HEAD,你会发现,它与一个特定的分支或分支上的特定点无关,只和你现在的位置有关。

所有的分支指针保存在 .git/refs/heads 目录下,HEAD 在 .git/HEAD 目录下,标签在 .git/refs/tags 目录下 - 你可以随意看看。

3.两个 Parents - 当然!

当在日志文件中查看一个合并提交的消息时,你会看到两个 parents(与正常提交相比)。第一个parent 是你所在的分支,第二个 parents 是你并入的分支。

4.合并冲突

到目前为止,我确信你一定有一个合并冲突需要解决。通常情况下,通过编辑该文件,删除文件中的<<<<, ====, >>>>标记,然后保存你需要保留的代码就可以了。有时候,在任何变更之前查看代码都是一个值得推荐的做法,比如,在你对两个有冲突的分支采取行动之前。这是又一个命令:

$ git diff --merge
diff --cc dummy.rb  
index 5175dde,0c65895..4a00477  
--- a/dummy.rb
+++ b/dummy.rb
@@@ -1,5 -1,5 +1,5 @@@
  class MyFoo
    def say
-     puts "Bonjour"
 -    puts "Hello world"
++    puts "Annyong Haseyo"
    end
  end

如果文件是二进制的,文件比较就不是那么容易了...你通常要做的是尝试每个版本的二进制文件,并决定使用哪一个(或者在二进制文件编辑器手动复制部分内容)。从一个特定分支下 pull 一个文件副本(如果你要合并主分支和分支132的话):

$ git checkout master flash/foo.fla # or...
$ git checkout feature132 flash/foo.fla
$ # Then...
$ git add flash/foo.fla

另一种方法是从 git 中查看这个文件 - 你能够以其他文件名的方式进行查看,然后将正确的文件(当你确定它是哪一个时)复制到正常的文件名中:

$ git show master:flash/foo.fla > master-foo.fla
$ git show feature132:flash/foo.fla > feature132-foo.fla
$ # Check out master-foo.fla and feature132-foo.fla
$ # Let's say we decide that feature132's is correct
$ rm flash/foo.fla
$ mv feature132-foo.fla flash/foo.fla
$ rm master-foo.fla
$ git add flash/foo.fla

更新:感谢 Carl 在早先的的博客评论中给与的提醒,你实际上能使用 “git checkout —ours flash/foo.fla” 和 “git checkout —theirs flash/foo.fla” 检出一个特定的版本而不需要记住你要合并到哪一个分支。我个人更喜欢更明确些,但是你可以随便选择...

在解决了合并冲突问题之后(就像我上面所做的那样),请记得将这个文件添加给索引。

服务器、分支和标签

5.远程服务器

Git 最强大的功能之一是可以有一个以上的远程服务器(另一个事实,你总是可以运行一个本地仓库)。你不一定总是需要写访问权限,你可以从多个服务器中读取(用于合并),然后写到另一个服务器中。添加一个远程服务器很简单:

$ git remote add john git@github.com:johnsomeone/someproject.git

如果你想查看远程服务器的相关信息,你可以这样做:

# shows URLs of each remote server
$ git remote -v 

# gives more details about each
$ git remote show name 

你可以查看本地分支和远程分支之间的差别:

$ git diff master..john/master

你也能查看不在远程分支上的 HEAD 的变化:

$ git log remote/branch..
# Note: no final refspec after ..

6.标签

在 Git 中存在两种类型的标签 - 一个轻量级标签和一个注解标签。记着第二个提示中说过 Git 是基于指针的,二者的区别很简单。一个轻量级标签无非是一个指向提交的具名指针。你可以改变它并指向另一个提交。一个注解标签是一个指向标签对象的具名指针,这个标签对象拥有自己的消息和历史。如果有需要,标签对象的消息可以采用 GPG 加密签名。

创建两种类型的标签其实很容易(只是一个命令行选项的差异)

$ git tag to-be-tested
$ git tag -a v1.1.0 # Prompts for a tag message

7.创建分支

在 Git 中创建分支非常容易(闪电般的速度,因为它仅仅需要创建一个不到100字节的文件)。创建一个新分支并切换过去的通用写法是:

$ git branch feature132
$ git checkout feature132

当然,如果你知道你要马上切换过去,你可以使用一条命令就能做到:

$ git checkout -b feature132

如果你要重命名一个本地分支,同样是件容易的事(长命令方式用来显示具体执行过程):

$ git checkout -b twitter-experiment feature132
$ git branch -d feature132

更新:或者你(就像 Brian Palmer 在博客文章评论中指出的那样)只使用 “git branch” 和 -m 选项就可以一步到位:

$ git branch -m twitter-experiment
$ git branch -m feature132 twitter-experiment

8.合并分支

在将来某个时候,你想要合并你的变更。有两种方式可以实现:

$ git checkout master
$ git merge feature83 # Or...
$ git rebase feature83

mergerebase 的区别在于,merge 试图解决变更而且创建一个融合后的新提交,而rebase则试图把自你上次在其他分支上的变化,在另一个分支的 HAED 上重现。但是,在你向远程服务器推送一个分支之后,不要进行rebase 操作 - 这会引发混淆/问题。

如果你不能确定哪些分支仍然有独立的工作在进行 - 以便你能知道你需要合并哪一个分支以及删除哪些分支,git branch 命令有两个选项可以帮助实现这一点:

# Shows branches that are all merged in to your current branch
$ git branch --merged

# Shows branches that are not merged in to your current branch
$ git branch --no-merged

9.远程分支

如果你有一个本地分支,你想让它出现在远程服务器上,你可以使用一个推送命令:

$ git push origin twitter-experiment:refs/heads/twitter-experiment
# Where origin is our server name and twitter-experiment is the branch

更新:感谢 Erlend 在博客文章评论中提到的 - 这实际上和 git push origin twitter-experiment 达到的效果的一样,但是通过使用全部语法,你能看到你实际上在两端使用了不同的名字(你的本地名字可能是 add-ssl-support,而远程名字可能是 issue-1723)。

如果你想删除一个远程服务器上的分支(请注意分支名称之前的冒号):

$ git push origin :twitter-experiment

如果你想显示所有远程分支的状态,你能像这样查看它们:

$ git remote show origin

这可能会列出一些服务器上曾经有过但现在已不存在的分支。如果碰到这种情况,你可以很轻松地使用如下命令从本地检出并将其删除:

$ git remote prune

最后,如果你有一个远程分支,你想在本地进行跟踪它,通常的做法是:

$ git branch --track myfeature origin/myfeature
$ git checkout myfeature

然而,如果你使用 -b 标识符去检出的话,新版的 Git 会自动建立跟踪:

$ git checkout -b myfeature origin/myfeature
在临时存放区、索引和文件系统中保存内容

10.临时存放(Stashing)

在Git中,你可以把当前的工作状态储存在一个临时的存储区域堆栈,然后重新加以利用。简单的案例如下:

$ git stash # Do something...
$ git stash pop

很多人推荐使用 git stash apply 来代替 “pop”,然而如果你真这么做的话,你最终得到一个长长的毫无用处的储藏清单。如果对它进行清理,“pop” 只会把它从堆栈中删除。如果你已经使用了 git stash apply ,你可以使用如下命令从堆栈中删除最后一项:

$ git stash drop

Git 会基于当前的提交消息自动创建一个注释信息。如果你更喜欢使用一个自定义的消息(因为它可能和之前的提交无关):

$ git stash save "My stash message"

如果你想从你的列表中(不必是最后一个)对一个特定的 stash 加以利用,你可以列出它们并像这样来使用它:

$ git stash list
  stash@{0}: On master: Changed to German
  stash@{1}: On master: Language is now Italian
$ git stash apply stash@{1}

11.交互式添加

在 Subversion 的世界里,你修改文件然后只是提交有变化的文件。而在 Git 的世界里,你在提交某些文件甚至某些补丁上有更多的控制权。为了提交某些文件或者文件的某些部分,你必须进入交互模式。

$ git add -i
           staged     unstaged path

*** Commands ***
  1: status      2: update   3: revert   4: add untracked
  5: patch      6: diff     7: quit     8: help
What now>  

这会让你进入一个基于交互式命令的菜单模式。你可以使用命令的数字符号或者加亮字符(如果你开启颜色高亮显示功能的话)进入对应模式,然后就是正常输入文件数的问题了(你可以使用像1或1-4或2,4,7这样的格式)。

如果你想进入修补模式(交互模式下输入‘p’或‘5’ ),你也可以直接进入那个模式:

$ git add -p    
diff --git a/dummy.rb b/dummy.rb  
index 4a00477..f856fb0 100644  
--- a/dummy.rb
+++ b/dummy.rb
@@ -1,5 +1,5 @@
 class MyFoo
   def say
-    puts "Annyong Haseyo"
+    puts "Guten Tag"
   end
 end
Stage this hunk [y,n,q,a,d,/,e,?]?  

如你所见,在底部你得到一系列选项为选择去添加文件改变的部分,这个文件的所有变化等等。使用‘?’ 命令可以了解选不同选项的解释。

12.存储/从文件系统检索

一些项目(例如 Git 项目自身)直接在 Git 文件系统中存储额外的文件而不必是检入文件。

让我们开始在 Git 中存储一个任意文件:

$ echo "Foo" | git hash-object -w --stdin
51fc03a9bb365fae74fd2bf66517b30bf48020cb  

此时,该文件对象已在数据库中,但是如果你不设置(一些东西)指向那个文件对象,它将被作为垃圾而回收。最简单的方法是标记它:

$ git tag myfile 51fc03a9bb365fae74fd2bf66517b30bf48020cb

既然在这里我们已经标记了 myfile。当我们需要获取该文件时,我们可以这样做:

$ git cat-file blob myfile

程序员可能经常用到的工具文件(密码、GPG 密钥、等等),不需要每次都检出到磁盘上(特别是在生产环境下),这种方法非常有效。

日志记录

13.查看日志

如果你不使用‘git log’查看最近提交历史的话,你就不能长时间顺利地使用 Git。但是,也存在一些如何更好使用它的建议。例如,你可以查看每次提交中改变的一个补丁:

$ git log -p

或者你可以只是查看一个哪些文件有所更改的概述:

$ git log --stat

你可以在一行中设置一个不错的别名,用于显示简短的提交和漂亮的带有消息的分支图(像 gitk,但在命令行上):

$ git config --global alias.lol "log --pretty=oneline --abbrev-commit --graph --decorate"
$ git lol
* 4d2409a (master) Oops, meant that to be in Korean
* 169b845 Hello world

14.检索日志

如果你想在日志中查询一个特定作者,你可以这样指定:

$ git log --author=Andy

更新:感谢 Johannes 的评论,我终于化解了一部分困惑。

或者如果你有一个搜索词出现在提交消息中:

$ git log --grep="Something in the message"

还有一个功能更强大的叫 pickaxe 的命令,它可以查找条目用来添加或删除一个特定的内容(也就是,当它第一次出现或被删除的时候)。这样你就可以知道何时增加了一行(但是如果那一行中的字符随后被改变,你将无从得知):

$ git log -S "TODO: Check for admin status"

如果你改变一个特定的文件会怎么样呢,例如 lib/foo.rb

$ git log lib/foo.rb

比如说你有一个 feature/132 分支和一个feature/145 分支,你想查看在这些分支但却不在主分支上的提交(备注:^ 代表非):

$ git log feature/132 feature/145 ^master

你也可以使用 ActiveSupport 风格的日期缩小日期范围:

$ git log --since=2.months.ago --until=1.day.ago

它默认使用 OR 模式来组合查询,但是你也可以很轻松地改为 AND 模式(如果你的查询项不止一个的话)

$ git log --since=2.months.ago --until=1.day.ago --author=andy -S "something" --all-match

15.选择查看/修改的版本

当引用一个修订版本时,你有许多选项可以选择,当然,这取决于你对此功能的了解程度:

$ git show 12a86bc38 # By revision
$ git show v1.0.1 # By tag
$ git show feature132 # By branch name
$ git show 12a86bc38^ # Parent of a commit
$ git show 12a86bc38~2 # Grandparent of a commit
$ git show feature132@{yesterday} # Time relative
$ git show feature132@{2.hours.ago} # Time relative

请注意,和上一节有所不同,在行尾的脱字符表示提交的 parent - 行首的脱字符则表示不在这个分支上。

16.选择一个范围

最简单的方法是这样来用:

$ git log origin/master..new
# [old]..[new] - everything you haven't pushed yet

你也可以删除[new],这将使用当前的 HEAD

时间回退和错误修复

17.重置更改

如果你还没有提交一个更改,你可以很容易地重置它:

$ git reset HEAD lib/foo.rb

通常使用‘unstage’作为别名比较好,因为它不是那么显而易见。

$ git config --global alias.unstage "reset HEAD"
$ git unstage lib/foo.rb

如果你已经提交了文件,你可以做两件事情 - 如果是最后一次提交,你可以这样来修改:

$ git commit --amend

这将回滚到最后一次提交,让你的工作副本回到变化存储在暂存区的状态,你可以编辑提交消息准备下一次提交。

如果你的提交不止一次,并且只想完全回滚它们,你可以重置分支回到之前的时间点。

$ git checkout feature132
$ git reset --hard HEAD~2

如果你真的想把分支指向一个完全不同的 SHA-1(也许你把一个分支的 HEAD 指向另一个分支,或者进一步提交),你可以按照以下方式去做:

$ git checkout FOO
$ git reset --hard SHA

实际上还有一种更便捷的方式(因为它不会先将你的工作副本变回最初 FOO 状态,然后再指向SHA):

$ git update-ref refs/heads/FOO SHA

18. 提交到错误的分支

好吧,让我们假设你提交到主分支,但应该已经创建了一个叫做 experimental 的主题分支。为了移除这些变化,你可以在当前点创建一个分支,回退 HEAD,然后检出新的分支:

$ git branch experimental   # Creates a pointer to the current master state
$ git reset --hard master~3 # Moves the master branch pointer back to 3 revisions ago
$ git checkout experimental

如果你已经在一个分支的一个分支的一个分支等上面做了些变更,这将会更复杂。然后你需要做的就是在这个分支上将其变更 rebase 到另一个的地方:

$ git branch newtopic STARTPOINT
$ git rebase oldtopic --onto newtopic

19. 交互式 rebasing

这是一个很酷的特性,我之前已看过演示,但当时没有真正搞明白,现在来看其实很简单。比方说,你已做了3次提交,但是你想对它们进行重新排序或者编辑(或者合并它们):

$ git rebase -i master~3

然后你将编辑器打开。你所要做的就是修改 “pick/squash/edit 的指令来进行如何提交,然后保存/退出。在编辑之后,你可以使用 git rebase —continue 让你的每一个指令一个一个进行。

如果你选择编辑一个文件,这会让你停留在你提交时的状态,因此你需要使用 git commit —amend 对它进行编辑。

备注:在 REBASE 过程中不要进行提交工作 - 只能添加然后使用 —continue, —skip or —abort 选项。

20.清理

如果你已经提交了一些内容到你的分支中(也许你是从SVN中的旧代码库导入的),你想从历史中删除掉所有的已提交内容:

$ git filter-branch --tree-filter 'rm -f *.class' HEAD

如果你已经向远程服务器推送过代码,但自那之后提交的都是一些垃圾,在推送之前你可以在本地系统上执行这样的操作:

$ git filter-branch --tree-filter 'rm -f *.class' origin/master..HEAD
各种各样的提示

21.之前你看过的引用

如果你知道你之前已经查看过一个 SHA-1,但是你已经做了一些重置/回退工作,你可以使用 reflog 命令去查看你最近看过的 SHA-1

$ git reflog
$ git log -g # Same as above, but shows in 'log' format

22.分支命名

一个可爱的小提示 - 请记住,分支的名字并不局限于 a-z 和 0-9 这些字符。名字中可以使用/. 来伪装命名空间或者版本号,例如:

$ # Generate a changelog of Release 132
$ git shortlog release/132 ^release/131
$ # Tag this as v1.0.1
$ git tag v1.0.1 release/132

23. 寻找谁是始作俑者

寻找谁更改了一个文件中的一行代码经常会用到。简单命令如下:

$ git blame FILE

有时更改来自于前一个文件(如果你已经合并了两个文件,或者你已经移动了一个函数),因此你可以这样用:

$ # shows which file names the content came from
$ git blame -C FILE

有时通过向前或向后点击来进行变化跟踪,这是很好的方法。有一个内置的 GUI 程序专门为此设计:

$ git gui blame FILE

24.数据库维护

Git 通常不需要大量维护,它基本上可以自我维护。然而,你可以使用如下命令查看数据库统计信息:

$ git count-objects -v

如果数值很高,你可以选择使用垃圾回收你的重复内容。这不会影响推送或者其它用户,但却可以让你的命令运行更快且占用更少空间:

$ git gc

经常运行一致性检查也是值得推荐的做法:

$ git fsck --full

你也可以在行尾添加一个 —auto 参数(如果你频繁运行它,或者在你的服务器上每日从 crontab 中运行它),如果统计数据表明必须进行要进行一致性检查,只要fsck命令就行。

如果检查 “dangling” 或 “unreachable” 的结果一切正常,这经常是由于回退 HEADrebasing的结果。如果检查“missing” 或 “sha1 mismatch” 出了问题...寻求专业帮助吧!

25.恢复一个丢失的分支

如果你使用-D 选项删除了一个分支 experimental,你可以重新创建它:

$ git branch experimental SHA1_OF_HASH

你可以使用 git reflog 来发现一个 SHA-1 哈希值,如果你近期访问过它的话。

另一种方法是使用git fsck —lost-found。一个悬空的提交就是一个lost HEAD(它只会是一个已删除分支的 HEAD,因为当一个 HEAD^HEAD 引用时,它就没有悬空)

作者: Andy Jeffries,Ruby on Rails 开发者 & 跆拳道教练,生活在英国伦敦。
原文: 25 Tips for Intermediate Git Users(2009)
感谢: Jodoo 帮助审阅并完成校对。
译文源自:http://www.ituring.com.cn/article/202419

相关文章

1.Git 使用规范流程

2.10 个迅速提升你 Git 水平的提示

3.简明 Git 命令速查表(中文版)

点击查看更多内容
17人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
Web前端工程师
手记
粉丝
2504
获赞与收藏
8.4万

关注作者,订阅最新文章

阅读免费教程

感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消