假设你是专注于命令行的用户，就可以不在多个工具之间切换招致专心，这个工具在命令行上完成了相似图形界面的提交视图。经过 --graph 参数获取 git 的记载：

John Anderson, CC BY

下面的命令可以失掉一样的仓库可视化片段：

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative 

--graph 选项将图表添加到日志的左侧，--abbrev-commit 存储提交运用了 SHA 办法， --date=relative 表达式用相对的术语来表示日期，并且 --pretty 以 bit 格式处置自定义格式。我知道 git lg 的别名，它是我最常运转的10个命令之一。

6. 更优雅的强迫推送(force-push)

有时，就跟你尽量避免运用它一样困难的是，你会发现你需求运转 git push --force 来覆写你仓库的远程正本上的历史记载。你能够已失掉了一些反应，他们会要求你停止交互式的变基(rebase)，或许你能够曾经搞砸了，并且希望隐藏证据。

当别人在仓库的远程正本的同一分支上停止改动后，会发作强迫推送的风险。当你强迫推送已重写的历史记载时，某些提交将会丧失。这是 git push --force-with-lease 出现的缘由 - 假设远程分支已更新，它不会允许你执行强迫推送，这将确保你不会丢弃别人的任务。

7. git add -N

你能否运用过git commit -a在一次举动中提交你一切未完成的修正，只要在你push完你的提交后才发现git commit -a疏忽了新添加的文件?处置这个成绩你可以用git add -N(“通知”)来通知Git你想把新添加的文件包含在提交中在你第一次实践提交之前。

8. git add -p

一最佳的实际为当运用Git时确保每个提交只包含一个逻辑更改--不管是修复一个bug还是(完成)一个新功用。但是，有时当你任务，会在你的仓库中出现一个以上的修正提交。你怎样样把事情分开，使每个提交只包含适当的修正呢?git add --patch来挽救!

这个标志将会使git add命令查看你任务正本中一切的变更，讯问你能否情愿将它提交，跳过，或许推延决议(还有其他一些更弱小的选项，你可以经过在运转这命令后选择?来查看)。git add -p是一个神奇的工具来消费结构良好的提交。

9. git checkout -p

与 git add -p相似，git checkout命令将运用 --patch 或 -p 选项，这会使 git 在本地任务正本中展现每个“大块”的改动，并允许丢弃对应改动 —— 复杂地说就是恢复本地任务正本到你改动之前的形状。

某些场景下这十分有用，例如，在你跟踪一个 bug 时引入了一堆调试日志语句，在修正了这个 bug 之后，你可以先运用 git checkout -p 删除一切新加的调试日志，之后运用 git add -p 来添加 bug 修复。没有比组合一个极好的、结构良好的提交更令人称心的了!

10. Rebase with command execution

有些项目有一条规则，即存储库中的每个提交都必须处于可任务形状 - 也就是说，在每次提交时，代码应该是可编译的，或运转测试套件应该不会失败的。当你在某分支上任务时间长时，但假设你最终由于某种缘由需求rebase时，那么跳过每个变基后的提交以确保你没有不测引入一个中缀是有些冗长有趣的。

幸运的是，git rebase曾经支持了-x或--exec选项。git rebase -x 将在每次提交运用到rebase后运转该命令。因此，例如，假设你有一个项目，其中npm run tests会运转你的测试套件，那么在rebase时期运用每次提交后，git rebase -x npm run tests将会运转测试套件。这使你可以查看测试套件能否在任何变基后的提交中有失败状况，因此你可以确保测试套件在每次提交时仍能经过。

11. 基于时间修正的指南

很多Git子命令都接受一个修正的参数来决议命令作用于仓库的哪个部分，能够是某次特定的提交的 sha1 值，或许一个分支的称号，又或许是一个符号性的称号如 HEAD(代表以后检出分支最后一次的提交)，除了这些复杂的方式以外，你还可以附加一个指定的日期或时间作为参数，表示“这个时间的援用”。

这个功用在某些时分会变得十分有用，比如当你处置最新出现的 bug，自言自语道：“这个功用明明昨天还是好好的，究竟又改了些什么”，不用盯着满屏的 git 日志的输入试图弄清楚什么时分更改了提交，您只需运转 git diff HEAD@{yesterday}，会看到从昨天以来的一切修正，这也适用于较长的时间段(例如 git diff HEAD@{'2 months ago'}) ，以及一个确切的日期(例如git diff HEAD@{'2010-01-01 12:00:00'})。

您还可以将这些基于日期的修正参数与运用修正参数的任何 Git 子命令一同运用。在 gitrevisions 手册页中有关于详细运用哪种格式的详细信息。

12. 全知的 reflog

你是不是试过在 rebase 时干掉过某次提交，后来又发现你需求保留这次提交的一些东西?你能够觉得这些提交的东西曾经永远找不回来了，只能从头再来了。其实不然，但假设你在本地任务正本中提交了，提交就会进入到 "援用日志" ，你依然可以拜访到。

运转 git reflog 将在本地任务正本中显示以后分支的一切活动的列表，并为您提供每个提交的 SHA1 值。一旦发现你 rebase 时保持的那个提交，你可以运转 git checkout 来检出该次提交，复制好你需求的信息，然后再运转 git checkout HEAD 前往到分支最新的提交去。

以上就是全部内容

希望这些技巧中至少有一个能教你一些关于 Git 的新知识，Git 曾经 12 岁了，在这个继续创新，不断添加新特性的项目里，你最喜欢哪个技巧?

【编辑引荐】

GitLab 调查报告显示：2018 将是 DevOps 和开源年

运用pelican和Github pages来搭建博客

开发者在 GitHub fork 的私有项目，如今却无法拜访了……

GitLab添加了对GitHub的支持，来吸引GitHub用户运用

GitHub 上最受欢迎的 5 大 Java 项目

(责任编辑：admin)