10 个技巧促使你的 Git 的技能上一个台阶 —— SitePoint

最近，我们发布了一些教程促使你了解 Git 基础知识和在团队环境中使用 Git。谈论的指令已经足够帮助一个开发者在 Git 世界中生存。在这次教程中，我们尝试如何在有效的时间内充分掌握提供的 Git 特性。

说明：文中一些指令包含指令的部分在方括号中（如：git add -p [file_name]）。在这些案例中，你可以不用方括号，选择插入一些必要的数字，标识符等等。

如果你通过命令行运行 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 的特性，你应该明确地转变对命令行的交互！

你是否对出现在你 Git 源中编译文件（如 .pyc）感到疲倦？或者对添加这些文件至 Git 上忍无可忍？不用舍近求远，这里有一种方式可以告诉 Git 忽视特定的文件和目录。只要创建一个名字为 .gitignore 的文件，并列出你不想让 Git 处理的文件和文件夹。你可以使用感叹号（!）来特殊处理。)

*.pyc
*.exe
my_db_config/

!main.pyc

当某些事出现问题时，责备其他人是人类的本性。如果你的产品服务器坏掉了，很容易查明真凶 —— 只需执行下 git blame指令。这个命令会显示每一个文件中每一行代码的作者，提交会看到当前行的最后一次变化，同时也提交时间戳。

`git blame [file_name]`

在屏幕截图下，你会看到这个命令就像一个巨大的源：

我们已经在以前的教程中了解过 git log 的运用了，但是这里仍然有你需要知道的三个选项。

• -- online -- 将每次提交展示的信息压缩至精简的提交哈希和提交信息中，所有的展示在一行中。

  
  

• -- graph -- 这个选项绘制了一个在输出左侧基于文本的图形展示的历史信息。如果你想看到每个分支的历史信息是无用的。

• -- all -- 展示所有分支的历史信息。

下面是这些选项的组合：

让我们谈论那些你不想提交的，最后经过了一个艰难的重置回到你之前的状态。后面，你意识到这个过程丢失了一些其他的信息并想返回去，或者至少可以再次看下。这就是 git reflog 作用。

一个简单的 git log 命令可以显示最新的提交，上一次的提交，上上次的提交等等。然而，git reflog是一个被指向提交的列表。记住：这是你系统的局部，不是源的部分，不包含推送的和合并的。

如果执行 git log，我获取的提交信息是源的一部分。

然而，当你执行硬重置时，git reflog 展示了提交信息（b1b0ee9–HEAD@{4}）是丢失的。

基于特性的提交通常是一个好的实践，也就是，每次提交都要展现出一个特性或修改的bug。想想如果你修复了两个bug会发生什么，或者添加多个特征却没有提交改变。在这种情况下，你可以将这些改变放在一个简单的提交中。但是，这里还有一个更好的方式，将文件单独地分段并分别提交他们。

让我们看看你做的几个改变至单个文件中，并想让他们出现在分离的提交中。在这种情况下，我们可以通过添加前缀 -p 来添加文件。

`git add -p [file_name]`

让我们来证明一致性。我已经添加了三个新行至 file_name，而且我仅想第一和第三行出现在提交信息中。让我们看看 git diff 展示给我们的信息。

让我们看看当我们添加一个前缀 -p 至 add 命令上发生了什么。

似乎 Git 假设所有的改变都是同样的，因此，将它们分成一个大块。你有下列选择：

• 输入 y 分成块

• 输入 n 不分块

• 输入 e 手动编辑块

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

• 输入 s 分离块

在我们的案例中，我们当然想将它分离成小块，可以有选择地添加一部分并忽略其余的。

正如你所看到的，我们已经添加第一行和第三行的信息并忽略了第二行的信息。你可以查看源的状态并提交。

当你提交你的代码是为了查看和创建一个新的推送请求（在开源项目中经常出现），在接受前，你可以要求改变的你的代码。你做出改变，仅仅是要求改变它以便下次查看。在你知道前，你可以做一些额外的提交。理想地，你可以使用 rabase 指令压缩它们。

`git rebase -i HEAD~[number_of_commits]`

如果你想压缩上面两次的提交，你要执行的指令在下面。

`git rebase -i HEAD~2`

在运行这条指令时，会带你来到一个交互的界面中，列出提交的信息，并要求你压缩哪一个。理想地，你会选择最新的提交并压缩上一次的。

要求你为新提交的准备提交信息。这个处理基本上会覆盖你的提交历史。

让我们探讨你正在致力于某个 bug 和特征时，要求验证你的工作。你当前的工作不足够提交，并且你并不能在这个阶段给出一个证明（没有回复改变值）。在这种情况下，git stash 可以帮助你。Stash 基本上具有你所有的改变并保存它们以便你后期使用。为了保存这些变化，你需要运行以下命令：

`git stash`

为了核对保存的列表，你需要执行下面的命令：

`git stash list`

如果你想不保存和恢复未提交的变化，你可以应用下面的保存：

`git stash apply`

在最后一个截图中，你可以看到每次保存都有个标识符，一个唯一的数字（尽管我们仅仅在这种情况下保存）。如果你想只选择有选择性的保存，你可以添加特殊的标识符到 apply 命令中。

`git stash apply stash@{2}`

尽管 reflog 是核对上次丢失的提交信息的一种方法，但在大量的源中，不是可行的。这就是 fsck(文件系统核对) 命令要做的。

`git fsck --lost-found`

在这里，你可以看到丢失的提交信息。那你可以通过运行 git show [commit_hash] 来核对改变的提交信息，或者通过执行 git merge [commit_hash] 来回复它。

git fsck 相比 reflog 有一种优势。让我们看看你删除了一个远程的分支，然后克隆源。使用 fsck，你可以查询和恢复删除的远程分支。

在之前，我保存了很多简洁的 Git 指令。cherry-pick 指令是迄今为止我最喜欢的 Git 命令，是由于它的字面意义和它的功能！

用最简单的术语来说，cherry-pick 是从不同的分支中选择单个提交和将它和当前分支的合并。如果你在两个或更多的分支中工作，你可能会注意到 bug 会出现所有的分支。如果你在其中一个分支解决了这个 bug，你可以使用 cherry pick 提交至其他分支，不干扰其他文件或提交。

让我们想想可以运用的场景。我有两个分支，并且我想 cherry-pick 提交 b20fd14:清理垃圾：至另外一个分支。

切换分支至我想 cherry-pick 的提交，并执行以下指令：

`git cherry-pick [commit_hash]`

尽管我们已经清除了 cherry-pick 的时间，但是你应该知道这个命令可能经常导致冲突，因此要慎用。

以上，总结下小技巧清单，我认为可以帮你的 Git 技能达到一个新的台阶。Git 是最好的，可以实现任何你想象的。因此，要总是尝试挑战自己使用 Git。你很有可能会学到一些新的东西！