Github、Git使用教程

Git的使用

git是一个分布式版本控制系统

目的：通过git管理github托管项目代码

git的两大特点

• 版本控制：可以解决多人同时开发的代码问题，也可以解决找回历史代码的问题
• 分布式：git是一个分布式版本控制系统，同一个git仓库，可以分布到不同的机器上。首先找一台电脑充当服务器的角色，2小时开机，其他每个人都从这个“服务器”仓库份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。可以自己搭建这台服务器，也可以使用github网站

下载安装

官网：https://www.git-scm.com/download ， 但是官网速度非常慢，建议百度，并在国内网站下载

windows上安装

安装过程：大致流程省略，只讲一些注意点
安装过程组件的选择：
选择使用命令行环境
其他的选择默认即可

检验是否安装成功：
回到桌面，空白处右击，如果发现菜单中新增了Git GUI Here和Git Bash Here，即表明安装成功

Unbuntu上安装

• sudo apt-get install git

Git的基本操作

Git工作区域

• 工作区（Working Directory）

  即本地的项目区（工作的目录，有.git目录的目录），可以完成添加、编辑、修改文件等动作。

• 暂存区

  暂存已经修改的文件最后统一提交到git仓库中（即给自己留个回旋的余地，方便撤销等操作）。我们使用git add就是添加修改到暂存区。
  git管理的文件的修改，他只会提交暂存区的修改来创建版本

• Git Repository（Git仓库）

  最终确定的文件保存到仓库（工作区中的.git目录，也称为版本库），成为一个新的版本，并且对他人可见

向仓库中添加文件的流程

• git status 查看当前状况
• git add 文件（夹）名 将文件（夹）添加到暂存区，可以跟多个文件，也可以通过git add . 将所有文件添加到暂存区。在我们提交一个版本的描述之前，可以多次将一个版本的更改add到暂存区，然后一次提交，创建一个版本记录
• git commit -m “要提交的描述” 将文件提交到git仓库，一旦我们提交后，再用status查看，就会提示我们这是一个干净的工作区（因为刚刚提交所有修改）
  

git的初始化及仓库创建和操作

Git基础设置

git安装完成后，需要进行一些基本信息设置

1. 设置用户名

git config --global user.name ‘用户名’

2. 设置用户名邮箱

git config --global user.email ‘用户邮箱’

3. 查看设置

git config --list

注意：该设置在github仓库主页显示谁提交了文件

文件的几个状态

使用git status可以查看文件的状态：

1. untracked：表明文件还没有add到暂存区，git没有办法帮助进行管理文件的内容
2. modified：如果文件已经add到了暂存区，但是后来又对文件进行了更改，则用git status查看时，会发现该文件的状态为modified。另：可用git status -s查看哪些文件进行了修改，git diff查看修改的详细信息（-号表示删掉了，+号表示添加了）
3. staged：文件已经add后的状态

初始化一个新的Git仓库

1. 向仓库添加文件夹（在本地创建一个文件夹）

2. 在文件夹内初始化git（创建git仓库），git可以帮助我们管理某一目录下代代码，要让它帮我们进行管理，就需要对其进行初始化

   1. 切换到对应文件夹下
   2. git init，就会在对应目录下生成一个.git的隐藏目录，该目录储存了所有的本地仓库信息

3. 向仓库中添加文件
   即之前所述的几个流程

向仓库添加文件

1. 在本地对文件进行修改

2. 将文件添加到暂存区
   git add 文件名

3. 将文件提交到git仓库
   git commit -m ‘描述’

使用如上两个命令，我们就能够创建一个版本

4. 查看版本的记录，如图
   git log
   
   如果内容过多，可以用 git log --pretty=oneline 来简短的显示

在我们创建一个版本的时候，git究竟做了什么？

