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

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

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 add -p [file_name]). In those examples, you would insert the necessary number, identifier, etc. without the square brackets.

已有 1 人翻译此段
我来翻译

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!

已有 1 人翻译此段
我来翻译

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
已有 2 人翻译此段
我来翻译

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]

git blame demonstration

And in the screenshot below, you can see how this command would look on a bigger repository:

git blame on the ATutor repository

已有 1 人翻译此段
我来翻译

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:

Use of git log with all, graph and oneline

已有 1 人翻译此段
我来翻译

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:

Project history

However, a git reflog shows a commit (b1b0ee9 – HEAD@{4}) that was lost when I did a hard reset:

Git reflog

已有 1 人翻译此段
我来翻译

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.

Changes in repo

And let’s see what happes when we prefix a -p to our add command.

Running add with -p

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.

Adding all hunks

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.

Repository after selectively adding a file

已有 1 人翻译此段
我来翻译

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.

Git squash interactive

You are then asked to provide a commit message to the new commit. This process essentially re-writes your commit history.

Adding a commit message

已有 1 人翻译此段
我来翻译

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

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}

After un-stashing changes

已有 1 人翻译此段
我来翻译

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

Git fsck results

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.

已有 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 太好用了!!!!命令如其名啊哈哈
donghui2020
donghui2020

引用来自“donhui”的评论

不错

引用来自“donhui”的评论

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

引用来自“donhui”的评论

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

引用来自“Raynor1”的评论

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

引用来自“CWhite”的评论

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