让你成为Git和GitHub大神的20个技巧

Git不仅是编程世界最流行的分布式版本控制系统，而且你还可以用它查找，分享以及优化你的代码。接下来就来看看怎样让Git和GitHub更好地为你服务吧。

尽管现在网上有很多Git的初学者教程，而且 GitHub自己也提供相当一部分教程 ，但是要找到有效提高开发者使用Git和GitHub使用效率的技巧还是不太容易的，所以我们就来教大家一些方法吧。

对Git或者GitHub不熟悉的人来说，接下来的几段话会提供充分的背景知识使得您更好地理解使用技巧。在文章结尾我们会列出一些实用的资源。

Git是一个分布式版本控制系统，它由 Linus Torvalds 2005年在Linux内核社区的帮助下创作完成。我并不是要向你吹嘘Git，所以我就不向你不拉不拉它到底有多快多轻便多灵活多受欢迎了，但是，当你复制Git储存库时，你应该知道这些，你可以在本地电脑上获得完整的历史版本，而不是一次一个分支的快照。

Git起初是作为命令行使工具，为它的东家Linux内核社区服务。你仍然可以使用Git 命令行，但这并不是必要的。特别是，如果你使用GitHub作为你的主机，你就可以在Windows 或者 Mac系统中免费使用GitHub客户端。从另一个角度看，Git命令行在任何主机上都适用，而且它在大多数Mac和Linux系统中都是预装的。

只有你能决定命令行和具有图形用户界面（GUI）的原生客户端到底哪个更好用。如果除了GitHub客户端（Windows和Mac系统），你还喜欢GUI，你可以考虑看看 SourceTree (Windows和Mac系统，免费)， TortoiseGit (Windows系统，免费)，以及 Gitbox (Mac系统, $14.99)。或者你可以用一个支持内部使用Git的编辑器或者IDE=（参见技巧11）。

现在在GitHub以及其他开源的Git库上都有很多有意思的项目是可以免费复制到你的电脑上的。而你又为什么会想要这么做呢？原因之一是想学学别人的代码风格、实践、以及感兴趣的编码语言工具，还包括提交日志评论的风格吧（详情看技巧4）。原因之二可能是想看看一个给定的项目是如何最终达到它的目标的吧。原因之三，既然证书允许你这样做并且这样做对实现你的目标是非常有意义的，那么把这些项目纳入你的努力和产品之中也是非常合理的。顺便多看一遍许可证，以防将来出现合法性问题的争论。

手册页的git clone 定义：

复制一个库到一个新建的目录下，在复制的库中为每一个分支创建一个远程跟踪分支（可视化使用git branch），然后创建并检查从复制库中当前激活的分支派生出的初始分支。

在复制之后，一个没有获取参数的 git fetch将更新所有远程跟踪分支，此外 git pull还将把远程主分支合并到现有的主分支。

用Git把自己弄得一团糟的最简单的方法之一（在其他版本控制系统也适用）就是允许文件不同步。如果你经常在git中进行拖拽，你复制的库的版本将会保持最新，由于合并很好理解和达成，所以你有机会将你改动的代码和其他人的改动合并在一起，当然最理想的是它能够简单到可以自动完成合并。要使用此技巧的话你就必须时刻监视你的项目状态。许多Git客户端会自动提示你需要更新以保持最新。

每次提交都是对项目的粒度更新，它包括一个或多个文件的改动。把它看成是对已完成的工作的单位记录，可以作为一个逻辑整体应用到项目中或从项目移除。即使是在测试之前也要记得提交你完成的每次逻辑变动。你的每次提交都只适用于本地储存库。参见技巧4和5对本技巧的推论。

手册页对 git commit的定义：

在一次新的提交中储存当前的指数内容并提交用户描述改变的日志消息。

世界上有10种程序员：描述他们的提交的，还有不描述提交的。（呵呵，老笑话啦。提示：我用的基数是什么？）