• 当我们使用add和commit创建一个版本（记为版本1）的时候，git就相当于记录一个点
• 当我们再次创建一个版本的时候，git就记录我们在上一个版本上做的更改（比如，添加了一行代码），这个记录就是版本2。即：后面的版本依赖于前面的版本，并不是将后面的版本完整的拷贝一份

版本的回退

在git中，记录了一个指针，叫做HEAD，指向了最新的版本，HEAD^指向了它的上一个版本，HEAD^^指向其上上一个版本，依次类推；也可以使用例如HEAD~100表示HEAD的前100个版本

假设我们要回到上一个版本，可以使用命令：git reset --hard HEAD^，此时，HEAD就指向了上一个版本（假设是从版本2回到了版本1）。

但是，git并没有将版本2删除掉，因此，我们还可以使用如下命令回到某个版本（eg：从版本2回到版本1后，又想回到版本2）：git reset --hard 版本号（即上面截图中的版本的序列号，没有必要输入整个版本号，输入前几位即可）

使用：git reflog，可以查看之前操作的记录（包括各个版本的序列号），如图所示：

撤销修改

还没有add到暂存区：当我们对工作区的文件进行了修改，但是还没有add到暂存区，就可以使用：git checkout – 文件名 来丢弃修改

已经add到了暂存区：但是还没有commit，1. 先使用 git reset HEAD 文件名 以取消暂存（status查看时，就从绿色的modi）；2. 使用 git checkout – 文件名 来撤销修改（丢弃工作区的改动）

如果已经commit：就必须进行版本的回退来撤销修改

对比文件的不同

使用命令：git diff

对比工作区和版本库

git diff HEAD – 文件的名字：将工作区的文件与版本库中的最新版本相对比（减号是前面的文件，加号对应的是后面的文件）

• 加号+表示工作区比版本库新增的，减号-表示工作区比版本库删除的。没有加减号的表示没有变动的部分

对比两个版本中文件的不同

git diff HEAD HEAD^ – git.txt：对比最新版本和上个版本中git.txt的不同，示例图如下：

此时，减号对应的是最新版，加号对应的是上一个版本（加号是后一个文件，减号是前一个文件）

删除仓库文件

1. 删除本地仓库的文件。这个阶段，我们可以直接：git checkout – 文件名 来丢弃本地更改
2. git rm 文件名 将删除这个改动提交到暂存区。这个阶段，我们可以先 git reset HEAD 文件名 以取消暂存。然后再用checkout来撤销本地的更改
3. git commit -m ‘描述’ 将删除这个改动提交到仓库

如果一个文件已经被放到版本库里面，那么我们就不用担心误删，可以通过版本回退以恢复文件

git checkout – 文件名 和 git reset HEAD 文件名

可以这么理解：前者是将暂存区同步到工作区（丢弃工作区的改动），后者是将仓库同步到暂存区；所以可以先用后者再用前者来实现仓库到工作区的同步（丢弃暂存区的改动）

分支

基本概念

分支就相当于流水线，流水线之间是互不干扰的

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

创建与合并分支

git会把我们之前的每次提交串成一条时间线，这条时间线就是一个分支。截止到目前为止只有一条时间线，在git里，这个叫做主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支

介绍

• 一开始的时候，master分支是一条线，git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
  
  每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

• 当我们创建新的分支，例如dev时，git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
  
  git创建一个分支很快，因为除了增加一个dev指针，改变HEAD的指向，工作区的文件都没有任何变化。

• 不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

  

• 假如我们在dev上的工作完成了，就可以把dev合并到master上。git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

  
  git合并分支也很快，就改改指针，工作区内容也不变。

• 合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

  

操作

• 查看当前分支：git branch

• 创建并切换到一个新的分支：git checkout -b dev
  
  星号表示我们当前所在分支

• 分支的切换：git checkout 分支名，即可切换到对应分支

• 分支内容的合并：git merge 要合并的分支 如果能够使用快速合并（直接移动指针）就使用快速合并

• 删除分支：git branch -d 要删除的分支

