不归路还行。

其实今天只不过是注册了github，其中也有踩到了不少的坑，所以今天打算造福下人民群众，提前告诉大家今天所遇到的问题，也方便我以后自己查找。本文大概需要十分钟左右阅读，主要内容大多翻译自github官方的指南，有什么不正确的地方，啊，概不负责。

什么是GitHub？

一个成熟的版本控制应用。版本控制在如今的团队协作中是必不可少的，毕竟我们不希望一个实习生修改了对于我们业务十分重要的代码而我们却无可奈何，更不希望离职的同事将代码压缩成FUCK的样式从而让下一任接手的程序员心里骂娘，所谓的版本控制，便是对于这些的最终解决方案。

所谓版本控制的核心，其一是可回滚的多重备份，其二是对于冲突的解决，这也就引入了所谓的branch。 Branch用通俗的话来说便是针对某种东西的副本。以网站开发为例，如果前端小姐姐（并不存在）想要在我们的主页上添加一个按钮，那么她就可以fork一个Branch，并在这个Branch中进行他想要的更改，等到她的更改结束后，她可以提交一个Pull request，而相关负责人就可以处理冲突并且将这个branch合并到主干当中。

这样子有效避免了对于代码的恶意修改，而对于严重异常的处理也变得容易，只需要回滚到上一个安全的版本即可。而上述所说的一切操作，都必须通过版本控制来进行。

流行的版本控制有很多，但严格说起来比较通用的架构只有两种，SVN和GIt，SVN是一种集中式的版本控制，简单来说就是所有的代码都在中心服务器上，任何对于业务代码的提交和修改都必须立刻解决冲突，而中心服务器无法通讯时，svn当然也就无法使用了。而git则是一种分布式的解决方案。对于每一个Fork的Branch都可以独立的进行版本控制，仅仅只在合并时需要和Master通讯。而小作坊的我们当然更加偏爱git，而git最为著名的发行版也就是所谓的github，也就是我们今天所介绍的应用。

使用github不需要任何编码基础，（虽然对于我们来说这也不一定是优点），同样，github也不仅仅只能管理代码的版本,也可以管理诸如word文档，财务报表等。下面我们就开始介绍如何从零开始使用GitHub。

如何使用GitHub

首先，你需要注册一个GitHub账号，我想这应该不需要额外写什么，在完成账号的注册后，你首先需要建立一个仓库（Repository），所谓的仓库，一般来说都是对应一个项目，比如一个程序，一个网站，你可以简单的按照字面意思来很好的理解所谓的仓库指的是什么。一个仓库可以包含文件夹，和几乎任何类型的文件，简单的来说，可以视为你电脑上的一个文件夹，你可以把任何你需要的东西传入文件夹。在这里不得不说一句，我非常推荐阅读文章的各位下载一个Github的桌面客户端，它可以直观的将本地文件库和远程服务器端连接起来，只需要在软件中创建一个新的仓库，那么剩下的一切，GitHub都会帮你完成。

在创建库的时候，一个很重要的选项就是生成一个Read me 文件，虽然我们都心照不宣的从来都不会看软件的readme，但即使是为了自己的成就感来考虑我们都应该这样做。更何况GitHub还会将这个readme默认为仓库的封面。

在创建库时另外一个选项便是选择库的可见性，如果是免费版便只能开源，而每年84刀便可以享受私有库的待遇，虽然并没有什么卵用，但若是你在为一个公司工作，那么还是尽量不要为你的老板省下这些钱了，毕竟开发起来说不定还会有一些敏感的东西泄露。

在点击Create Repository后，你的库讲道理就准备就绪了，这个时候你可以像你从来没有用过GitHub那样正常的编程，也可以打开刚刚我推荐你下载的客户端，打开正确的库和正确的Branch，在你的代码上随便修改几笔，然后你就可以见证GitHub自动显示了你所做出的修改。而这时你只需要决定是否把这些修改保留。

使用红色标出的是删除的内容，使用绿色标出的则是增加的内容，而你所要提交的改动则是一种鲜艳的蓝色。你可以任意的修改，选择你所需要修改的内容，并在确认后，随便在Summary里填点什么后，点Commit to BRANCH_NAME，，就可以在GitHub上看到你今天的提交状态又是一片喜人的绿色。

在这些基础操作之后，重要的就是接下来的两个高级操作了。创建一个Branch以及合并一个branch。

严格来讲，创建一个Branch本身并没有什么难度，你只需要掏空心思为你的branch想一个好听的名字即可，然而决定创建Branch却需要深思熟虑。首先我们需要一个上线的版本，也就是所谓的Master，这个版本是我们所有Branch之中最为稳定的，在他之下是任天堂玩家，不，是我们的beta，这个Branch是我们合并了Master和Feature之后的产物，在Beta足够稳定后，我们会把他合并到Master中。而在那之下，则是feature。每个Feature都代表了一种软件新增的特性，而我们每增加一个特性，最好也就创建一个新的Feature Branch。

在创建完Branch后，我们可以在这个Branch进行任何我们所喜欢的开发，而不必担心这种开发影响到正常的业务。这也就是所谓的生产和开发环境分离。

而合并一个Branch则需要处理者更多的经验，因为Feature所基于的Master很用可能已经和如今的Master已经有重大的区别。决定保留哪些代码，删除哪些，都是需要很强的处理能力的，然而这对个人开发者来说并不是什么难事，毕竟大多数开发者还是可以阅读自己一个周之前写作的代码的（虽然更久就不一定了）。

而对于合并请求的提交者来说，所需要的只不过是提交一份写明所有改动的readme来换取面包和啤酒，这也就是所谓的互联网公司的技术总监的轻松生活背后的真相。

我觉得以上已经把Github 的基础用法讲解的差不多了，如果还有其他问题的，还可以继续去这里做拓展阅读。

一个重要的命名标准

啊，终于也到了我制定命名标准的时候了。

简单介绍下代号

s代表首字母

a代表全部字母

在没有s时a也包括首字母。

例saSa =第一个单词首字母小写，其余单词首字母大写。

AA=所有字母大写

a_a=单词全部小写并用下划线隔开

那么了解了这种规则后，我就用这种规则来简单说一下我如今使用的命名规则。

函数名：saSa

类名：SaSa

属性名：saSa

方法名：saSa

常量名：AA

本地临时变量名：tmp，i，t。