mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
Merge pull request #1261 from CNprober/working
翻译完成By CNprober, Tips to Push Your Git Skills .. Next Level
This commit is contained in:
joeren
commit
93cf9ed520
@ -1,190 +0,0 @@
|
||||
CNprober 翻译中... 619913541
|
||||
|
||||
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][1] and [using Git in a team environment][2]. 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 add -p [file_name]`). In those examples, you would insert the necessary number, identifier, etc. without the square brackets.
|
||||
|
||||
### 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:
|
||||
|
||||
cd ~
|
||||
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash
|
||||
|
||||
Next, add the following lines to your ~/.bash_profile file:
|
||||
|
||||
if [ -f ~/.git-completion.bash ]; then
|
||||
. ~/.git-completion.bash
|
||||
fi
|
||||
|
||||
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!
|
||||
|
||||
### 2. Ignoring Files in Git ###
|
||||
|
||||
Are you tired of compiled files (like `.pyc`) appearing in your Git repository? Or are you so fed up that you have added them to Git? Look no further, there is a way through which you can tell Git to ignore certain files and directories altogether. Simply create a file with the name `.gitignore` and list the files and directories that you don’t want Git to track. You can make exceptions using the exclamation mark(!).
|
||||
|
||||
*.pyc
|
||||
*.exe
|
||||
my_db_config/
|
||||
|
||||
!main.pyc
|
||||
|
||||
### 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 `git blame`. This command shows you the author of every line in a file, the commit that saw the last change in that line, and the timestamp of the commit.
|
||||
|
||||
git blame [file_name]
|
||||
|
||||
|
||||
|
||||
And in the screenshot below, you can see how this command would look on a bigger repository:
|
||||
|
||||
|
||||
|
||||
### 4. Review History of the Repository ###
|
||||
|
||||
We had a look at the use of `git log` in a previous tutorial, however, there are three options that you should know about.
|
||||
|
||||
|
||||
- **--oneline** – Compresses the information shown beside each commit to a reduced commit hash and the commit message, all shown in a single line.
|
||||
- **--graph** – This option draws a text-based graphical representation of the history on the left hand side of the output. It’s of no use if you are viewing the history for a single branch.
|
||||
- **--all** – Shows the history of all branches.
|
||||
|
||||
Here’s what a combination of the options looks like:
|
||||
|
||||
|
||||
|
||||
### 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 `git reflog` can help.
|
||||
|
||||
A simple `git log` shows you the latest commit, its parent, its parent’s parent, and so on. However, `git reflog` is a list of commits that the head was pointed to. Remember that it’s local to your system; it’s not a part of your repository and not included in pushes or merges.
|
||||
|
||||
If I run `git log`, I get the commits that are a part of my repository:
|
||||
|
||||
|
||||
|
||||
However, a `git reflog` shows a commit (`b1b0ee9` – `HEAD@{4}`) that was lost when I did a hard reset:
|
||||
|
||||
|
||||
|
||||
### 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 `-p` to our add commands.
|
||||
|
||||
git add -p [file_name]
|
||||
|
||||
Let’s try to demonstrate the same. I have added three new lines to `file_name` and I want only the first and third lines to appear in my commit. Let’s see what a `git diff` shows us.
|
||||
|
||||
|
||||
|
||||
And let’s see what happes when we prefix a `-p` to our `add` command.
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
- Enter y to stage that hunk
|
||||
- Enter n to not stage that hunk
|
||||
- Enter e to manually edit the hunk
|
||||
- Enter d to exit or go to the next file.
|
||||
- Enter s to split the hunk.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
### 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 rebase command.
|
||||
|
||||
git rebase -i HEAD~[number_of_commits]
|
||||
|
||||
If you want to squash the last two commits, the command that you run is the following.
|
||||
|
||||
git rebase -i HEAD~2
|
||||
|
||||
On running this command, you are taken to an interactive interface listing the commits and asking you which ones to squash. Ideally, you `pick` the latest commit and `squash` the old ones.
|
||||
|
||||
|
||||
|
||||
You are then asked to provide a commit message to the new commit. This process essentially re-writes your commit history.
|
||||
|
||||
|
||||
|
||||
### 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, `git stash` comes to the rescue. Stash essentially takes all your changes and stores them for further use. To stash your changes, you simply run the following-
|
||||
|
||||
git stash
|
||||
|
||||
To check the list of stashes, you can run the following:
|
||||
|
||||
git stash list
|
||||
|
||||
|
||||
|
||||
If you want to un-stash and recover the uncommitted changes, you apply the stash:
|
||||
|
||||
git stash apply
|
||||
|
||||
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 apply command:
|
||||
|
||||
git stash apply stash@{2}
|
||||
|
||||
|
||||
|
||||
### 9. Check for Lost Commits ###
|
||||
|
||||
Although `reflog` is one way of checking for lost commits, it’s not feasible in large repositories. That is when the `fsck` (file system check) command comes into play.
|
||||
|
||||
git fsck --lost-found
|
||||
|
||||
|
||||
|
||||
Here you can see a lost commit. You can check the changes in the commit by running git show [commit_hash] or recover it by running `git merge [commit_hash]`.
|
||||
|
||||
`git fsck` has an advantage over `reflog`. Let’s say you deleted a remote branch and then cloned the repository. With `fsck` you can search for and recover the deleted remote branch.
|
||||
|
||||
### 10. Cherry Pick ###
|
||||
|
||||
I have saved the most elegant Git command for the last. The `cherry-pick` command is by far my favorite Git command, because of its literal meaning as well as its utility!
|
||||
|
||||
In the simplest of terms, `cherry-pick` is picking a single commit from a different branch and merging it with your current one. If you are working in a parallel fashion on two or more branches, you might notice a bug that is present in all branches. If you solve it in one, you can cherry pick the commit into the other branches, without messing with other files or commits.
|
||||
|
||||
Let’s consider a scenario where we can apply this. I have two branches and I want to cherry-pick the commit `b20fd14: Cleaned junk` into another one.
|
||||
|
||||
|
||||
|
||||
I switch to the branch into which I want to cherry-pick the commit, and run the following:
|
||||
|
||||
git cherry-pick [commit_hash]
|
||||
|
||||
|
||||
|
||||
Although we had a clean `cherry-pick` this time, you should know that this command can often lead to conflicts, so use it with care.
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
With this, we come to the end of our list of tips that I think can help you take your Git skills to a new level. Git is the best out there and it can accomplish anything you can imagine. Therefore, always try to challenge yourself with Git. Chances are, you will end up learning something new!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.sitepoint.com/10-tips-git-next-level/
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://www.sitepoint.com/git-for-beginners/
|
||||
[2]:http://www.sitepoint.com/getting-started-git-team-environment/
|
||||
@ -0,0 +1,190 @@
|
||||
CNprober 翻译完成... 619913541
|
||||
|
||||
10招让你的Git技能提升一个台阶
|
||||
================================================================================
|
||||
|
||||
之前我们发了一些教程让你熟悉[Git基础][1]和[在团队合作环境中使用Git][2].我们讨论的这些Git命令足够让一个开发者在Git的世界里生存下去。在这篇教程里，我们试着探索如何高效地管理你的时间以及如何充分利用Git提供的特性。
|
||||
|
||||
> 注意：这里介绍的命令中有的包含方括号(例如：`git add -p [file_name]`)。在这些例子中，你应该用你自己的数字，标识符等替代方括号里的内容，并且去掉方括号。
|
||||
|
||||
### 1. Git自动补全 ###
|
||||
|
||||
如果你在命令行环境中运行Git命令，每次都手动地逐个输入命令是一件很无聊的事。为此，你可以花几分钟时间配置一下Git命令的自动补全功能。
|
||||
|
||||
在*nix系统运行下列命令下载自动补全脚本：
|
||||
|
||||
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特性，你绝bi应该切换到命令行环境。
|
||||
|
||||
### 2. 在Git中忽略文件 ###
|
||||
|
||||
你是不是对出现在你Git库里面的编译生成文件（比如`.pyc`)感到很无语？或者你是不是很厌恶不小心将他们添加到了Git？直接看这里，这里有一个方法可以让你告诉Git忽略所有这些文件和目录。只需要创建一个名字为`.gitignore`的文件，里面列出你不想要Git跟踪的文件和目录。可以用感叹号(!)列出例外情况。
|
||||
|
||||
*.pyc
|
||||
*.exe
|
||||
my_db_config/
|
||||
|
||||
!main.pyc
|
||||
|
||||
### 3. 谁动了我的代码？ ###
|
||||
|
||||
当事情出了乱子时立马责怪别人这是人类的天性。如果你的服务器程序不能正常工作了，要找出罪魁祸首是非常简单的--只需要执行`git blame`。这个命令告诉你文件里的每一行的作者是谁，最后改动那一行的提交，以及提交的时间戳。
|
||||
|
||||
git blame [file_name]
|
||||
|
||||
|
||||
|
||||
在下面的截图里，你可以看到在一个更大的库里这个命令的输出是什么样的：
|
||||
|
||||
|
||||
|
||||
### 4. 查看库的历史 ###
|
||||
|
||||
在之前的教程里，我们已经看过了如何使用`git log`命令。不管怎样，有3个选项你应该知道。
|
||||
|
||||
- **--oneline** - 压缩每次的提交信息，只保留一个缩减的Hash值和说明文字，然后把这些都展示在一行里。
|
||||
- **--graph** - 这个选项将在左边画出一个文字界面的提交历史图。如果你只有一个分支，用这个选项查看历史时是没什么意义的。
|
||||
- **--all** - 显示所有分支历史。
|
||||
|
||||
这是这3个选项合起来使用的效果：
|
||||
|
||||
|
||||
|
||||
### 5. 不要丢失对某个提交的跟踪 ###
|
||||
|
||||
假设你提交了一些不需要的东西，然后你进行了hard重置回到之前的状态。后来，你发现在这个过程中你丢失了其他一些重要的信息，你想要把这些信息找回来，或者至少可以查看一下这些信息。这就需要`git reflog`帮忙。
|
||||
|
||||
简单的`git log`只能告诉你最近的提交，这个提交的父提交，父提交的父提交，等等。但是`git reflog`是一个HEAD指向的提交的列表。记住，这个列表依赖于你自己的操作环境，它不是库的一部分，也不包含在push或者merge中。
|
||||
|
||||
如果执行`git log`命令，可以看到提交历史，这是我的库的一部分：
|
||||
|
||||
|
||||
|
||||
但是，`git reflog`命令显示了一个被我用hard重置丢掉的提交(`b1b0ee9`-`HEAD@{4}`).
|
||||
|
||||
|
||||
|
||||
### 6. 暂存文件的一部分更改以便进行一次提交 ###
|
||||
|
||||
通常依据特性来提交是一个好的实践方法，意思是说，每一个提交都只添加一个特性或者修复一个bug。想一下如果你一次修复了两个bug或者添加了两个特性但是都还没有提交该怎么办。这种场景下，你可以将他们一起提交。但是有一个更好的办法：单独暂存这些文件，然后分开提交。
|
||||
|
||||
让我们假设你对一个文件做了多个更改，然后想让这些更改分开提交。这时，我们用带`-p`的添加命令。
|
||||
|
||||
git add -p [file_name]
|
||||
|
||||
我们来试试这种用法。我添加了3个新行到`file_name`，但是我只想让第1行和第3行出现在我的提交里。让我们看看`git diff`的输出是什么样的。
|
||||
|
||||
|
||||
|
||||
然后，我们看看带`-p`选项的`add`命令会发生什么。
|
||||
|
||||
|
||||
|
||||
似乎Git认为所有的更改都是同一个目的的一部分，所以把他们分组到同一个块里。这时，你可以：
|
||||
|
||||
- 输入 y 暂存块
|
||||
- 输入 n 不暂存块
|
||||
- 输入 e 手动编辑块
|
||||
- 输入 d 退出或者跳转到下一个文件
|
||||
- 输入 s 分割块
|
||||
|
||||
在我们这个例子中，我们想把这个块分割成更小的部分，然后选择其中一些忽略另外一些。
|
||||
|
||||
|
||||
|
||||
如你所见，我们已经添加了第1和第3行，忽略了第2行。你可以看到库的状态并且进行一次提交。
|
||||
|
||||
|
||||
|
||||
### 7. 合并多个提交 ###
|
||||
|
||||
为了进行核查或者发起一个合并请求（这经常发生在开源项目里），对代码进行了修改提交。但在最后代码被接受之前，你也许会被要求修改你的代码。于是你修改代码，但是下一次核查的时候又一次被要求进行修改。不知不觉中，你就已经有了好几个提交。理论上你应该用rebase命令把他们合并起来。
|
||||
|
||||
git rebase -i HEAD~[number_of_commits]
|
||||
|
||||
如果你想合并最后的两次提交，你应该运行下面的命令。
|
||||
|
||||
git rebase -i HEAD~2
|
||||
|
||||
一旦你运行这个命令，你将进入一个交互式界面，它将询问你想要合并哪些提交。你`pick`(拣选)最近的提交然后`squash`(合并)旧的提交。
|
||||
|
||||
|
||||
|
||||
接着你被要求提供一个对新提交的说明。这个过程会重写你的提交历史。
|
||||
|
||||
|
||||
|
||||
### 8. 储藏没有提交的更改 ###
|
||||
|
||||
假设你正在修复一个bug或者添加一个特性，突然你被要求展示一下你的工作成果。你现在的工作还没有完成，不够进行一次提交。这时，`git stash`命令可以用来急救一下。Stash命令跟踪你所有的更改，然后把他们储藏起来以便以后使用。命令如下-
|
||||
|
||||
git stash
|
||||
|
||||
可以多次储藏更改，查看储藏列表，你可以运行下面的命令：
|
||||
|
||||
git stash list
|
||||
|
||||
|
||||
|
||||
如果你想取消储藏，覆盖当前的更改，你可以通过下面的命令使用储藏：
|
||||
|
||||
git stash apply
|
||||
|
||||
在最后的这个截图里，你可以看到每个储藏都有一个标识符，是一个唯一的数字（尽管在这里我们只有一个储藏）。如果你想使用某个储藏，你在apply命令后面加上这个唯一的标识符：
|
||||
|
||||
git stash apply stash@{2}
|
||||
|
||||
|
||||
|
||||
### 9. 检查丢失的提交 ###
|
||||
|
||||
尽管`reflog`是一种检查丢失提交的方法，大型的库里却不太实用。这个时候，应该用`fsck`（文件系统检查）命令。
|
||||
|
||||
git fsck --lost-found
|
||||
|
||||
|
||||
|
||||
这里你可以看到一个丢失的提交。你可以通过`git show [commit_hash]` 查看提交的更改或者通过运行`git merge [commit_hash]`命令进行恢复。
|
||||
|
||||
`git fsck`跟`reflog`命令相比有一个优点。假设你删除了一个远程分支，然后clone了这个库。用`fsck`命令你可以找到并且恢复这个删除的远程分支。
|
||||
|
||||
### 10. 最佳选择 ###
|
||||
|
||||
之前我已经存记下了那些最优雅的Git命令。但是目前为止，`cherry-pick`命令是我最喜欢的Git命令，因为它直白的名字和实用的功能！
|
||||
|
||||
最简单的情况下，`cherry-pick`从另一个分支里选出单独的一个提交，然后合并到当前分支。如果你正并行工作在两个或者更多的分支上，你也许会发现一个存在于所有分支上的bug。如果你解决了一个分支上的这个bug，你可以拣选这个对应的提交应用到其他分支上，而不会弄乱其他文件或者提交。
|
||||
|
||||
让我们来考虑一个可以使用这个命令的场景。我有两个分支，我想拣选`b20fd14: Cleaned junk`这个提交到另一个分支上。
|
||||
|
||||
|
||||
|
||||
我切换到想要应用这个拣选出来的提交的分支，然后运行下面的命令：
|
||||
|
||||
git cherry-pick [commit_hash]
|
||||
|
||||
|
||||
|
||||
尽管这次我们很干净的用了`cherry-pick`命令，但你应该知道这个命令经常会引起冲突，所以请小心使用。
|
||||
|
||||
### 总结 ###
|
||||
|
||||
到了这里，我们结束了这个能使你Git能力提升一个级别的列表。Git是最好的版本控制器，它能完成你能想象到的任何事情。所以，经常试着用Git挑战你自己。一不小心你就会学到很多新东西。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.sitepoint.com/10-tips-git-next-level/
|
||||
|
||||
译者：[love_daisy_love](https://github.com/CNprober) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://www.sitepoint.com/git-for-beginners/
|
||||
[2]:http://www.sitepoint.com/getting-started-git-team-environment/
|
||||
Loading…
Reference in New Issue
Block a user