Git和Github的应用与命令方法总结

---

title: Git和Github的应用与命令方法总结

date: 2016-07-11 14:03:09

tags: git/github

[本文摘抄自微信公众平台：AndroidDeveloper(公众号：googdev)，转载请联系原作者！]

1.什么是 GitHub

GitHub 是一家公司，位于旧金山，由 Chris Wanstrath, PJ Hyett 与 Tom Preston-Werner 三位开发者在2008年4月创办。这是它的 Logo：

2008年4月10日，GitHub正式成立，地址：https://github.com/ ，主要提供基于git的版本托管服务。一经上线，它的发展速度惊为天人，截止目前，GitHub 已经发展成全球最大的开源社区。

2.GitHub 与 Git 的关系

Git 是一款免费、开源的分布式版本控制系统，他是著名的 Linux 发明者 Linus Torvalds 开发的。说到版本控制系统，估计很多人都用过 SVN ，只不过 Git 是新时代的产物，如果你还在用 SVN 来管理你的代码，那就真的有些落伍了。

Github,主要提供基于 git 的版本托管服务。也就是说现在 GitHub 上托管的所有项目代码都是基于 Git 来进行版本控制的，所以 Git 只是 GitHub 上用来管理项目的一个工具而已，GitHub 的功能可远不止于此！

3.GitHub 有什么用

• 学习优秀的开源项目
• 多人协作
• 搭建博客、个人网站或者公司官网
• 写作(推荐MarkDown)
• 个人简历
• 其他

4.加入 Github

---

4.1 注册 GitHub

GitHub 官网「https://github.com」注册「Sign Up」个账号,需要填用户名、邮箱、密码。

4.2 设置你的 GitHub

如果你是新注册的 GitHub 账号，是不是觉得很简陋？虽然你没有自己的项目，但是第一步起码要先完善自己的信息，点击如下的 Settings 菜单。

---

5.GitHub 基本概念

• Repository
  
  仓库的意思，即你的项目，你想在 GitHub 上开源一个项目，那就必须要新建一个 Repository ，如果你开源的项目多了，你就拥有了多个 Repositories 。

• Issue
  
  问题的意思，举个例子，就是你开源了一个项目，别人发现你的项目中有bug，或者哪些地方做的不够好，他就可以给你提个 Issue ，即问题，提的问题多了，也就是 Issues ，然后你看到了这些问题就可以去逐个修复，修复ok了就可以一个个的 Close 掉。

• Star
  
  这个好理解，就是给项目点赞，但是在 GitHub 上的点赞远比微博、知乎点赞难的多，如果你有一个项目获得100个star都算很不容易了！

• Fork
  
  这个不好翻译，如果实在要翻译我把他翻译成分叉，什么意思呢？你开源了一个项目，别人想在你这个项目的基础上做些改进，然后应用到自己的项目中，这个时候他就可以 Fork 你的项目，这个时候他的 GitHub 主页上就多了一个项目，只不过这个项目是基于你的项目基础（本质上是在原有项目的基础上新建了一个分支，分支的概念后面会在讲解Git的时候说到），他就可以随心所欲的去改进，但是丝毫不会影响原有项目的代码与结构。

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

• Watch
  
  这个也好理解就是观察，如果你 Watch 了某个项目，那么以后只要这个项目有任何更新，你都会第一时间收到关于这个项目的通知提醒。

• Gist
  
  有些时候你没有项目可以开源，只是单纯的想分享一些代码片段，那这个时候 Gist 就派上用场了！

6.创建自己的项目

点击顶部导航栏的 + 可以快速创建一个项目，如下图：

创建一个项目需要填写如上的几部分：项目名、项目描述与简单的介绍，你不付费没法选择私有的，所以接着只能选择 public 的，之后勾选「Initialize this repository with a README」，这样你就拥有了你的第一个 GitHub 项目。可以看到这个项目只包含了一个 README.md 文件，但是它已经是一个完整的 Git 仓库了，你可以通过对它进行一些操作，如watch、star、fork，还可以 clone 或者下载下来。

