使用这12个Git提示和技巧，让您的版本控制体验更有用。Git，分布式版本控制系统，已成为开源世界源代码控制的默认工具，于4月7日满12岁。但使用Git时更令人沮丧的是您需要了解多少才能有效地使用它。这也是使用Git的美妙之处之一，因为没有什么比发现一个新的小技巧来简化或提高工作流程效率更令人满意的了。为了纪念Git的12岁生日，本文提供了12个提示和技巧，让您的Git体验更加有用和强大，从一些您可能会忽略的基础知识开始，到一些真正强大的技巧！1.你的~/.gitconfig文件第一次使用git命令提交一个仓库的变更，你可能首先看到这样的东西：***Pleasetellmewhoyouare.Rungitconfig--globaluser.email"you@example.com"gitconfig--globaluser.name"YourName"设置您帐户的默认身份。您可能没有意识到这些命令正在修改~/.gitconfig文件的内容，该文件是Git存储全局配置选项的文件。你可以通过你的~/.gitconfig文件做很多事情，包括定义别名、打开（或关闭）特定的命令选项，以及修改Git工作方式的各个方面（例如：哪个diff用于gitdiff）算法，或者默认使用什么类型的合并策略）。您甚至可以根据路径有条件地将其他配置文件包含到存储库中！使用“mangit-config”查看所有详细信息。2.你的仓库的.gitconfig文件在前面的技巧中，你可能想知道gitconfig命令中的--global标志是做什么的。它告诉Git更新“全局”配置，这是在~/.gitconfig中找到的配置。当然，拥有全局配置就代表了本地配置，果然，如果省略--global选项，gitconfig将更新存储库自己的配置，该配置存储在.git/config中。.git/config中设置的选项会覆盖~/.gitconfig中的相应设置。因此，例如，如果您需要在特定存储库中使用不同的电子邮件地址，您可以运行“gitconfiguser.email“also_you@example.com””。然后，你在这个仓库中的提交将使用你单独配置的邮箱地址。如果您使用工作计算机处理开源项目，但想为该项目使用个人电子邮件地址，而其他人仍在主Git配置中使用工作电子邮件地址，这将很有用。任何可以在~/.gitconfig中设置的内容，都可以在.git/config中设置为特定于此存储库。在下面的提示中，当我提到要添加到您的~/.gitconfig文件的内容时，我还说您可以添加到特定存储库的.git/config来设置该选项。3.别名别名是您可以在~/.gitconfig文件中做的另一件事。他的工作原理就像shell命令行中的别名——设置一个新的命令名来调用一个或多个其他命令，这些命令通常包括一些特定的选项或标志。别名对于您经常使用的那些又长又复杂的命令行非常有用。你可以使用gitconfig命令来定义别名——例如，在执行“gitconfig--global--addalias.ststatus”命令后，它会让gitst的执行与执行gitstatus-但是，我发现在定义别名时，直接在~/.gitconfig文件中编辑它们通常更容易。如果您选择这样做，您会发现您的~/.gitconfig文件是一个INI文件，它是一种具有特定部分的基本键值对文件格式。添加别名时，您将更改[alias]部分。例如：要定义和上面提到的一样的gitst别名，需要添加如下代码：[alias]st=status（如果已经有[alias]段，只需要在第二行添加本段）4。shell命令中的别名别名不仅仅运行其他Git子命令——您还可以定义运行其他shell命令的别名。这是处理重复的、罕见的、复杂的任务的好方法：一旦您第一次弄清楚如何执行命令，就用别名保存命令。比如我有几个仓库是我fork了一个开源项目，在本地做了一些改动，不需要贡献给这个项目。在项目的持续开发过程中，我想保留最新版本，同时保留我的本地修改。为了实现这个想法，我需要定期将来自上游存储库的更改合并到我的复刻中——我定义了一个别名“upstream-merge”来执行此操作。定义如下：upstream-merge=!"gitfetchoorigin-v&&gitfetchupstream-v&&gitmergeupstream/master&&gitpush""!"在别名定义的开头告诉Git通过shell运行这个命令。此示例包括运行一些git命令，但以这种方式定义的别名可以运行任何shell命令。（注意：如果你想复制我的upstream-merge别名，你需要确保你有一个名为upstream的Git远程，它为你的分支指定了这个上游存储库。你可以使用“gitremoteaddupstream”添加一个。）5.VisualCommitGraph如果您正在处理一个包含大量分支活动的项目，有时可能很难跟踪所有正在发生的工作以及它们之间的关系。各种GUI工具允许您在所谓的“提交图”中找出不同分支和提交记录的概览。例如，这是我使用GitLab提交图查看器可视化的存储卡的部分屏幕截图：JohnAnderson，CCBY该工具在命令行上实现了类似GUI的提交视图。通过--graph参数获取git记录：JohnAnderson,CCBY以下命令可以获取同仓库可视化片段：gitlog--graph--pretty=format:'%Cred%h%Creset-%C(yellow)%d%Creset%s%Cgreen(%cr)%C(boldblue)<%an>%Creset'--abbrev-commit--date=relative--graph选项在日志的左侧添加一个图表，--abbrev-commit使用SHA方法存储提交，--date=relative表达式以相对术语表示日期，--pretty以位格式处理自定义格式。我知道gitlg的别名，它是我最常运行的10个命令之一。6.更优雅的force-push有时，就像你尽量避免使用它一样，你会发现你需要运行gitpush--force来覆盖你存储库远程副本上的历史。您可能已经收到一些反馈，他们会要求您进行交互式变基，或者您可能搞砸了并想隐藏证据。当其他人在存储库的远程副本的同一分支上进行更改时，就会出现强制推送的风险。当您强制推送已被重写的历史记录时，一些提交将丢失。这就是gitpush--force-with-lease出现的地方——如果远程分支已经更新，它不会让你强制推送，这将确保你不会丢弃其他人的工作。7.gitadd-N你是否曾经使用gitcommit-a一次提交所有未完成的更改，却发现在你推送提交后gitcommit-a忽略了新添加的文件？要解决此问题，您可以使用gitadd-N("notify")告诉Git您希望在第一次实际提交之前将新添加的文件包含在提交中。8.gitadd-p的最佳实践是在使用Git时确保每次提交仅包含一个逻辑更改——无论是修复错误还是（实现）新功能。但是，有时当您工作时，您的存储库中会出现多个提交。您如何分离事物以使每个提交仅包含适当的更改？gitadd--patch来拯救！这个标志将导致gitadd命令查看你工作副本中的所有更改，并询问你是要提交它、跳过它还是推迟决定（运行这个命令后你可以选择其他更强大的选项？查看）。gitadd-p是一个用于生成结构良好的提交的神奇工具。9.gitcheckout-p类似于gitadd-p，gitcheckout命令将使用--patch或-p选项，这将使git显示本地工作副本中的每个“大块”更改并允许相应的改变被丢弃——简单来说就是将本地工作副本恢复到你改变之前的状态。这在某些场景下非常有用，比如当你跟踪一个bug，引入了一堆调试日志语句，修复bug后，你可以先使用gitcheckout-p删除所有新添加的调试日志，然后再使用git添加-p以添加错误修复。没有什么比将一个漂亮的、结构良好的提交放在一起更令人满意的了10.Rebasewithcommandexecution一些项目有一个规则，即存储库中的每个提交都必须处于工作状态——也就是说，在每次提交时，代码应该是可编译的，或者测试套件应该可以无故障地运行。当您在一个分支上工作了很长时间，但如果您最终出于某种原因需要变基，跳过每个变基提交以确保您没有意外引入中断可能会很乏味。幸运的是，gitrebase已经支持-x或--exec选项。gitrebase-x将在每次提交应用于rebase后运行命令。因此，例如，如果您有一个项目，其中npmruntests运行您的测试套件，则gitrebase-xnpmruntests将在rebase期间应用每次提交后运行测试套件。这允许您查看您的测试套件是否在任何重新定位的提交中失败，因此您可以确保您的测试套件在每次提交时仍然通过。11.基于时间的修改指南很多Git子命令都接受一个修改的参数来确定该命令作用于仓库的哪个部分，这个参数可能是具体commit的sha1值，也可能是某个分支的名称，也可能是一个符号名比如HEAD（代表当前checkedout分支的最后一次commit），除了这些简单的形式，你还可以附加一个指定的日期或时间作为参数，意思是“参考此时”。这个功能在某些时候会变得非常有用。比如你在处理***中出现的一个bug时，你对自己说：“这个功能昨天还好好的，怎么改了？”屏幕的gitlog输出试图弄清楚提交何时被更改，你可以简单地运行gitdiffHEAD@{yesterday}你会看到自昨天以来的所有修改，这也适用于更长的时间段（例如gitdiffHEAD@{'2个月前'}）和确切的日期（例如gitdiffHEAD@{'2010-01-0112:00:00'}）。您还可以将这些基于日期的修改参数与任何使用修改参数的Git子命令一起使用。gitrevisions手册页详细说明了要使用的格式。12.Omniscientreflog你有没有试过在rebase期间杀死某个提交，后来发现你需要从这个提交中保留一些东西？你可能会觉得这些提交永远丢失了，必须重新开始。不是真的，但是如果你在你的本地工作副本中提交，提交会进入“reflog”，你仍然可以访问它。运行gitreflog将显示本地工作副本中当前分支上所有活动的列表，并为您提供每次提交的SHA1值。一旦找到你在rebase时放弃的提交，你可以运行gitcheckout检出提交，复制你需要的信息，然后运行??gitcheckoutHEAD返回到分支***的提交。希望这些技巧中至少有一个能教给您一些关于Git的新知识。Git已经12岁了。在这个不断创新和添加新功能的项目中，您最喜欢哪个技巧？
