from : http://blog.csdn.net/fybon/article/details/51201382
from : http://www.oschina.net/translate/10-tips-git-next-level?cmp
英文原文:10 Tips to Push Your Git Skills to the Next Level
Recently we published a couple of tutorials to get you familiar with Git basics and using Git in a team environment. The commands that we discussed were about enough to help a developer survive in the Git world. In this post, we will try to explore how to manage your time effectively and make full use of the features that Git provides. Note: Some commands in this article include part of the command in square brackets (e.g. | 译者信息 最近我们推出了两个教程:熟悉Git的基本功能和让你在开发团队中熟练的使用Git . 我们所讨论的命令足够一个开发者在Git使用方面游刃有余。在这篇文章中,我们试图探索怎样有效的管理你的时间和充分的使用Git提供的功能。 注:本文中,一些命令包含了方括号中的部分内容(例如:git add -p [file_name]).在这些示例中,你将插入必要的数字、标示符等等,如果没有方括号。 |
1. Git Auto Completion
If you run Git commands through the command line, it’s a tiresome task to type in the commands manually every single time. To help with this, you can enable auto completion of Git commands within a few minutes. To get the script, run the following in a Unix system: Next, add the following lines to your Although I have mentioned this earlier, I can not stress it enough: If you want to use the features of Git fully, you should definitely shift to the command line interface! | 译者信息 |
1. Git自动补全
假使你使用命令行工具运行Git命令,那么每次手动输入各种命令是一件很令人厌烦的事情。 然后,添加下面几行到你的 ~/.bash_profile 文件中: 尽管早些时候我们已经提到这个,但是强调的不够充分。如果你想使用git的全部功能特性, |
2. Ignoring Files in Git
Are you tired of compiled files (like
| 译者信息 |
2. 在 Git 中忽略文件
你是不是很烦那些编译过的文件 (比如 .pyc) 出现在你的 Git 仓库中?或者说你已经受够了已经把它们都加进了 Git 仓库?好了,这有个办法可以让你告诉 Git 忽略掉那些特定的文件和文件夹。只需要创建一个名为 .gitignore 然后列出那些你不希望 Git 跟踪的文件和文件夹。你还可以添加例外,通过使用感叹号(!)。
|
3. Who Messed With My Code?
It’s the natural instinct of human beings to blame others when something goes wrong. If your production server is broke, it’s very easy to find out the culprit — just do a
And in the screenshot below, you can see how this command would look on a bigger repository:
| 译者信息 |
3. 是谁弄乱了我的代码?
当事情出错时,先去指责别人是人类的天性之一。如果你的产品服务器挂了,使用git blame命令可以很容易找出罪魁祸首。这个命令可以将文件中的每一行的作者、最新的变更提交和提交时间展示出来。 git blame [file_name]
在下面的截图中你可以看到命令是如何在更大的目录中搜寻。
|
4. Review History of the Repository
We had a look at the use of
Here’s what a combination of the options looks like:
| 译者信息 |
4. 查看仓库历史记录
上一节我们已经学习了如何使用 git log ,不过,这里还有三个你应该知道的选项。
把这些选项组合起来之后,输出看起来会像这样:
|
5. Never Lose Track of a Commit
Let’s say you committed something you didn’t want to and ended up doing a hard reset to come back to your previous state. Later, you realize you lost some other information in the process and want to get it back, or at least view it. This is where A simple If I run
However, a
| 译者信息 |
5. 绝对不要丢失对Commit的跟踪
假设你不小心提交了些你不想要的东西,不得不做一次强制重置来恢复到之前的状态。然后,你意识到在这一过程中你丢失了其它一些信息并且想要把它们找回来,或者至少瞅一眼。这正是git reflog可以做到的。 一个简单的git log命令可以为你展示最后一次commit,以及它的父亲,还有它父亲的父亲等等。而git reflog则列出了head曾经指向过的一系列commit。要明白它们只存在于你本机中;而不是你的版本仓库的一部分,也不包含在push和merge操作中。 如果我运行git log命令,我可以看到一些commit,它们都是我仓库的一部分:
然而,一个git reflog命令则展示了一次commit (b1b0ee9–HEAD@{4}),它正是我刚才进行强制重置时弄丢的:
|
6. Staging Parts of a Changed File for a Commit
It is generally a good practice to make feature-based commits, that is, each commit must represent a feature or a bug fix. Consider what would happen if you fixed two bugs, or added multiple features without committing the changes. In such a situation situation, you could put the changes in a single commit. But there is a better way: Stage the files individually and commit them separately. Let’s say you’ve made multiple changes to a single file and want them to appear in separate commits. In that case, we add files by prefixing Let’s try to demonstrate the same. I have added three new lines to
And let’s see what happes when we prefix a
It seems that Git assumed that all the changes were a part of the same idea, thereby grouping it into a single hunk. You have the following options:
In our case, we definitely want to split it into smaller parts to selectively add some and ignore the rest.
As you can see, we have added the first and third lines and ignored the second. You can then view the status of the repository and make a commit.
| 译者信息 |
6. 暂存文件的部分改动
一般情况下,创建一个基于特性的提交是比较好的做法,意思是每次提交都必须代表一个新特性的产生或者是一个bug的修复。如果你修复了两个bug,或是添加了多个新特性但是却没有提交这些变化会怎样呢?在这种情况下,你可以把这些变化放在一次提交中。但更好的方法是把文件暂存(Stage)然后分别提交。 例如你对一个文件进行了多次修改并且想把他们分别提交。这种情况下,你可以在 add 命令中加上 -p 参数 我们来演示一下在 file_name 文件中添加了3行文字,但只想提交第一行和第三行。先看一下 git diff 显示的结果:
然后再看看在 add 命令中添加 -p 参数是怎样的?
看上去,Git 假定所有的改变都是针对同一件事情的,因此它把这些都放在了一个块里。你有如下几个选项:
在我们这个例子中,最终是希望分割成更小的部分,然后有选择的添加或者忽略其中一部分。
正如你所看到的,我们添加了第一行和第三行而忽略了第二行。之后你可以查看仓库状态之后并进行提交。
|
7. Squash Multiple Commits
When you submit your code for review and create a pull request (which happens often in open source projects), you might be asked to make a change to your code before it’s accepted. You make the change, only to be asked to change it yet again in the next review. Before you know it, you have a few extra commits. Ideally, you could squash them into one using the If you want to squash the last two commits, the command that you run is the following. On running this command, you are taken to an interactive interface listing the commits and asking you which ones to squash. Ideally, you
You are then asked to provide a commit message to the new commit. This process essentially re-writes your commit history.
| 译者信息 |
7. 压缩多个Commit
当你提交代码进行代码审查时或者创建一次pull request (这在开源项目中经常发生),你的代码在被接受之前会被要求做一些变更。于是你进行了变更,并且直到下一次审查之前你没有再次被要求进行变更过。在你知道又要进行变更之前,你已经有了一些额外的commit。理想情况下,你可以用rebase命令把多个commit压缩成一个。 如果你想要压缩最后两个commit,你需要运行下列命令。 运行该命令时,你会看到一个交互界面,列出了许多commit让你选择哪些需要进行压缩。理想情况下,你选择最后一次commit并把其它老commit都进行压缩。
然后会要求你为新的commit录入提交信息。这一过程本质上重写了你的commit历史。
|
8. Stash Uncommitted Changes
Let’s say you are working on a certain bug or a feature, and you are suddenly asked to demonstrate your work. Your current work is not complete enough to be committed, and you can’t give a demonstration at this stage (without reverting the changes). In such a situation, To check the list of stashes, you can run the following:
If you want to un-stash and recover the uncommitted changes, you apply the stash: In the last screenshot, you can see that each stash has an indentifier, a unique number (although we have only one stash in this case). In case you want to apply only selective stashes, you add the specific identifier to the
| 译者信息 |
8. Stash未提交的更改
你正在修改某个bug或者某个特性,又突然被要求展示你的工作。而你现在所做的工作还不足以提交,这个阶段你还无法进行展示(不能回到更改之前)。在这种情况下, git stash可以帮助你。stash在本质上会取走所有的变更并存储它们为以备将来使用。stash你的变更,你只需简单地运行下面的命令-
希望检查stash列表,你可以运行下面的命令:
如果你想要解除stash并且恢复未提交的变更,你可以进行apply stash:
在屏幕截图中,你可以看到每个stash都有一个标识符,一个唯一的号码(尽管在这种情况下我们只有一个stash)。如果你只想留有余地进行apply stash,你应该给apply添加特定的标识符:
|
9. Check for Lost Commits
Although
Here you can see a lost commit. You can check the changes in the commit by running | 译者信息 |
9.检查丢失的提交
尽管 reflog 是唯一检查丢失提交的方式。但它不是适应用于大型的仓库。那就是 fsck(文件系统检测)命令登场的时候了。 git fsck --lost-found
这里你可以看到丢掉的提交。你可以通过运行 git show [commit_hash] 查看提交之后的改变或者运行git merge [commit_hash] 来恢复到之前的提交。 git fsck 相对reflog是有优势的。比方说你删除一个远程的分支然后关闭仓库。 用fsck 你可以搜索和恢复已删除的远程分支。 |