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）。
Git/GitHub 小技巧1: 复制几乎所有内容
现在在GitHub以及其他开源的Git库上都有很多有意思的项目是可以免费复制到你的电脑上的。而你又为什么会想要这么做呢？原因之一是想学学别人的代码风格、实践、以及感兴趣的编码语言工具，还包括提交日志评论的风格吧（详情看技巧4）。原因之二可能是想看看一个给定的项目是如何最终达到它的目标的吧。原因之三，既然证书允许你这样做并且这样做对实现你的目标是非常有意义的，那么把这些项目纳入你的努力和产品之中也是非常合理的。顺便多看一遍许可证，以防将来出现合法性问题的争论。
手册页的git clone 定义：
复制一个库到一个新建的目录下，在复制的库中为每一个分支创建一个远程跟踪分支（可视化使用git branch），然后创建并检查从复制库中当前激活的分支派生出的初始分支。
在复制之后，一个没有获取参数的 git fetch将更新所有远程跟踪分支，此外 git pull还将把远程主分支合并到现有的主分支。
用Git把自己弄得一团糟的最简单的方法之一（在其他版本控制系统也适用）就是允许文件不同步。如果你经常在git中进行拖拽，你复制的库的版本将会保持最新，由于合并很好理解和达成，所以你有机会将你改动的代码和其他人的改动合并在一起，当然最理想的是它能够简单到可以自动完成合并。要使用此技巧的话你就必须时刻监视你的项目状态。许多Git客户端会自动提示你需要更新以保持最新。
Git/GitHub小技巧3: 尽量提交得又快又频繁
每次提交都是对项目的粒度更新，它包括一个或多个文件的改动。把它看成是对已完成的工作的单位记录，可以作为一个逻辑整体应用到项目中或从项目移除。即使是在测试之前也要记得提交你完成的每次逻辑变动。你的每次提交都只适用于本地储存库。参见技巧4和5对本技巧的推论。
手册页对 git commit的定义：
在一次新的提交中储存当前的指数内容并提交用户描述改变的日志消息。
Git/GitHub 小技巧4:像要求别人的提交描述一样要求你自己的
世界上有10种程序员：描述他们的提交的，还有不描述提交的。（呵呵，老笑话啦。提示：我用的基数是什么？）
我承认我非常坚持提交日志消息是很好的习惯。我把我的储存库设置成每次都需要提交日志消息，而且我是出了名地爱发送烦人的深夜消息，尤其是当我以XX的顺序提交日志的时候。如果你是这种坚持认为（1）代码应该“为自己代言”（2）在线注释远比改变日志重要的开发者，请试试复制一个你以前从来没见过的储存库，并分辨在没有阅读所有代码之前可能产生最新问题的最新提交。所以你可以看到，精确的提交日志简直是双倍的好啊。
Git/GitHub 小技巧 5:当你的改变被测试时进行推送
我知道的最近发生的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。如果你更喜欢传统的方法，那么你可以编辑与你最喜欢的编程编辑器冲突的文件，完全移除 <<<<<<>>>>>>，把修订过的文件保存后，再进行记录更新。
Git/GitHub小技巧8:在进行分支切换之前记得保存
一个软件开发者的工作流程很少是线性的。用户常常会抱怨产品的bug，经理常常会优先考虑你并不想要在上面浪费时间的门票，而你呢，你自己可能会随时改变你想要做什么的想法。
现在在你面前，有三份提交过的文件待发行，还有第四份文件在一个已经修订过但是是不工作的状态。（git status命令会告诉你所有这些信息，如果你刚好不记得你的进度的话。）突然之间你需要对产品版本的bug进行修复。你需要快速地切换分支，但是你做不到，因为你的工作目录一团糟，而且你不想放弃你两个小时的辛苦工作。
进入git stash。好啦！你可以看到你所有的改动都保存在WIP（进程中）里面，而且你可以从你干净的目录切换到产品分支。当你把产品部分处理完毕，你就可以通过git stash apply切换回你之前在做的工作啦。
Git/GitHub小技巧9：使用gists来分享snippet和paste
GitHub “gists”—分享代码片段—非Git格式，但是他们使用Git。所有的gists都是Git 库，而且GitHub Gist 使得他们分享起来很容易。你可以在公共gists通过主题、编程语言、分叉状况以及获得Star的状况搜索Gist。你还可以创建私密的gists并通过URL分享他们。
很多有趣的开源项目在GitHub上都有代码库。Explore GitHub 提供了找到这些项目的浏览界面，但是在大多数情况下在搜索框敲几个项目名称的字母可能还更快找到它的库。例如，输入 jq、back或者ang你就能找到主要的前三名开源JS框架。
既然你常常浏览开源项目，为什么你不贡献一些呢？其实这并没有你想象的那么困难，而且你可以从中学习到很多哦。举个栗子，你可以复制jquery/jquery (jQuery Core)项目，然后在README.MD中进行浏览，在最上方你会看到：
本着开源软件开发的精神，jQuery总是鼓励社区代码贡献。为了帮助你在敲代码之前能有一个好的开始，请你确保你认真阅读了以下重要的贡献指南……
后面又三个链接。第一个链接可以使你快速起步。并不是所有的开源项目都能很清晰地列出他们的计划，但是他们都在尝试。
理解做为一个贡献者和提交者的不同。一个贡献者是已经签了所需协议并且对项目做出有益贡献的。一个提交者是被授权上传项目库所需要的贡献的。因为在提交者对你的贡献进行测试的时候是有延迟的，而且你也不想绑定你的主分支，所以你应该在发送pull请求（参见技巧16）之前在你的另外一个分支当中进行修改（参见技巧6）。
Git/GitHub小技巧12：使用 “git it”的编辑器和IDE
如果你千辛万苦写了一堆代码，结果在你下次登录的时候，发现其他人也在编你那段相同的代码，你肯定觉得心好累啊。你可以通过使用集成Git的编辑器或者IDE来避免心累或者减少心累，它会告诉你你现在正在浏览的代码有了新的你需要Pull的提交，以及新的提交要实现的功能。
Git/GitHub小技巧13：Fork a repo
Fork一个库意味着创建属于你自己的代码库可编辑服务器拷贝，也就是说，在路径中创建一个fork。如果它是一个我们没有提交权利的公有库（参见技巧11），那么贡献我们的修改的最简单的方法就是在服务器端把它们托管在我们自己的fork中，此方法可通过初始的GitHub项目底部的fork按钮实现。然后我们就可以向fork库的所有者提出pull请求（参见技巧16），它们才有可能测试并采用我们的贡献。开始的时候你可能会懵逼，但是后面就会越来越轻松啦。例如，请参见本书部分，介绍对一个小型公共项目的贡献。
当你fork一个项目的时候，你肯定想知道你的上游项目发生了些什么。如果是这样的话，请查看repo。如果你觉得更新提示很烦，无视它就好。如果你注意到会影响你的改动，提取并并到上游提交项目合。
GitHub建议你以一种“不恶心的方式”关注GitHub员工。你还应该关注上传你感兴趣项目的人，然后那可能可以拓展另外你可能感兴趣的项目。我在GitHub上关注了dmethvin，但是完全不是令人恶心的方式哦，因为在他还在PC Tech Journal的时候我们就曾经断断续续地共事过，然后现在他已经是jQuery基金会的主席啦。
Git/GitHub小技巧16：发送pull request
在技巧13当中，我们探讨了如何fork一个GitHub库。用上游库（fork之后变成你的库）合并一些或者所有的改动的方法就是向它们发送一个pull request，参照这个指南。
所有的软件都有bug。许多软件项目采用单独的bug跟踪系统，但是有些人在GitHub中会使用 Issues feature。你可以通过向一个项目报告bug来展现你的牛逼，如果能解决的话就更加牛逼啦
Git/GitHub小技巧18：写有趣的README内容
在技巧11，我给你了jquery/jquery 的页面来让你了解这个项目。为你的项目写个有趣的README内容，你不会后悔的哦。
自从上世纪60年代以来，README在软件开发领域就成了一个既定的规范，当我看到我的第一份README文档以全大写字母的形式在绿白相间的纸上打印出来，还包装着一堆字符卡，那时候企图在1940年的IBM计算机上运行。在70年代我就看到更多啦，在我还在研发DEC迷你计算机和大型IBM电脑主机的时候，在所有可以想象到的媒体以及操作系统上你都可以看见。参见REAMDE。
Git/GitHub小技巧19：使用Markdown
早期的大写字母README文件只是一个雏形。现在标准的格式化README文件都是Markdown, 尤其是 GitHub 味儿的Markdown。我以前还看见过HTML格式的README文件，但是这种形式慢慢地好像消失了。
Git/GitHub小技巧20：转化你的旧有repo到Git
上面所有我列出的技巧，这个可能是最难实现的，不论是在技术上还是政治上。政治方面主要是因为程序员天生对他们的工具是比较保守的。这需要在训练中加以解决。
要转化一个大型的，历史久远的，存有上百万行的代码，数以万计的提交，还有因为使用公吨的储存记忆而产生的成千上万tag的库在技术上也是非常困难的。我有一个几十年的CVS库，只能在大型或者加大型的亚马逊EC2实例当中进行转换，而且他们依然需要几天的时间才能转换完成。如果你是从Subversion进行转换，你可以试试 svn2git。如果你是从CVS进行转换，可以考虑git -cvsimport 和cvs2git。
