网站的运营与管理,4000套微信小游戏源码,wordpress网站搬家,上海响应式网站设计转载自 Git 12 岁了#xff0c;送给你 12 个 Git 使用技巧Git#xff0c;一个分布式版本控制系统#xff0c;它已经成为了开源世界的源码控制默认工具#xff0c;在4月7号12岁了。但是使用Git中更另人沮丧的是#xff0c;你需要了解多少才能让你更有效的使用它。同时这也是…转载自 Git 12 岁了送给你 12 个 Git 使用技巧Git一个分布式版本控制系统它已经成为了开源世界的源码控制默认工具在4月7号12岁了。但是使用Git中更另人沮丧的是你需要了解多少才能让你更有效的使用它。同时这也是使用Git中比较美妙的一件事因为没有什么比发现一个新的小技巧来简化或提高你的工作流的效率更加令人快乐了。
为了纪念Git的12岁生日这篇文章提供12个诀窍与技巧来让你的Git经验更加有用和强大从一些你可能会忽视的基础开始到一些真正的强大技巧!1. 你的 ~/.gitconfig 文件
在第一次用git命令来提交一个仓库的修改你可能会首先看到像下面这种内容*** Please tell me who you are.Run git config --global user.email youexample.com git config --global user.name Your Nameto set your accounts default identity.
你可能还没有意识到那些命令正在修改~/.gitconfig文件的内容这个文件就是Git存储全局配置选项的文件。通过你的~/.gitconfig文件你可要做很多事情包括定义别名永久的打开或关闭一些特定的命令选项还可以修改Git如何工作的方面例如git diff使用哪个diff算法或者默认使用什么类型的的合并策略。你甚至可以按条件地基于路径包含其他配置文件到一个仓库使用“man git-config”查看所有细节。
2. 你的仓库的.gitconfig文件在之前的技巧中你可能会想知道在git config 命令中的—global标识是做什么的。它告诉Git更新“global”配置也就是~/.gitconfig发现的这个配置。当然拥有一个全局的配置代表了一个本地配置而且足够肯定的是如果你省略—global选项git config 会更新这个仓库自己的配置这个配置文件存储在.git/config。
在.git/config中设置的选项会推翻在~/.gitconfig文件中的对应设置。因此例如如果你需要在一个特定的仓库中使用一个不同的邮箱地址你可以运行“git config user.email also_youexample.com”。然后你在这个仓库中提交会使用你单独配置的这个邮箱地址。如果你使用一个工作的电脑在开源项目中工作但是希望在这个项目中使用个人的邮箱地址而其他在主Git配置中仍然使用工作邮箱这一点是非常有用的。
在~/.gitconfig中可以设置的任何东西都可以在.git/config中设置来对这个仓库做特定设置。在下面的这些技巧中当我提到在你的~/.gitconfig文件中添加什么东西同时也说明可以在特定的仓库的.git/config中添加来设置那个选项。
3、别名
别名是你可以在你的~/.gitconfig文件里做的另外一件事。他的工作原理就像shell命令行里的别名——设置一个新的命令名称来调用一个或者多个其他的命令这些命令通常包括一些特定的选项或标识。别名对于你经常使用的那些又长又复杂的命令行是非常有效的。
你可以使用git config命令来定义别名——例如执行”git config —global —add alias.st status”命令后会使得执行git st与执行git status做的是同样的事情——然而我发现当定义别名的时候只需要直接在~/.gitconfig文件里编辑通常会更加容易。
如果你选择这么做你会发现~/.gitconfig文件就是一个INI文件INI是一种带有特定段落的基础键值对文件格式。添加一个别名时你将改变[alias]段落。例如上面提到的定义相同的git st别名需要添加下面这段代码[alias]st status
如果已经有了[alias]这个段落只需要在这个段落中添加到第二行
4. shell命令中的别名别名不仅仅是运行其他Git子命令——你也可以定义别名这些别名可以运行其他shell命令。这是一个很好的方法来处理一个重复的、罕见的、复杂的任务一旦你已经想到第一次怎么做那就使用一个别名保存这个命令。例如我有几个仓库是我fork了一个开源项目而且在本地做了一些修改这些修改不用贡献给这个项目。在项目的持续的开发的过程中我想保持最新的版本同时保留我的本地修改。为了完成这个想法我需要定期地从upstream仓库中合并这些修改到我的fork——我定义一个别名“upstream-merge”来完成这个操作。定义如下upstream-merge !git fetch origin -v git fetch upstream -v git merge upstream/master git push
别名定义开始的这个“!”是告诉Git来通过shell运行这个命令。这个例子包括了运行一些git命令但是使用这种方式定义别名可以运行任何shell命令。
注意如果你想复制我的upstream-merge别名你将需要确认你有一个Git remote命名为upstream来指定这个你fork的upstream仓库。你可以通过“git remote add upstream ”来添加一个。
5. 可视化提交图如果你从事的是一个有很多分支活动的项目有时可能很难掌握所有正在发生的工作以及它们之间的相关性。各种GUI工具可让你弄清楚不同分支的概况以及在所谓的“提交图”中提交记录。例如以下是我使用 GitLab 提交图查看器进行可视化的一个存储卡的部分截图John Anderson, CC BY
如果你是专注于命令行的用户就可以不在多个工具之间切换导致分心这个工具在命令行上实现了类似图形界面的提交视图。通过 -- graph 参数获取 git 的记录 John Anderson, CC BY
下面的命令可以得到一样的仓库可视化片段git log --graph --prettyformat:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset --abbrev-commit --daterelative
--graph 选项将图表添加到日志的左侧 --abbrev-commit 存储提交使用了 SHA 方法 --daterelative 表达式用相对的术语来表示日期并且 --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 岁了在这个持续创新不断添加新特性的项目里你最喜欢哪个技巧