7.开始你的Git

• 什么是Git？
  
  Git 是 Linux 发明者 Linus 开发的一款新时代的版本控制系统，那什么是版本控制系统呢？怎么理解？下面我只举几个例子来帮助理解。

1. 开发者与源代码：为了防止代码的丢失，肯定本地机器与远程服务器都要存放一份，而且还需要有一套机制让本地可以跟远程同步。
2. 团队合作协同开发：我们经常是好几个人做同一个项目，都要对一份代码做更改，这个时候需要大家互不影响，又需要各自可以同步别人的代码。
3. 程序Bug的修复与程序复原：我们开发的时候免不了有bug，有时候刚发布的功能就出现了严重的bug，这个时候需要紧急对代码进行还原。
4. 版本的迭代：我们版本迭代的功能越来越多，但是我们需要清楚的知道历史每一个版本的代码更改记录，甚至知道每个人历史提交代码的情况。

这些都是版本控制系统能解决的问题。所以说，版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统，对于软件开发领域来说版本控制是最重要的一环，而 Git 毫无疑问是当下最流行、最好用的版本控制系统。

• Git 安装

1.Mac：https://sourceforge.net/projects/git-osx-installer/

2.Windows：https://git-for-windows.github.io/

3.Linux：apt-get install git

• Git 命令列表
  
  在命令行里输入 git ，如果出现以下提示证明你已经安装成功了。

Git 所有的操作命令开头都要以 git 开头，上面列举了最常用的一些 Git 命令，紧接着会有一句英文解释这个命令的意义，都不是很难的单词，不妨试着看一下，不过没有实际操作你仍然不好理解，下面我们来以一个实际的操作来介绍下一些常用命令的含义。

• Git 具体命令
  
  第一步，我们先新建一个文件夹，在文件夹里新建一个文件。

  mkdir test （创建文件夹test）
  
  cd test （切换到test目录）
  
  touch a.md （新建a.md文件）

在进行任何 Git 操作之前，都要先切换到 Git 仓库目录，也就是先要先切换到项目的文件夹目录下。Windows可进入到该文件夹的目录下，右键 Git Bash Here，开始git方法操作。

git init   -->  初始化 git 仓库
git status   -->  查看状态

默认就直接在 master 分支，关于分支的概念后面会提，这时最主要的是提示 justtest.md 文件 Untracked files ，就是说 justtest.md 这个文件还没有被跟踪，还没有提交在 git 仓库里呢，而且提示你可以使用 git add 去操作你想要提交的文件。

git status 这个命令顾名思义就是查看状态，这个命令可以算是使用最频繁的一个命令了，建议大家没事就输入下这个命令，来查看你当前 git 仓库的一些状态。

此时提示以下文件 Changes to be committed ， 意思就是 justtest.md 文件等待被提交，当然你可以使用 git rm --cached 这个命令去移除这个缓存。

git commit   -->  提交

输入 git commit -m 'first commit

-m 代表是提交的注释信息，执行了以上命令代表我们已经正式进行了第一次提交。

git log   -->  查看所有产生的 commit 记录

• git add & git commit解析

可能有人有疑问，要提交直接进行 commit 不就行了么，为什么先要再 add 一次呢？首先 git add 是先把改动添加到一个「暂存区」，你可以理解成是一个缓存区域，临时保存你的改动，而 git commit 才是最后真正的提交。这样做的好处就是防止误提交，当然也有办法把这两步合并成一步，不过后面再介绍，建议新手先按部就班的一步步来。

git branch   -->  分支

branch 即分支的意思，分支的概念很重要，尤其是团队协作的时候，假设两个人都在做同一个项目，这个时候分支就是保证两人能协同合作的最大利器了。举个例子，A, B俩人都在做同一个项目，但是不同的模块，这个时候A新建了一个分支叫a， B新建了一个分支叫b，这样A、B做的所有代码改动都各自在各自的分支，互不影响，等到俩人都把各自的模块都做完了，最后再统一把分支合并起来。

