10 个迅速提升你 Git 水平的提示 已翻译 100%

oschina 投递于 2014/08/18 06:54 (共 12 段, 翻译完成于 08-20)
阅读 79961
收藏 740
Git
76
加载中

最近我们推出了两个教程:熟悉Git的基本功能让你在开发团队中熟练的使用Git . 我们所讨论的命令足够一个开发者在Git使用方面游刃有余。在这篇文章中,我们试图探索怎样有效的管理你的时间和充分的使用Git提供的功能。

注:本文中,一些命令包含了方括号中的部分内容(例如:git add -p [file_name]).在这些示例中,你将插入必要的数字、标示符等等,如果没有方括号。

漠天
漠天
翻译于 2014/08/18 09:24
5

1. Git自动补全

假使你使用命令行工具运行Git命令,那么每次手动输入各种命令是一件很令人厌烦的事情。
为了解决这个问题,你可以启用Git的自动补全功能,完成这项工作仅需要几分钟。

为了得到这个脚本,在Unix系统下运行以下命令:

cd ~
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash

然后,添加下面几行到你的 ~/.bash_profile 文件中:

if [ -f ~/.git-completion.bash ]; then
    . ~/.git-completion.bash
fi

尽管早些时候我们已经提到这个,但是强调的不够充分。如果你想使用git的全部功能特性,
你绝对应该切换到命令行界面!

quentingui
quentingui
翻译于 2014/08/19 08:14
2

2. 在 Git 中忽略文件

你是不是很烦那些编译过的文件 (比如 .pyc) 出现在你的 Git 仓库中?或者说你已经受够了已经把它们都加进了 Git 仓库?好了,这有个办法可以让你告诉 Git 忽略掉那些特定的文件和文件夹。只需要创建一个名为 .gitignore 然后列出那些你不希望 Git 跟踪的文件和文件夹。你还可以添加例外,通过使用感叹号(!)。

*.pyc
*.exe
my_db_config/

!main.pyc
开源中国匿名会员
开源中国匿名会员
翻译于 2014/08/19 10:43
1

3. 是谁弄乱了我的代码?

当事情出错时,先去指责别人是人类的天性之一。如果你的产品服务器挂了,使用git blame命令可以很容易找出罪魁祸首。这个命令可以将文件中的每一行的作者、最新的变更提交和提交时间展示出来。

git blame [file_name]

git blame demonstration

在下面的截图中你可以看到命令是如何在更大的目录中搜寻。

git blame on the ATutor repository

0x0bject
0x0bject
翻译于 2014/08/18 11:22
2

4. 查看仓库历史记录

上一节我们已经学习了如何使用 git log ,不过,这里还有三个你应该知道的选项。

  • --oneline- 压缩模式,在每个提交的旁边显示经过精简的提交哈希码和提交信息,以一行显示。

  • --graph- 图形模式,使用该选项会在输出的左边绘制一张基于文本格式的历史信息表示图。如果你查看的是单个分支的历史记录的话,该选项无效。

  • --all- 显示所有分支的历史记录

把这些选项组合起来之后,输出看起来会像这样:

Use of git log with all, graph and oneline

开源中国匿名会员
开源中国匿名会员
翻译于 2014/08/19 10:35
3

5. 绝对不要丢失对Commit的跟踪

假设你不小心提交了些你不想要的东西,不得不做一次强制重置来恢复到之前的状态。然后,你意识到在这一过程中你丢失了其它一些信息并且想要把它们找回来,或者至少瞅一眼。这正是git reflog可以做到的。

一个简单的git log命令可以为你展示最后一次commit,以及它的父亲,还有它父亲的父亲等等。而git reflog则列出了head曾经指向过的一系列commit。要明白它们只存在于你本机中;而不是你的版本仓库的一部分,也不包含在push和merge操作中。

如果我运行git log命令,我可以看到一些commit,它们都是我仓库的一部分:

Project history

然而,一个git reflog命令则展示了一次commit (b1b0ee9–HEAD@{4}),它正是我刚才进行强制重置时弄丢的:

Git reflog

lwei
lwei
翻译于 2014/08/19 22:32
2

6. 暂存文件的部分改动

一般情况下,创建一个基于特性的提交是比较好的做法,意思是每次提交都必须代表一个新特性的产生或者是一个bug的修复。如果你修复了两个bug,或是添加了多个新特性但是却没有提交这些变化会怎样呢?在这种情况下,你可以把这些变化放在一次提交中。但更好的方法是把文件暂存(Stage)然后分别提交。

例如你对一个文件进行了多次修改并且想把他们分别提交。这种情况下,你可以在 add 命令中加上 -p 参数

git add -p [file_name]

我们来演示一下在 file_name 文件中添加了3行文字,但只想提交第一行和第三行。先看一下 git diff 显示的结果:

Changes in repo

然后再看看在 add 命令中添加 -p 参数是怎样的?

