什么是GIT
Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
主要是可以用于敏捷高效地处理任何或小或大的项目。
今天小编就分享1212个诀窍与技巧来让你的Git经验更加有用和强大，从一些你可能会忽视的基础开始到一些真正的强大技巧!
你的 ~/.gitconfig 文件
在第一次用git命令来提交一个仓库的修改，你可能会首先看到像下面这种内容：
这个文件就是Git存储全局配置选项的文件。你可以按条件地基于路径包含其他配置文件到一个仓库!使用"man git-config"查看所有细节。
你的仓库的.gitconfig文件
在之前的技巧中，你可能会想知道在git config 命令中的—global标识是做什么的。它告诉Git更新"global"配置，也就是~/.gitconfig发现的这个配置。
3别名
4 shell命令中的别名
5. 可视化提交图
如果你从事的是一个有很多分支活动的项目，有时可能很难掌握所有正在发生的工作以及它们之间的相关性。各种GUI工具可让你弄清楚不同分支的概况以及在所谓的"提交图"中提交记录。例如，以下是我使用GitLab提交图查看器进行可视化的一个存储卡的部分截图：
John Anderson, CC BY
如果你是专注于命令行的用户，就可以不在多个工具之间切换导致分心，这个工具在命令行上实现了类似图形界面的提交视图。通过 --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 岁了，在这个持续创新，不断添加新特性的项目里，你最喜欢哪个技巧?