我承认我非常坚持提交日志消息是很好的习惯。我把我的储存库设置成每次都需要提交日志消息，而且我是出了名地爱发送烦人的深夜消息，尤其是当我以XX的顺序提交日志的时候。如果你是这种坚持认为（1）代码应该“为自己代言”（2）在线注释远比改变日志重要的开发者，请试试复制一个你以前从来没见过的储存库，并分辨在没有阅读所有代码之前可能产生最新问题的最新提交。所以你可以看到，精确的提交日志简直是双倍的好啊。

我知道的最近发生的Git相关bug的大悲剧就是一个外包公司从Subversion切换出来的时候，他们的开发者并没有被训练过如何分辨分布式源代码控制和集中式源代码控制。在大约一个月后，那个项目开始产生一些任何人都没办法追踪的bug。在每天的会议上，负责那个应用出现奇怪bug部分的开发者就会抗议道：“我两个星期前就修复了那个bug了！”，或者指责另外一个开发者没有上传他们万分仔细检查过的改动。

最终，发现了那个问题的人教会了所有开发者如何以及在何时 push 他们的提交：长话短说，就是当你的提交在本地成功通过测试的时候。然后那个公司在可以创建并部署最新的集成项目之前，他们进行了长达两天的合并行动。

Git相对于其他分布式控制系统来说，最大的优势就是它的合并做得很好，至少一部分原因是因为Git在合并时选择的都是最好的原型。大多数软件开发者需要更经常地在他们的项目中创建分支了。它应该成为每天的日常事件，而不是一个全体战略会议的主题。最大的可能性是，当你的分支项目已经完成，通过，并且打算转向主要项目时，这时合并就不会出现无法克服的问题了。

我知道这需要一些调整，尤其是你的公司是使用CVS进行源代码控制的话。但是还是要试试啊。总比你的用户意外发现了你的主线项目必须因为一个破坏性的bug被迫发布的时候遗留的一些未完成的实验性代码要好得多。（ 这篇文章 解释了基本的分支和合并）

用Git进行合并通常来讲是应该进行得很顺利的，但是之前如果你不进行谨慎的思考的话，偶尔你也会喷到一些困难。第一步首先要确保你没有未提交的改动。git merge手册页上说道：

在你进行任何的外部改变之前，你应该先使你的任务保持在基本完好的状态并在当地进行提交，所以在产生冲突的时候不至于彻底崩溃。参见git-stash。

更多详情参见技巧8。

即使在一次git合并过程中你完全失败了，也不至于遭受太大的损失：

即使你的合并导致了非常复杂的冲突并且想要重来一次，你可以通过 git merge —abort进行修复。假设你是用GUI来进行合并的话，git merge的后续命令通常是git mergetool。如果你更喜欢传统的方法，那么你可以编辑与你最喜欢的编程编辑器冲突的文件，完全移除 <<<<<<<, =======, 和 >>>>>>>，把修订过的文件保存后，再进行记录更新。

一个软件开发者的工作流程很少是线性的。用户常常会抱怨产品的bug，经理常常会优先考虑你并不想要在上面浪费时间的门票，而你呢，你自己可能会随时改变你想要做什么的想法。

现在在你面前，有三份提交过的文件待发行，还有第四份文件在一个已经修订过但是是不工作的状态。（git status命令会告诉你所有这些信息，如果你刚好不记得你的进度的话。）突然之间你需要对产品版本的bug进行修复。你需要快速地切换分支，但是你做不到，因为你的工作目录一团糟，而且你不想放弃你两个小时的辛苦工作。

进入git stash。好啦！你可以看到你所有的改动都保存在WIP（进程中）里面，而且你可以从你干净的目录切换到产品分支。当你把产品部分处理完毕，你就可以通过git stash apply切换回你之前在做的工作啦。

GitHub “gists”—分享代码片段—非Git格式，但是他们使用Git。所有的gists都是Git 库，而且 GitHub Gist 使得他们分享起来很容易。你可以在公共gists通过主题、编程语言、分叉状况以及获得Star的状况搜索Gist。你还可以创建私密的gists并通过URL分享他们。

很多有趣的开源项目在GitHub上都有代码库。 Explore GitHub 提供了找到这些项目的浏览界面，但是在大多数情况下在搜索框敲几个项目名称的字母可能还更快找到它的库。例如，输入 jq、back或者ang你就能找到主要的前三名开源JS框架。