执行 git init 初始化git仓库之后会默认生成一个主分支 master ，也是你所在的默认分支，也基本是实际开发正式环境下的分支，一般情况下 master 分支不会轻易直接在上面操作的，你们可以输入 git branch 查看下当前分支情况。

如果我们想在此基础上新建一个分支呢，很简单，执行 git branch issues1 就新建了一个名字叫 issues1 的分支，这时候分支 issues1 跟分支 master 是一模一样的内容，我们再输入 git branch 查看的当前分支情况。

但是可以看到 master 分支前有个 * 号，即虽然新建了一个 a 的分支，但是当前所在的分支还是在 master 上，如果我们想在 a 分支上进行开发，首先要先切换到 a 分支上才行，所以下一步要切换分支。

git checkout issues1   -->  切换到分支 issues1

可以看到当前我们在的分支已经是issues1了，这个时候 A 同学就可以尽情的在他新建的issues1分支去进行代码改动了。

git checkout -b issues1   -->  新建一个issues1分支，并且自动切换到issues1分支

避免麻烦，一步到位的方法：git checkout -b issues1

git merge   -->  合并分支

A同学在issues1分支代码写的不亦乐乎，终于他的功能完工了，并且测试也都ok了，准备要上线了，这个时候就需要把他的代码合并到主分支master上来，然后发布。git merge 就是合并分支用到的命令，针对这个情况，需要先做两步，第一步是切换到 master 分支，如果你已经在了就不用切换了，第二步执行 git merge issues1 ，意思就是把a分支的代码合并过来，不出意外，这个时候 issues1 分支的代码就顺利合并到 master 分支来了。

git branch -d   -->  删除分支

有新建分支，那肯定有删除分支，假如这个分支新建错了，或者 issues1 分支的代码已经顺利合并到 master 分支来了，那么 issues1 分支没用了，需要删除，这个时候执行 git branch -d issues1 就可以把 issues1 分支删除了。

git branch -D   -->  强制删除

有些时候可能会删除失败，比如如果 issues1 分支的代码还没有合并到master，你执行 git branch -d issues1 是删除不了的，它会智能的提示你 issues1 分支还有未合并的代码，但是如果你非要删除，那就执行 git branch -D issues1 就可以强制删除 issues1 分支。

git tag   -->  强制删除

我们在客户端开发的时候经常有版本的概念，比如v1.0、v1.1之类的，不同的版本肯定对应不同的代码，所以我一般要给我们的代码加上标签，这样假设v1.1版本出了一个新bug，但是又不晓得v1.0是不是有这个bug，有了标签就可以顺利切换到v1.0的代码，重新打个包测试了。

所以如果想要新建一个标签很简单，比如 git tag v1.0 就代表我在当前代码状态下新建了一个v1.0的标签，输入 git tag 可以查看历史 tag 记录。

如果我们有多个tag，想要切换他给怎么办？

执行 git checkout v1.0 ，这样就顺利的切换到 v1.0 tag的代码状态了。

8.用Git向Github提交代码

• 1. SSH
     
     SSH是一种网络协议，用于计算机之间的加密登录。目前是每一台 Linux 电脑的标准配置。而大多数 Git 服务器都会选择使用 SSH 公钥来进行授权，所以想要在 GitHub 提交代码的第一步就是要先添加 SSH key 配置。
• 1. 生成SSH key
     
     Linux 与 Mac 都是默认安装了 SSH ，而 Windows 系统安装了 Git Bash 也是带了 SSH 的。大家可以在终端（win下在 Git Bash 里）输入 ssh 如果出现以下提示证明你本机已经安装 SSH 。

紧接着输入 ssh-keygen -t rsa ，什么意思呢？就是指定 rsa 算法生成密钥，接着连续三个回车键（不需要输入密码），然后就会生成两个文件 id_rsa 和 id_rsa.pub ，而 id_rsa 是密钥，id_rsa.pub 就是公钥。这两文件默认分别在如下目录里生成：

