git入门学习

一、Git与GitHub简介

1. Git

Git(global information tracker,全局信息跟踪器)是分布式版本控制系统，用来进行版本控制的。

2. 浅谈集中式与分布式

因为在下对集中式与分布式涉足的并不多，也可以说更多的是了解在理论方面，因此这里只是作为一个补充。 
(1) 集中式版本控制系统：其版本库是集中存放在中央服务器的，而各自工作的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始做各自的工作，各自完成各自的工作任务后，再把自己的任务推送给中央服务器。典型的代表是SVN和CVS。CVS作为最早的开源而且免费的集中式版本控制系统，直到现在还有不少人在用。由于CVS自身设计的问题，会造成提交文件不完整，版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题，是目前用得最多的集中式版本库控制系统。集中式版本控制系统的拓扑结构如下。 
 
集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟。 
(2) 分布式版本控制系统：分布式版本控制系统没有”中央服务器”，每个人的电脑上都是一个完整的版本库，这样，工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。当需要多个人协作的时候，比如说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。分布式版本控制系统的安全性较高，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法工作了。而且在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能你要推送版本库的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样工作，只是交换修改不方便而已。典型代表：git。其拓扑结构如下： 

3. Git与GitHub的关系

GitHub开源项目的托管平台,而Git是一种使用命令行的工具，GitHub使Git使用更方便。 
(1) GitHub DeskTop/Git客户端：https://desktop.github.com/ 
(2) GitHub: https://github.com/

二、GitHub的使用入门

1. 注册/登录

https://github.com/ 
略。

2. 创建仓库(create Repository)

一个项目如果被git控制了版本历史，在Github平台上就称为”仓库”(Repository)。 
(1) 通过如下两种方式进入到Repository首页 
 
或者 

(2) 创建仓库 

private一般指绑定了信用卡之类的。 
(3) 在Repository下创建新的文件 

下面对几个条目作简要说明 

- commit：用来进行版本控制的。这里的“1 commit”指的是目前只有一个版本； 
- branch：分支在后面会详细说明； 
- releases：帮助开发者分发其软件给最终用户的功能。当然用户也可以自行选择下载指定的分支，但 Github 的作者可以明确定义发行分支。这意味着你可以快速下载最新的软件发行版本，之前发布的版本也更加容易访问到； 
- contributor：项目的共享者，即协同开发的参与者。 

-New pull request：在后面会较为详细的说明，这里主要介绍Create New File。当点击Create New File后(如果该按钮出现灰色不能点击则点击一下Repository名即可再点击)会出现编辑File的界面，然后往下拉，可以看到如下界面： 

-1处：做版本留言，说明为什么要做这个版本； 
-2处：留言的详细说明； 
-3处：提交到哪个分支上，默认将版本做到master分支上。 
当点击Commit new file之后再回到创建的Repository可以查看到变为”2 commit”了。 

(4) 版本说明 
以最新提交的File1为例作说明 


然后看到如下的界面： 

- 1处：说明了提交的时间和提交人 
- 2处：parent 7b54ad5是43d38…..ce91版本的上一个版本。这个Parent就可以在多个版本中理清层次关系了。 
- 3处：表示的意思是显示了1个文件被修改，比较原文件有1处增加，0处删除。 
- 关于版本号：这里即为7b54ad5和43d38…..ce91，均为为40位的16进制数。前面那个可以展开，也是40位。在Git中的版本是一串数而不是1,2,3等。可以通过版本号来访问的相应的项目，当然这里的版本号也不一定需要全称，也可以取前几位来简称，只要能区别。结构如下： 
https://github.com/用户名/仓库名/commit/版本号 
比如说这里即为https://github.com/herdyouth/MyFirstRepository/commit/43d38

3. 删除Repository

进入到需要删除的Repository 

然后点击Settings进入到如下界面，可以进行Rename，然后拉到最低边，就可以进行Delete操作了 
 

本篇所谈的内容均是客户端Git的使用，以windows平台为例。 
下载地址： 
https://windows.github.com/ 
https://mac.github.com/ 
安装完成后会有一个GitHub和Git Shell。GitHub是图形界面模式，Git Shell是命令行模式

三、创建仓库以及文件的简单操作

1. 创建仓库

 
当点击”Create Repository”之后可能会报”An error occurred while creating the repository.You might need to open a shell and debug the state of this repo.”的错误，如下： 
 