Running add with -p

看上去,Git 假定所有的改变都是针对同一件事情的,因此它把这些都放在了一个块里。你有如下几个选项:

  • 输入 y 来暂存该块

  • 输入 n 不暂存

  • 输入 e 手工编辑该块

  • 输入 d 退出或者转到下一个文件

  • 输入 s 来分割该块

在我们这个例子中,最终是希望分割成更小的部分,然后有选择的添加或者忽略其中一部分。

Adding all hunks

正如你所看到的,我们添加了第一行和第三行而忽略了第二行。之后你可以查看仓库状态之后并进行提交。

Repository after selectively adding a file

鉴客
鉴客
翻译于 2014/08/20 07:50
5

7. 压缩多个Commit

当你提交代码进行代码审查时或者创建一次pull request (这在开源项目中经常发生),你的代码在被接受之前会被要求做一些变更。于是你进行了变更,并且直到下一次审查之前你没有再次被要求进行变更过。在你知道又要进行变更之前,你已经有了一些额外的commit。理想情况下,你可以用rebase命令把多个commit压缩成一个。

git rebase -i HEAD~[number_of_commits]

如果你想要压缩最后两个commit,你需要运行下列命令。

git rebase -i HEAD~2

运行该命令时,你会看到一个交互界面,列出了许多commit让你选择哪些需要进行压缩。理想情况下,你选择最后一次commit并把其它老commit都进行压缩。

Git squash interactive

然后会要求你为新的commit录入提交信息。这一过程本质上重写了你的commit历史。

Adding a commit message

lwei
lwei
翻译于 2014/08/19 22:55
2

8. Stash未提交的更改

你正在修改某个bug或者某个特性,又突然被要求展示你的工作。而你现在所做的工作还不足以提交,这个阶段你还无法进行展示(不能回到更改之前)。在这种情况下, git stash可以帮助你。stash在本质上会取走所有的变更并存储它们为以备将来使用。stash你的变更,你只需简单地运行下面的命令-

git stash

希望检查stash列表,你可以运行下面的命令:

git stash list

Stash list

如果你想要解除stash并且恢复未提交的变更,你可以进行apply stash:

git stash apply

在屏幕截图中,你可以看到每个stash都有一个标识符,一个唯一的号码(尽管在这种情况下我们只有一个stash)。如果你只想留有余地进行apply stash,你应该给apply添加特定的标识符:

git stash apply stash@{2}

After un-stashing changes

溪边九节
溪边九节
翻译于 2014/08/19 19:14
2

9.检查丢失的提交

尽管 reflog 是唯一检查丢失提交的方式。但它不是适应用于大型的仓库。那就是 fsck(文件系统检测)命令登场的时候了。

git fsck --lost-found

Git fsck results

这里你可以看到丢掉的提交。你可以通过运行 git show [commit_hash] 查看提交之后的改变或者运行git merge [commit_hash] 来恢复到之前的提交。

git fsck 相对reflog是有优势的。比方说你删除一个远程的分支然后关闭仓库。 用fsck 你可以搜索和恢复已删除的远程分支。


长宁楚王陈涉
长宁楚王陈涉
翻译于 2014/08/19 17:42
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(70)

531432594
531432594
mark
江斌V
江斌V
干嘛要使用命令行,pycharm 关联git后要有多优雅就有多优雅~~~
whaon
whaon
不错mark
breaker_CHN
breaker_CHN
git就代表程序员的生活? 命令行就是程序员的情趣? 版本管理工具而已, 何必刻意拔高?
牛的定义是两个星期写个版本控制系统, 而不是工具用的6和命令行用的6.
breaker_CHN
breaker_CHN

引用来自“Raynor1”的评论

其实在我们团队里面我并不希望在使用git的时候都是自己打命令。。效率太低。。。太低。。。太低。。

引用来自“CWhite”的评论

只能说明你不是一个程序员,你也不懂程序员的生活。。。如果你是个程序员的上级,我为你的部下感到惭愧
呵呵了个呵呵. 照你这意思, 不会用git的都不是程序员呗?
木杉
木杉
git blame 太好用了!!!!命令如其名啊哈哈
donhui
donhui

引用来自“donhui”的评论

不错

引用来自“donhui”的评论

6. 暂存文件的部分改动 这个赞
7.压缩多个Commit 学习了
donhui
donhui

引用来自“donhui”的评论

不错
6. 暂存文件的部分改动 这个赞
donhui
donhui
不错
Fonny
Fonny

引用来自“Raynor1”的评论

其实在我们团队里面我并不希望在使用git的时候都是自己打命令。。效率太低。。。太低。。。太低。。

引用来自“CWhite”的评论

只能说明你不是一个程序员,你也不懂程序员的生活。。。如果你是个程序员的上级,我为你的部下感到惭愧
羞愧+1
返回顶部
顶部