Linux/Mac 系统 在 ~/.ssh 下，win系统在 /c/Documents and Settings/username/.ssh 下，都是隐藏文件。

接下来要做的是把 id_rsa.pub 的内容添加到 GitHub 上，这样你本地的 id_rsa 密钥跟 GitHub 上的 id_rsa.pub 公钥进行配对，授权成功才可以提交代码。

• 1. Github上添加 SSH key

• 1. Push & Pull

Push ：直译过来就是「推」的意思，什么意思呢？如果你本地代码有更新了，那么就需要把本地代码推到远程仓库，这样本地仓库跟远程仓库就可以保持同步了。

git push origin master   -->  把本地代码推到远程 master 分支

Pull：直译过来就是「拉」的意思，如果别人提交代码到远程仓库，这个时候你需要把远程仓库的最新代码拉下来，然后保证两端代码的同步。

git pull origin master   -->  把远程最新的代码更新到本地

一般我们在 push 之前都会先 pull ，这样不容易冲突。

• 1. 提交代码

添加 SSH key 成功之后，我们就有权限向 GitHub 上我们自己的项目提交代码了，而提交代码有两种方法：

1. Clone自己的项目

1. 提交自己的代码

提交完成之后查看自己的Github是否发生改变

• 1. 关联本地已有项目

假设我们本地有个 test2 的项目，我们需要的是在 GitHub 上建一个 test 的项目，然后把本地 test2 上的所有代码 commit 记录提交到 GitHub 上的 test 项目。

第一步就是在 GitHub 上建一个 test 项目，这个想必大家都会了，就不用多讲了。

第二步把本地 test2 项目与 GitHub 上的 test 项目进行关联，切换到 test2 目录，执行如下命令：

git remote add origin git@github.com:hankinspan/Dev_PanASDemo .git
-->  添加一个远程仓库，他的地址是 git@github.com:hankinspan/Dev_PanASDemo.git

查看我们当前项目有哪些远程仓库可以执行如下命令：

git remote -v   -->  查看当前项目

9.Git进阶

此时此刻，相信你已经会了git的基本用法，为了提高工作效率，加快开发速度，这里来优化你对Git的使用。

• 1. alias

我们知道我们执行的一些 Git 命令其实操作很频繁的类似有：

git commit
git checkout
git branch
git status
...

这些操作非常频繁，每次都要输入完全是不是有点麻烦，有没有一种简单的缩写输入呢？比如我想直接输入以下命令代替：

git c
git co
git br
git s
...

是不是很简单快捷啊？这个时候就用到了 alias 了，翻译过来就是别名的意思，输入以下命令就可以直接满足以上的需求。

git config --global alias.co checkout  # 别名
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch

当然以上别名不是固定的，你完全可以根据自己的习惯去定制，除此之外还可以设置组合，比如：

git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'

之后经常用到的 git push origin master 和 git pull origin master 直接就用 git psm 和 git plm 代替了，是不是很方便？

【 -- 这里插播一个个人认为特别炫的 git log方法，可以去试试 -- 】

git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"

这样以后直接输入 git lg 就行了。

• 1. 其他配置

当然还有一些其他有用的配置，默认情况下 git 用的编辑器是 vi ，如果不喜欢可以改成其他编辑器，比如我习惯 vim 。

git config --global core.editor "vim"  # 设置Editor使用vim

你们如果喜欢其他编辑器可自行搜索配置，前提是本机有安装。

有些人纳闷我的终端怎么有各种颜色显示，自己却不是这样的，那是因为你们没有开启给 Git 输出着色，输入如下命令即可：

git config --global color.ui true

还有些其他的配置如：

git config --global core.quotepath false # 设置显示中文文件名

以上的配置基本就差不多了，默认这些配置都在 ~/.gitconfig 文件下的，你可以找到这个文件查看自己的配置，也可以输入 git config -l 命令查看。

• 1. diff