合并分支的问题

如果我们在一个分支上面有了一些commit，然后又切换到了另外一个分支，也有了一些commit，即：两个分支各自有了自己的工作进度，并对相同文件进行了编辑。此时如果我们再用git merge 分支名进行合并，就会报合并冲突的错误，提示是哪些文件的内容出现了冲突。

此时如果用 git status 查看状态，对冲突的文件，就会有提示：双方修改

然后查看冲突的文件，就能够查看哪些内容是哪个分支所做的更改

此时就需要手动融合

然后提交

此时，各分支就变成了如下所示

用带参数的git log也可以看到分支的合并情况：

然后就可以删除不必要的分支

分支管理策略

通常，合并分支时，如果可能，git会用fast forward模式，但是有些快速合并不能成功而且合并时没有冲突（不同分支没有对相同文件进行更改），这个时候会合并之后并做一次新的提交。

但是提交的时候就会让我们做一个说明的信息：直接在上面的弹窗里面输入。然后control+s 以进行合并

就会提示：xxx ‘recursive’ strategy xxx

此时就已经合并成功

强制禁用快速合并

如果要强制禁用fast forward模式，git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

方法：在合并的时候使用–no-ff参数，如果本次合并要创建一个新的commit，直接加上-m。如图所示
其中，dev是要合并的分支

Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号001的bug的任务时，很自然地，你想创建一个分支bug-001来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：git stash

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支

然后在临时分支上进行bug修复

修复完成后，切换到master分支，并完成合并**（此时，就不能使用快速合并）**，最后删除bug-001分支。

现在bug-001修复完成，是时候接着回到dev分支干活了！

用git stash list命令查看保存的工作现场

然后使用：git stash pop 恢复工作现场

小结：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并（禁止快速合并），最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，恢复工作现场。

---

使用Github

目的

借助github托管项目代码

基本概念

• 仓库（Repository)

仓库的意思，即你的项目，你想在Github上开源一个项目，那就必须要新建一个Repository，如果你开源的项目多了，你就拥有了多个Repository。相当于git中的仓库

• 收藏（Star）

仓库主页star键，意思为收藏项目的人数，在Github上如果你有一个项目获得100个star都算很不容易了

• 复制克隆项目（Fork）

fork：分叉。即，你开源了一个项目，别人想在你这个项目的基础上做些改进，然后适用到自己的项目中，这个时候他就可以Fork一下你的项目（打开项目主页打击右上角的fork键即可），然后他的Github主页上就多了一个项目，只不过这个项目是基于你的项目基础（本质上是在原有项目的基础上新建了一个分支），他就可以随心所欲的去改进，但是丝毫不会影响原有项目的代码与结构。但是会有forked from sb.字样

• 发起请求（Pull Request）

发起请求，这个其实是基于Fork的，还是上面那个例子，如果别人 在你的基础上做了改进，后来觉得改进的很不错，应该要把这些改进让更多的人收益，于是就想把自己的改进合并到原有项目里，这个时候他就可以发起一个Pull Request（简称PR），原有项目创建人，也就是你，就可以收到这个请求，这个时候你会仔细review他的代码，并且测试觉得ok了，就会接受他的PR，这个时候他做的改进原有项目就会拥有了。

• 关注（Watch）

如果你watch了某个项目，那么以后只要这个项目有任何更新，你都会第一时间收到关于这个项目的通知提醒。

• 事务卡片（Issue）

发现代码Bug，但是目前没有成型代码，需要讨论时用；
就是你开源了一个项目，别人发现了你的项目中有bug，或者哪些地方做得不够好，他就可以给你提个Issue，即问题，提的问题多了，也就是Issues，然后看到了这个问题就可以去诸葛修复，修复ok了就可以一个个Close掉。

• Github主页

账号创建成功或点击网址导航栏github图标都可进入github主页，该页左侧主要是显示用户动态以及关注用户或关注仓库的动态；右侧显示所有git库