我在Stack Overflow上看到的相似问题是要delete调.git的文件夹，但是我尝试了没有解决，不过奇怪的是，虽然报错了，但是依旧还是创建了该Repository。因此，你可以通过这种方法处理：直接忽略掉”Failed to …”，切换到Add(可能需要重启Git才能进行Add)，然后Browse选中相应的Repository即可。 
 
添加成功后如下： 

几个选项的说明： 
- Add：本地已经有项目了，输入该项目的路径。 
- Create：创建一个项目并存放在指定路径 
- Clone：将GitHub上的项目下载到本地

2. 关于添加项目(Add)再介绍

找到存放该仓库的文件夹(可以看到Github的仓库里都有.git 文件夹和配置文件)，然后将项目复制到该文件夹下，就会在GitHub客户端出该项目。可以选择自己的编译器来编辑该项目，只要没被commit成一个版本就可以一直编辑。 
例如将c语言文件写在创建的Repository里，然再利用C语言的IDE来进行编辑调试。 

 

3. 编辑项目

可以像上面那样用IDE编辑也可以直接双击打开后编辑

4. Commit

- 勾选框是用来选择需要commit的文件，选中的文件的修改会被做到下一个版本中。如下： 
 
- 蓝色为需要commit的部分，选中的代码部分的修改会被做到下一个版本中。如下： 

5. 发布与撤销

到上述commit为止，项目其实还并没有同步到Github上。进入到如下界面： 

- Publish：进行项目发布 
 
发布之后就阔以在Github平台上看到Git刚发布的项目了，如下： 

- Undo most recent commit：撤销还没有发布的版本。由于我刚才已经发布了，所以此处按钮变灰了。 

-Revert：撤销已经发布的版本。

四、分支与合并

1. 分支的实现原理

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。分为如下几种情况： 
(1) 只有一个主分支(master分支)：master指针移动 
 
HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的。HEAD指向的就是当前分支。一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点，每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。 
(2) 创建新的分支(Master指针不变，新指针移动) 
 
假设创建了一个idea新分支，Git会新建一个idea指针，跟master指针指向同一个版本，并不是拷贝历史线。同时，再把HEAD指向idea，就表示当前分支在idea上。不过，从现在开始，对工作区的修改和提交就是针对idea分支了，比如新提交一次后，idea指针往前移动一步，而master指针不变。 
 
你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。开发新代码又不想污染主分支(Master)这时候就需要创建分支。Master上的代码是随时可以放到服务器上运行的，所以测试性的代码不能放在其上。

2. 创建、切换、发布、删除分支

理论讲了那么多，现在来看看实际的操作。(PS:前几天没网，一直拖到了今天才写的) 
(1) 创建分支 
选择一个主干然后创建分支。 
 
(2) 发布分支 

发布之后可以看到Github上有两个分支 

(3) 删除分支 


这段英文提示很简单，下一步的操作我就不做说明了。同样的，删除也可以在远端GitHub网站上实现。 
(4) 同步操作 

这里可以将Github的内容同步到本地。

3. 合并分支

真正在服务器上运行的是master分支，所以创建的分支还是得合并到master分支上。 
假如我们在dev上的工作完成了，就可以把dev合并到master上。最简单的方法，就是直接把master指向dev的当前提交，就完成了合并。 
 
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支。 
 
合并分支又分为合并本地分支和合并远端的分支，同时可能要解决冲突问题。在后面的团队合作开发中要谈到的。

————————》》》》》》———无聊分割线—————》》》》》》——————–

这篇blog因为没网和其他原因导致拖了快一个星期，还有利用Git进行”团队协作开发”没有介绍，将在下一篇进行介绍，这也是最重要的一部分。下一篇主要进行“团队协作开发和合并分支”的介绍。我先把这篇发了吧。

之前所讲的都是“自娱自乐”，自己管理自己的项目。本篇主要是Git入门的尾声，也是最为精华的一部分，即利用Git进行版本控制，进行“团队协作开发”，也会介绍分支合并以及合并冲突时常见的处理方法。

五、团队协作流程

1. 基本流程