diff 命令算是很常用的，使用场景是我们经常在做代码改动，但是有的时候2天前的代码了，做了哪些改动都忘记了，在提交之前需要确认下，这个时候就可以用diff来查看你到底做了哪些改动。

git diff <$id1> <$id2>   # 比较两次提交之间的差异
git diff <branch1>..<branch2> # 在两个分支之间比较
git diff --staged   # 比较暂存区和版本库差异

• 1. checkout

checkout 一般用作切换分支使用，比如切换到 develop 分支，可以执行：

git checkout develop

但是 checkout 不只用作切换分支，他可以用来切换 tag，切换到某次 commit，如：

git checkout v1.0
git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7

后面的一长串是commit_id，是每次commit的SHA1值，可以根据 git log 看到。

除了有“切换”的意思，checkout 还有一个撤销的作用，举个例子，假设我们在一个分支开发一个小功能，刚写完一半，这时候需求变了，而且是大变化，之前写的代码完全用不了了，好在你刚写，甚至都没有 git add 进暂存区，这个时候很简单的一个操作就直接把原文件还原：

git checkout a.md

checkout 命令只能撤销还没有 add 进暂存区的文件。

10.团队合作利器 Branch

Git 相比于 SVN 最强大的一个地方就在于「分支」，Git 的分支操作简直不要太方便，而实际项目开发中团队合作最依赖的莫过于分支了。

• 1. 分支的常用操作

通常我们默认都会有一个主分支叫 master ，下面我们先来看下关于分支的一些基本操作：

新建一个叫 develop 的分支

git branch develop

这里稍微提醒下大家，新建分支的命令是基于当前所在分支的基础上进行的，即以上是基于 mater 分支新建了一个叫做 develop 的分支，此时 develop 分支跟 master 分支的内容完全一样。如果你有 A、B、C三个分支，三个分支是三位同学的，各分支内容不一样，如果你当前是在 B 分支，如果执行新建分支命令，则新建的分支内容跟 B 分支是一样的，同理如果当前所在是 C 分支，那就是基于 C 分支基础上新建的分支。

切换到 develop 分支

git checkout develop

如果把以上两步合并，即新建并且自动切换到 develop 分支：

git checkout -b develop

把 develop 分支推送到远程仓库

git push origin develop

查看本地分支列表

git branch

查看远程分支列表

git branch -r

删除本地分支

git branch -d develop    

git branch -D develop (强制删除)

删除远程分支

git push origin :develop

如果远程分支有个 develop ，而本地没有，你想把远程的 develop 分支迁到本地：

git checkout develop origin/develop

同样的把远程分支迁到本地顺便切换到该分支：

git checkout -b develop origin/develop

• 1. 基本的团队协作流程

一般来说，如果你是一个人开发，可能只需要 master、develop 两个分支就 ok 了，平时开发在 develop 分支进行，开发完成之后，发布之前合并到 master 分支，这个流程没啥大问题。

如果你是 3、5 个人，那就不一样了，有人说也没多大问题啊，直接可以新建 A、B、C 三个人的分支啊，每人各自开发各自的分支，然后开发完成之后再逐步合并到 master 分支。然而现实却是，你正在某个分支开发某个功能呢，这时候突然发现线上有一个很严重的 bug ，不得不停下手头的工作优先处理 bug ，而且很多时候多人协作下如果没有一个规范，很容易产生问题，所以多人协作下的分支管理规范很重要，就跟代码规范一样重要，以下就跟大家推荐一种我们内部在使用的一种分支管理流程 Git Flow。

• 1. Git Flow

准确的说 Git Flow 是一种比较成熟的分支管理流程，我们先看一张图能清晰的描述他整个的工作流程：

一般开发来说，大部分情况下都会拥有两个分支 master 和 develop，他们的职责分别是：

1. master：永远处在即将发布(production-ready)状态
2. develop：最新的开发状态

确切的说 master、develop 分支大部分情况下都会保持一致，只有在上线前的测试阶段 develop 比 master 的代码要多，一旦测试没问题，准备发布了，这时候会将 develop 合并到 master 上。