• 仓库主页

仓库主页主要显示项目的信息，如：项目代码，版本，收藏/关注/fork情况等

• 个人主页

个人信息：头像，个人简介，关注我的人，我关注的人，我关注的git库，我的开源项目，我贡献的开源项目等信息

注册账号

官网：www.github.com

sign in：登录
sign up：注册

主页：
注意：

1. 因为github是在国外服务器，所以访问速度比较慢或者无法访问，需要翻墙（Shadowsocks）
2. 私有仓库只能自己或者指定的朋友才有权限操作，且需要收费
3. 新注册的用户必须验证邮箱后才能创建仓库

创建仓库/创建新项目

• 说明

1. 一个git库（仓库）对应一个开源项目
2. 通过git管理git库

开始新建项目：

点击新建项目后：其中，左下角的add .gitignore表示要忽略的文件，比如我们要使其忽略python的中间文件.pyc，就直接选择python。然后在生成的对应文件中可以自己定义哪些要忽略
点击仓库名会到仓库主页，点击用户名可到用户个人主页

仓库管理

• 新建文件
  仓库主页-》creat new file，进入如下页面：
  左上角：name your file…输入框中输入文件名（需要加后缀）

Edit new file处的输入框中输入文件内容，点击右边的preview可查看你写的东西

在图中的第一个输入框中，写文件说明的标题

第二个输入框中输入对文件的说明：为了方便其他开发者知道本次添加或修改的原因

通过下方的commit new file提交文件，提交后自动跳转到仓库主页

• 编辑文件

对文件的编辑也算一次提交

点击文件名到文件详情页后
点击修改后
对所做修改进行描述

提交修改后，不会默认回到仓库主页，需通过点击左上角的仓库名（或者Code）回到仓库主页

如果是点击了对文件的描述，查看文件的详细信息时
如果点击了仓库主页左上角的Commit，可查看每次所做的修改
即进入如下页面

• 删除文件

点击文件名进入文件详情页，右上角有的常见的删除符号，点击即可删除
ps：删除文件时，也可提交描述

思考被删除文件如何查看信息：
1. 点击commit，进入每次修改的记录页面
2. 点击对应删除文件的项，即可查看被删除文件的详细信息

• 上传文件

在仓库主页点击上传文件按钮

• 搜索仓库文件

仓库主页点击find file
然后在输入文件名称进行筛选
多学一招：也快通过快捷键t/T迅速进入搜索页面

• 下载/检出项目

ps：如果是通过git下载的话，就需要用到输入框中的链接

Github Issues

作用：发现代码bug，但是目前没有成型代码，需要讨论时使用；或者使用开源项目出现问题时使用

如何创建？

一个用户访问另一个用户的仓库主页时

ps：提交issue时可采用Markdown格式

提交后，仓库所有者就会在自己主页的左侧（显示动态）处看到相关信息（提交者、issue的标题）等。也可以在仓库的issues处查看，并予以回复。一般是在解决后再回复，如果解决了，则可以close issue

ps：关闭该issue的权限提交者和仓库所有者都拥有

关闭issue后
## Github实战操作

• github主页
  - 仓库主页

略

• 个人主页

- 仓库

略

• 收藏

作用：便于下次查找

打开对应项目主页，点击右上凋star按钮即可收藏
查看自己的收藏

- 关注（Watch）

情景：张三关注了李四的项目，李四添加项目文件，张三可以在Github主页收到相关信息

- 复制克隆项目（Fork）

- 发起请求（Pull Request）

情景：张三修改了fork的项目中的文件，希望更新到原来的仓库中（原仓库所有者的仓库中），所以需要发起请求（Pull Request）

发起请求
点击Pull Request之后，进入详情页，可查看具体做了哪些修改，然后Creat pull request
对pull request进行描述
收到请求的一方可以在自己的github主页收到相关信息
收到请求的一方查看请求后，可点击 Merge pull request 将更新的文件合并到原仓库（即自己所有的仓库）
确定合并
- 开源项目的贡献流程