(1) 创建一个分支 
当你在开发一个项目的时候，一般在同一时刻你会同时展开多个想法，其中一些比较成熟了，另一些还是很初级的。有了分支就可以很好地来进行管理了。当你在项目中创建一个分支的时候，你可能就是正在搭建一个可以尝试新想法的环境。你在新分支上所做的修改不会影响到master分支，所以你能自由实验和提交修改。在被你的同事审核前，你的分支是不会被合并的。 
(2) 在新分支上添加新版本 
一旦你的分支创建好之后，就可以开始做些修改了。不论何时你添加，编辑或者删除一个文件，你就做一个版本，然后把他们添加到你的分支中。添加版本的过程就跟踪了你在一个功能分支上的工作进展。版本也为你的工作创建了一个透明的历史，其他人可以跟随着去理解你所做的工作以及为什么要这样做。没一个版本都有一条关联的版本信息，版本信息是一段描述，解释了为什么要做这样一个特定的修改。 
(3) Pull Request 
Pull Requst就是用来发起对你做的各个版本的讨论。因为Pull Request与底层的Git仓库代码是紧密相关的，任何人都能确切地看到你的Pull Request被接受后会有哪些代码合并起来。 
在开发过程中的任意时刻，你都可以开启一个Pull Request。当你有很少或没有代码但想要分享一些截图或基本想法的时候，当你陷入困境需要帮助和建议的时候，或者当你准备好让他人审核你的工作的时候，就需要Pull Request。 
(4) 讨论和代码审核 
一旦开启了一个Pull Rquest，审核你修改的人或团队会来提出问题和评论。有可能是代码风格不符合项目规范，也或者是代码忘了单元测试，也可能是各方面都没问题。Pull Request就是为了鼓励这种类型的讨论而设计的。 
根据别人对你所做版本的讨论和反馈，你也可以继续往你的分支上修改代码、推送代码等。 
(5) 合并分支，然后部署 
一旦你的Pull Request的所有代码经审核，通过了测试，就可以把你的代码合并到主分支上了。在把代码合并到Github上的仓库之前，如果你想测试代码或者是没有仓库的推送权限的话，你可以先在本地执行合并操作。 
一旦合并之后，Pull Request会保留代码的历史修改记录。因为它们是可搜索的，它们让人可以回到过去去理解为什么做这个决定以及怎样做的决定。

2. 实际操作

这里以herdyouth的仓库为例作说明。按照以下步骤进行团队内部的合作开发。 
(1) 给队友添加写权限 

(2) 接收通知 
这时youthherd的用户就会收到受邀的通知了。 

(3) 指定队友在相应的分支上继续进行项目开发 
可以看到被指定的队友youthherd只能在分支上进行Pull Request，而不能对Master进行操作。 

(4) 发布之前的讨论、修改、审核 
herdyouth在本地进行修改 

修改之后做成版本pull到Github上，注意选择相应的分支 

这时在herdyouth的Github上阔以看到Compare&pull request 

点击之后，则可以进行相应的讨论 

继续下拉则可以由颜色条明显的看到前后的变化 

再来看看被授予了权限的youthherd===》

进入到相应仓库主页之后，New pull request 

这里来选择比较的分支，然后进行讨论。可以一边讨论一边修改代码(在自己本地的相应分支上修改然后同步即可)，使用“:”添加表情。 



这时候，herdyouth又可以通过来查看所有的pull request 

=====》 
讨论结束后其中任何一方就可以通过Merge pull request来合并分支到Master上了，当然得确保分支无冲突。 

六、合并分支时的冲突解决

这里主要介绍一下，合并远端的分支以及解决冲突问题。由于我实践的不是很深，所以这一块是看的理论，有问题的地方我在后面的实践中会继续更正的。

同步冲突：如果A和B修改了同一个地方，而且修改的不同，在做版本的时候就可能出现同步冲突，因此在做版本之前A和B必须先商量，手动解决冲突，然后再做成版本。冲突在代码中”<<<<<<<，=======，>>>>>>>”标记出不同分支的内容。HEAD 表示本地分支，Origin/master表示远端分支，======是分隔符，分割冲突的两个分支的冲突地方。 

===========》无聊分割线============》 
过几天要着手蓝牙了，所以我想捋一捋之前所了解到的蓝牙知识，但是Github基础这一块还有最后一大点，即利用开源项目以及Githu的三套机制还没有介绍。我先占个位，免得排版断片了，到时候再补完整。

过几天要着手蓝牙了，所以我想捋一捋之前所了解到的蓝牙知识，但是Github基础这一块还有最后一大点，即利用开源项目以及Githu的三套机制还没有介绍。我先占个位，免得排版断片了，到时候再补完整。

七、Github 的“三件套”

1. GithubPage来搭建主页 https://pages.github.com/
2. Wiki
3. Issues(事务卡片)

八、利用开源项目