但是我们发布之后又会进行下一版本的功能开发，开发中间可能又会遇到需要紧急修复 bug ，一个功能开发完成之后突然需求变动了等情况，所以 Git Flow 除了以上 master 和 develop 两个主要分支以外，还提出了以下三个辅助分支：

• feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop

• release: 准备要发布版本的分支, 用来修复 bug，基于 develop，完成后 merge 回 develop 和 master

• hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop

什么意思呢？

举个例子，假设我们已经有 master 和 develop 两个分支了，这个时候我们准备做一个功能 A，第一步我们要做的，就是基于 develop 分支新建个分支：

git branch feature/A

看到了吧，其实就是一个规范，规定了所有开发的功能分支都以 feature 为前缀。

但是这个时候做着做着发现线上有一个紧急的 bug 需要修复，那赶紧停下手头的工作，立刻切换到 master 分支，然后再此基础上新建一个分支：

git branch hotfix/B

代表新建了一个紧急修复分支，修复完成之后直接合并到 develop 和 master ，然后发布。

然后再切回我们的 feature/A 分支继续着我们的开发，如果开发完了，那么合并回 develop 分支，然后在 develop 分支属于测试环境，跟后端对接并且测试的差不多了，感觉可以发布到正式环境了，这个时候再新建一个 release 分支：

git branch release/1.0

这个时候所有的 api、数据等都是正式环境，然后在这个分支上进行最后的测试，发现 bug 直接进行修改，直到测试 ok 达到了发布的标准，最后把该分支合并到 develop 和 master 然后进行发布。

以上就是 Git Flow 的概念与大概流程，看起来很复杂，但是对于人数比较多的团队协作现实开发中确实会遇到这么复杂的情况，是目前很流行的一套分支管理流程。

GitFlow开源地址：https://github.com/nvie/gitflow

简单点来说，就是这个工具帮我们省下了很多步骤，比如我们当前处于 master 分支，如果想要开发一个新的功能，第一步切换到 develop 分支，第二步新建一个以 feature 开头的分支名，有了 Git Flow 直接如下操作完成了：

git flow feature start A

这个分支完成之后，需要合并到 develop 分支，然而直接进行如下操作就行：

git flow feature finish A

如果是 hotfix 或者 release 分支甚至会自动帮你合并到 develop、master 两个分支。

GitFolw作者还提供了 git-flow 命令工具:

git flow init

接着它会问你一系列的问题，蛋定！尽量使用它的默认值就好了：

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

完成后当前所在分支就变成 develop. 任何开发都必须从 develop 开始:

git flow feature start some_awesome_feature

完成功能开发之后:

git flow feature finish some_awesome_feature

该命令将会把feature/some_awesome_feature合并到develope分支，然后删除功能(feature)分支。

将一个 feature 分支推到远程服务器:

git flow feature publish some_awesome_feature
或者
git push origin feature/some_awesome_feature

当你的功能点都完成时（需要发布新版本了），就基于develop创建一个发布(release)分支，然后升级版本号并在最后发布日期前把Bug Fix掉吧：

 git flow release start v0.1.0

当你在完成（finish)一个发布分支时，它会把你所作的修改合并到master分支，同时合并回develop分支，所以，你不需要担心你的master分支比develop分支更加超前。

最后一件让git-flow显得威武的事情是它处理热修复（即时的BugFix）的能力，你可以像其他分支一样地创建和完成一个热修复分支，区别是它基于master分支，因此你可以在产品出现问题时快速修复，然后通过”finish”命令把修改合并回master和develop分支。

以上就是我做的所有Git和Github的应用与命令方法总结，一个人你也许感受不到什么，但是实际工作中大都以团队协作为主，而分支是团队协作必备技能，而 Git Flow 是我推荐给你们的一个很流行的分支管理流程。

[本文摘抄自微信公众平台：AndroidDeveloper(公众号：googdev)，转载请联系原作者！]