1. 通过新建issue的方式

提交使用问题或者建议或者想法

2. pull request
   1. fork项目
   2. 修改自己仓库的项目代码
   3. 发起pull request
   4. 等待原开发者操作审核

Github Pages搭建网站

个人站点

• 访问

https://用户名.github.io

• 搭建步骤

1. 创建个人站点：新建仓库（注：仓库名必须是【用户名.github.io】
2. 在仓库下新建index.html的文件作为网站首页
   注意点：github pages仅支持静态网页，且仓库里面只能是.html文件

项目站点

即每个仓库创建一个站点

访问：https://用户名.github.io/仓库名

• 搭建步骤

  略

---

Git的远程操作

使用远程仓库的目的：备份，实现代码共享集中化管理

将本地仓库同步到git远程仓库中

在本地操作的基础上 ，git push

• Git克隆操作

  目的：将远程仓库（github对应的项目）复制到本地

  代码：git clone 仓库地址
  ps：仓库地址由来如下图，其格式为：https://github.com/用户名/仓库名.git
  
  在本地对项目做了更改后，再直接git push就可以将本地的更改同步到github

• 推送分支

  就是把某分支上的所有本地提交推送到远程库，推送时要指定本地分支：git push origin 本地分支；如果远程没有与本地分支名相同的分支，就会在远程建立一个与本地分支名相同的分支。

  为此，我们需要使用ssh-key

• ssh-key的使用

  产生ssh秘钥的方法：在git的bash中：ssh-keygen -t rsa –C “你注册github时的邮箱地址”

  然后它会提示你rsa key的保存地方，直接回车就行

  然后还让你输入密码，你想输也行，不想输就一路回车，最后有个public key的要注意，这个待会儿会用到。

  然后下面设置的是git的账户信息

  git config --global user.name “username”

  git config --global user.email “email”
  
  然后在github的settings中配置ssh-key
  

关联到远程仓库：git remote add origin 你远程仓库的地址

注意：这里的origin就相当于你远程仓库在本地的名字

上传到远程仓库：git push -u origin master

master就是你要push的分支，第一次要-u，后面就不需要了

跟踪同步

示例：让本地的master分支跟踪远程的master分支

git branch --set-upstream-to=origin/master master

从远程分支上拉取代码

git pull origin 分支名称

如果git pull 失败 ,提示：fatal: refusing to merge unrelated histories

其实这个问题是因为 两个根本不相干的 git 库， 一个是本地库， 一个是远端库， 然后本地要去推送到远端， 远端觉得这个本地库跟自己不相干， 所以告知无法合并

• 一个种方法： 是 从远端库拉下来代码 ， 本地要加入的代码放到远端库下载到本地的库， 然后提交上去 ， 因为这样的话， 你基于的库就是远端的库， 这是一次update了

• 第二种方法：
  使用这个强制的方法

  git pull origin master --allow-unrelated-histories

  后面加上 --allow-unrelated-histories ， 把两段不相干的 分支进行强行合并

后面再push就可以了

工作中使用git

• 项目经理：

  (1) 项目经理搭建项目的框架。
  (2) 搭建完项目框架之后，项目经理把项目框架代码放到服务器。

• 普通员工：
  (1) 在自己的电脑上，生成ssh公钥，然后把公钥给项目经理，项目经理把它添加的服务器上面。
  (2) 项目经理会给每个组员的项目代码的地址，组员把代码下载到自己的电脑上。
  (3) 创建本地的分支dev,在dev分支中进行每天的开发。
  (4) 每一个员工开发完自己的代码之后，都需要将代码发布远程的dev分支上。并不是每天都push，需要项目经历视开发进度来控制

Master：用户保存发布的项目代码。V1.0,V2.0
Dev：保存开发过程中的代码。