Github使用指南（转）

来自：https://github.com/neuola/neuola-legacy/wiki/github%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97

Github使用指南

如果你只是想了解 github 的使用，请跳到 Github 简介一节。

版本控制简介

至于什么是版本控制？作为程序员大军之一，想必大家有这样的经历吧。开始一个项目的时候，脑子一热，把程序一下子写了七七八八了，然后慢慢地到了瓶颈了，要实现新的功能，要改变某些结构。这个过程肯定是有很大风险的，说不定改变的时间要很长。但是客户又在催着要代码，那就为当前的版本起一个版本号吧，然后复制一份来重新改写部分，如果写好了，就交新的代码，改不好就又回到原来的版本。至少还可以交差。版本控制工具的原理也是这样，只是这个工具把代码都压缩存储了，省得自己手工复制代码然后存储。
然后我们来看看另一个场景。一个团队的人希望合作开发一个软件，为了让所有人都看到最新的改动，他们把代码放到一个 ftp 上，然后每个人做完自己的工作后，上传到 ftp 然后替换相关的文件。但是，我们知道，软件的开发很难做到完全不耦合，或者两个人的指责是相同的，只是工作时间不同，他们的更改很可能有冲突。于是，要么两个人消极地等待对方进行修改然后自己再修改，要么两个人过于积极以至于每次更改都要仔细看看对方的代码有没有和自己的冲突，费劲地更改代码。而版本控制工具则提供了一种更好的方法，可以自动合并修改（如果没有冲突的话），或者，如果遇到冲突就对用户进行提示。
为了更好地进行团队协作开发，我们引入 git 作为版本控制工具。

Git
以及 Github 简介

Git 是 Linus 在开发 Linux 内核时用于替换 Bitkeeper 版本控制工具（该工具不是免费的）而写的一个开源的分布式版本控制软件。而Github 是一个代码托管网站。而代码托管的意思是允许人们把代码放到
Github ，并为团队开发提供一种比较简单的代码同步方法。Git是一个分布式的版本控制工具。分布式主要是针对已有的 SVN 、CVS 受中央控制的版本控制工具而言的。在git里，每个代码库在相互独立的同时，又可以相互交换代码（通过push/pull）进行代码的交换。这里主要介绍Github在
Windows 上的使用。

安装
Github for Windows

在http://windows.github.com/上下载 Github for Windows ，按提示安装即可。在安装过程中，git 的命令行版本也会一并安装。虽然在 Windows 下大多数应用都是基于图形界面的，但是使用
git 还是很有必要用命令行。
Github for Windows 实际上是 Github 网站的客户端版本，有网站上的一切功能，并且，为上传、更新位于 github.com 的代码库进行了良好的支持。使用 Github 帐号登陆以后，在图形界面里可以轻易地创建代码库。

Git
常用命令使用

命令行里

git

的命令列表以及解释：

git
clone <address>

：复制代码库到本地。

git
add <file> ...

：添加文件到代码库中。

git
rm <file> ...

：删除代码库的文件。

git
commit -m <message>

：提交更改，在修改了文件以后，使用这个命令提交修改。

git
pull

：从远程同步代码库到本地。

git
push

：推送代码到远程代码库。

git
branch

：查看当前分支。带

*

是当前分支。

git
branch <branch-name>

：新建一个分支。

git
branch -d <branch-name>

：删除一个分支。

git
checkout <branch-name>

：切换到指定分支。

git
log

：查看提交记录（即历史的 commit 记录）。

git
status

：当前修改的状态，是否修改了还没提交，或者那些文件未使用。

git
reset <log>

：恢复到历史版本。
看了这些命令以后，对里面的名词肯定有所疑问。代码库应该很好理解，就是存放代码的地方，而在 

git
clone

 里，代码库一般指的是远程的代码库，即 github 给出的链接。而分支则是开发的一个阶段或者一个旁系版本，至于怎么定则取决于使用者了。例如，有一个分支叫做

stable

，代表里面的代码是经过测试的、稳定的；另一个分支叫

dev

，则是保存开发中的代码，不一定经过足够测试。

一般的开发流程

一般使用 git 的流程： 1. 编辑文件，更新代码。 2. 添加代码到当前待提交的更改列表中：

git
add <修改的文件>

。 3. 提交当前修改作为一个记录：

git
commit -m '修改了<修改的文件>，原因是：……'

。 4. 更新代码：

git
push

。

常见问题

这里的常见问题只是基于我的使用经历，如果有错或者有更好的想法，留言通知我~

什么时候提交更改记录（ commit ）？
这个问题其实很随意，新增一个特性或者破坏了原有结构，甚至每一次改动都可以作为提交更改记录的依据。

什么时候推送更新（ push ）？
一般来说，更改了项目的结构（包括文件、目录），就应该尽快推送更新，以通知其他协作者跟进这个更新。对于其它细微的修改，没有破坏到别人的工作的，可以随自己的想法更新（如果是提交了某些激动人心的特性，就赶紧推送给别人分享吧~ ）
不过切记，更改了目录结构、文件结构等一定要在

commit

中写清楚，否则别人可能还是一头雾水。

什么时候和远程同步（ pull ）？
每次开始工作前都应该同步一下，以免自己的修改和别人冲突或者别人做了结构性的调整和自己的修改不协调了。

分支（ branch ）的使用？
至于远程分支的使用，可以参考 github 的推荐方法功能划分方法，来自，就是说，每一个功能设定一个分支，当修改完成以后再合并到 

master

 ，保证 

master

 分支是可用的。
对于本地分支（就是本地代码库的分支了，这两个是不同的概念哦，记得 git 是分布式的，每个代码库有关联但又互相独立），使用就比较随便了。主要是方便自己开发即可。

怎么解决冲突（ conflict ）？
在团队开发中，同时对某一个文件进行改写是常见的事，但是我们应该尽可能避免。每个模块之间应该进行良好的隔离。但一旦遇到冲突，git也有很好的解决方法。
在同步代码的过程中，git会自动检查冲突，并尝试进行自动合并。最好的情况应该是大家同时修改一个文件，但是大家修改的地方不同了。在这样的情况下，git会进行非冲突合并，这时，在调用 

git
pull

 的时候，git会尝试进行非冲突合并。
而在合并过程中有冲突的时候， git 会把修改记录直接保存在文件中，让开发者判断文件如何解决合并。例如，在一个描述文件中同时修改了一句话，在合并的时候，git会这么做：

<<<<<<< HEAD
It's not a project cool enough for you to enjoy the code but a mix of my thoughts in the year 2012~2013. I didn't know where the project leads to. Hope it will became useful after practice.
=======
It's not a project cool enough for you to enjoy the code but it's a mix of my thoughts in the year 2012~2013. I didn't know where the project leads to. Hope it will became useful after practice.
>>>>>>> 2b41083cf969979d8e4a1eedc987976af544d129

即把两个更改都写在文件上，但是用

=======

来区别发生冲突的位置，在

=======

以上是
HEAD，即本地的代码；而

=======

以下则是来自远程的更改了。这个时候，你可以选择保留远程或本地的修改或者都不要（简单地说，把不需要的内容删除即可）。

怎样恢复到历史版本（ reset ）？
使用 

git
log

 查看更改记录，记住其中的 commit 版本号，然后，运行 

git
reset <log> --hard

 即可（ 

<log>

 即
commit 版本号）。另外， 

git
reset HEAD

 可以恢复到上一个 commit 版本。
如果只是想把更改状态切换到某一个历史记录，那么，可以 

git
reset <log>

 这样，文件不会恢复到历史版本，但是，在这个记录后修改的文件会被标记为已修改，但未添加修改记录里。