Git快速开发手册

Git

Git 是一个开源免费的分布式版本控制系统。旨在快速高效的处理从小型到大型项目的所有内容。

2005年Git 诞生，它的作者是Linux之父- Linus（林纳斯 · 托瓦兹）。

推荐学习资料：GitBook中文版

使用方式

​ Git有多种使用方式，你可以使用原生的命令行模式（Git Bash），也可以使用GUI模式（Git GUI）。

​ 命令行模式可以使用Git的全部功能，但GUI就未必了，Git GUI也有很多不同的实现，如Git 官方提供的 Git GUI，Tortoise Git，Eclipse提供的 EGit等，界面化的GUI 可以降低Git的操作难度。

​ 本人是 Git Bash 的重度使用者，所以本文基于Git 命令行模式进行讲解。

配置

使用Git前需要做一些必要的配置项。

配置用户名和邮箱

git 配置分为全局配置和局部配置。局部配置文件为 .git/config ( git 库根目录),

可以使用 git config 命令配置git:

第一件事就是配置你的用户名和邮箱地址，这很重要，因为git的每次提交都会使用这些信息。

# 配置用户名和邮箱地址
$ git config --global user.name "mikai"
$ git config --global user.email mikai@example.com

注：配置变量不要写 “=”等号。

查看配置信息：

$ git config --list

配置忽略文件

​ 一般我们会有一些文件不需要纳入 Git 管理，也不希望她们总是出现在未跟踪文件列表。通常都是一些自动生成文件、日志文件或临时文件。

​ 这种情况下，我们可以创建一个名为 .gitignore 的文件 ，列出要忽略的文件格式。

.gitignore 文件：

# 忽略所有的 .a 文件
*.a
# 但跟踪所有的 lib.a，即便你在前面忽略了 .a 文件
!lib.a
# 只忽略当前目录下的 TODO 文件，而不忽略 subdir/TODO
/TODO
# 忽略任何目录下名为 build 的文件夹
build/
# 忽略 doc/notes.txt，但不忽略 doc/server/arch.txt
doc/*.txt
# 忽略 doc/ 目录

注: 忽略文件不仅可以在git 库的根目录配置, 在git 库内的任意目录下都会起效;

# Compiled class file
*.class
# Log file
*.log

bin/
classes/
target/
.gradle/
*.bak
.DS_Store
!/.project
.settings
.project
.classpath

Git基础

总览

四个主要区域

Git分为四个主要区域：

• Workspace：工作区
• Index / Stage：暂存区
• Repository：本地仓库
• Remote：远程仓库

文件四种状态

​ 在你的 Git 工作目录下，文件会是这四种状态中的其中一种：

• 未跟踪（untracked）
• 已暂存（staged）
• 已修改（modified）
• 已提交（committed）

基本工作流程

Git 基本工作流程：

1. 在工作目录中新建的文件并没有被 Git 所管理，处于未跟踪状态；
2. 使用 git add 将文件加入到暂存区，此时文件处于已暂存状态，并且文件被Git所跟踪；
3. 使用 git commit 命令将暂存文件提交到本地仓库，此时文件处于已提交状态；
4. 后期你又对该文件进行修改操作，那么文件处于已修改状态，这时你就可以再次将修改的文件重新加入暂存区并提交。
5. 如果你想把本地文件分享给团队的其他人，就可以将本地仓库修改的文件推送到远程仓库，其他人从远程仓库拉取到自己的本地。

初始化 / 克隆仓库

有两种获取 Git 项目仓库的方式：

初始化本地git仓库：

$ git init
Initialized empty Git repository in E:/code/mikai/.git/

git仓库初始化完成后，就会在相应的位置，产生一个 .git 目录（隐藏文件）。

克隆远程git仓库

如果远程服务器上有git仓库，可以直接克隆到本地：

# 克隆远程git仓库
$ git clone https://github.com/Jackpot/mikai.git
# 克隆远程git仓库的指定分支
$ git clone -b feature/iot https://github.com/Jackpot/mikai.git
# 克隆远程git仓库的指定分支，重命名文件夹（避免重名）
$ git clone -b feature/iot https://github.com/Jackpot/mikai.git iot_backend_bee

通过克隆得到的git仓库，会自动新建一个名称为 origin 的远程仓库，origin 的地址就是远程仓库的地址。

查看状态

​ git status 应该是开发中使用最频繁的一个命令了，在任何时候，你都可以查看 git 状态，而且强烈推荐你频繁使用，做什么操作前查看一下状态是一个好习惯。

​ git status 除了告诉你当前仓库的状态，还会顺便提示你当前状态你可能会使用什么命令，非常方便智能。

# 查看状态
git status

加入暂存区

加入暂存区就表明该文件已经被Git跟踪，跟踪后，文件的所有修改内容对于Git来说都是可感知的。

# 将指定文件加入暂存区
$ git add <file> 
# 将所有文件加入暂存区
$ git add * 

注:

​ 将未追踪的文件加入到暂存区，Git自动将该文件纳入追踪列表。

​ 未跟踪和未暂存不相等，新建的文件处于未跟踪状态，当文件加入暂存区并且再次修改后，新修改的内容属于未暂存，但是该文件已被追踪。跟踪的对象是文件，而暂存的对象是文件内容。未跟踪的文件一定未暂存，但未暂存修改内容的文件可能已被跟踪。

查看差异

git diff 可以查看已被追踪文件的修改差异情况：

# 查看未暂存的文件修改内容
$ git diff 
# 查看已暂存的文件修改内容
$ git diff --staged

效果:

$ git diff
diff --git a/mikai.java b/mikai.java
index 1a2a479..6d576e8 100644
--- a/mikai.java
+++ b/mikai.java
@@ -1,6 +1,7 @@

        public static boolean booInclueStockBill(Context context, GUID entryId){
-               RecordSet rs = findStockOutBill(context, entryId, true);
+               int i = 0;
+               RecordSet rs = findStockOutBill(context, entryId, false);
                if(rs.next()){
                        return false;
                }

注：

​ 减号 - 代表删除，加号 + 代表增加。

​ 只能查看已跟踪但未暂存和已暂存文件的修改差异信息，未跟踪和已提交的文件是看不到差异变化的。

difftool 工具

除了使用 git diff ，还可以使用 git difftool 可视化工具来对比查看文件差异情况：

提交修改

文件修改内容加入到暂存区后，就可以提交到本地仓库了：

# 提交到本地仓库
$ git commit -m 'commit message;' 
# 提交到本地仓库
$ git commit -a -m 'commit message;' 

注:

​ git commit 加入 -a 选项，表示git 会把已经跟踪过的文件自动暂存起来一并提交，从而跳过 git add 步骤。但 -a 选项对未跟踪的文件是无效的，依然需要手动加入暂存区。

远程仓库

基本操作

# 查看远程仓库
git remote -v
# 添加远程仓库
git remote add mikai https://github.com/jackpot/mikai.git
# 重命名远程仓库
git remote rename mikai haya
# 删除远程仓库
git remote remove mikai

注：使用 git remote 命令可以轻松更换 git 远程仓库的地址。

拉取

​ git fetch 命令从远程服务上拉取最新数据到本地，它并不会修改工作目录的内容。它只会获取数据然后让你自己合并。

git pull 会查找当前分支所跟踪的远程分支，从远程分支上抓取数据然后合并到当前本地分支；当然也可以指定远程分支拉取合并到本地分支： git pull origin develop ，

# 拉取远程分支数据（不会影响本地分支）
git fetch
# 拉取远程分支代码并合并到本地当前分支
git pull origin develop

推送

git push 命令用于将当前分支推送到远程指定分支:

# 将当前分支推送到远程指定分支
git push origin develop
# 推送本地的feature-branch(冒号前面的)分支到远程origin的feature-branch(冒号后面的)分支(没有会自动创建)
git push origin feature-branch:feature-branch    

撤销

撤销未存的修改

# 撤销指定文件
$  git checkout <file> 
# 撤销所有已修改的文件
$  git checkout .

注意：

​ git checkout file 是个危险的命令! 因为修改的内容没有加到暂存区，所以撤销后，之前的信息可能就再也找不回来了。

撤销已暂存的修改

如果已经使用 git add 将修改的文件加入暂存区，

# 撤销指定已暂存的文件
git reset HEAD <file>
# 撤销所有已暂存的文件
git reset HEAD .

回退历史 reset

​ 使用 git reset 可以在Git的历史版本之间任意穿梭。

​ 在Git中，HEAD指针指向当前分支的最新一次提交，上一个版本就是HEAD^ ,上上个版本就是HEAD^^，往上100个版本可以写成HEAD~100；

# 回退到指定的历史提交版本
git reset --hard 79f673d6
# 回退到上一个提交版本
git reset --hard HEAD^

• 回退版本之前，可以使用 git log 查看提交历史；
• 回退版本之后，如果想回到未来版本，可以使用 git reflog 命令查看所有提交历史；

注:

​ git reset 加 --hard 选项代表版本硬回退，即不仅git版本进行回退，本地文件的内容也回退；与之对应的是 --soft 选项，代表软回退，即git版本进行回退，但本地文件还存在，这算是一种保守的做法。

看下面一个例子：

如果不小心把topic 分支的内容合并到master分支上，想退回怎么办？

使用 git reset HEAD^ 修改HEAD指针的引用，就回退到了指定版本：

注：

​ git reset 这种方法相当于修改 HEAD 指针的引用，缺点是它会重写历史，这在一个共享的仓库中可能会造成问题。如果你想回退到某个历史版本，并且该版本之后的提交你都不要了，那么可以使用 git reset ，否则不要使用该方法。

还原提交 revert

git reset 回退历史版本会重写历史，使用 git revert 则没有这样的情况。

还是上面那个例子，使用 git revert 可以还原提交版本，并且分支上的HEAD指针是往前推进的：

master 分支的 C6版本和 ^M版本内容是一样的，中间的历史版本没有受到影响。

# 还原到指定提交版本
git revert d4259f880e0

查看提交历史

git log 会按照时间倒序显示所有提交的历史信息

# 查看当前分支的提交信息
git log 
# 查看所有提交信息:包括修改了哪些文件
git log --stat
# 查看最近的10条提交信息
git log -10
# 以差异的方式查看提价信息:显示文件修改的差异细节
git log -p 
# 查看所有分支的提交信息
git log --all

git log 显示的信息有提交ID，作者（用户名、邮箱）、时间、提交信息。

$ git log 

commit a34c3e744aef82078ea32bab80de3f431b153bfb
Author: mikai <mikai@example.com>
Date:   Mon Jun 29 14:03:52 2020 +0800

    费用类型过滤完善;

commit 2f70173c5de37662328715e1e92ca3e70356c2b8
Merge: 6f06e4a 0f6191c
Author: mikai <mikai@example.com>
Date:   Mon Jun 29 12:04:21 2020 +0800

    Merge branch 'develop_haya' of gitlab.beecode.cn:drjs-product/ERP into haya-68

git log –stat 除了显示基本的信息，还会显示提交的文件变动列表。

$ git log --stat

commit a34c3e744aef82078ea32bab80de3f431b153bfb
Author: mikai <mikai@example.com>
Date:   Mon Jun 29 14:03:52 2020 +0800

    费用类型过滤完善;

 .../erp/common/function/FeeTypeFilterFunc.java     | 92 +++++++++++++++-------
 .../erp/common/model/FeeTypeFilterModel.java       | 40 +++++++++-
 .../erp/common/service/FeeTypeFilterService.java   |  8 +-
 .../erp/common/storage/TB_BMS_FEETYPE_FILTER.java  |  2 +
 4 files changed, 109 insertions(+), 33 deletions(-)

gitk 可视化工具

​ 使用 gitk 命令就可以启动 gitk 可视化工具查看提交历史了，非常直观和方便。

临时保存

​ 有时当前的任务项进行到一半，不得不处理其他任务项，这时就需要你把当前分支处理“干净”，然后切换到其他分支上工作。如果你不想提交未完成的任务，那么就可以使用 git stash 提供的临时保存功能。

​ git stash 会将未完成的修改保存到一个栈上，你可以在任何时候重新应用这些改动。（甚至在不同的分支上）

​ git stash 命令用来临时保存还没有完成的工作，以便在分支上不需要提交未完成的工作就可以清理工作目录。

git stash 常用命令:

# 将修改内容临时保存在栈中(入栈)
git stash

# 查看临时保存的记录
git stash list

# 将栈顶存放的临时内容应用到当前分支
git stash apply
# 将指定的临时内容应用到当前分支
git stash apply stash@{2}

# 删除栈顶的临时内容(出栈)
git stash pop
# 删除指定的临时内容
git stash drop stash@{1}

注：

​ 临时保存的修改内容，一定要在短时间内处理，或者还原，或者删除，如果一直遗留不处理，可能会给自己带来“麻烦”。

打标签（版本）

打标签一般用于记录项目版本。

Git 提供两种标签：附注标签和轻量标签。

打标签的常用命令：

# 打附注标签
git tag -a v5.0.1 -m 'tag message'
# 打轻量标签
git tag v5.0.0
# 后期打标签 (需要提交ID)
git tag -a v1.2 9fceb12

# 查看指定标签的详情信息
git show v5.0.1
# 查看所有标签列表
git tag
# 查看指定标签列表：模糊搜索
git tag -l v5.*

# 共享指定标签：推送本地标签信息到远程
git push origin v5.0.1
# 共享所有标签
git push origin --tags

# 删除本地标签
git tag -d v5.0.1
# 删除远程标签
git push origin --delete v5.0.1

# 检出标签(适用于只读)
git checkout v5.0.1
# 检出标签(适用于再次开发或修复)
git checkout -b fix/v5.0.1  v5.0.1

看看开源项目 Spring 的标签是怎么标记的:

$ git tag

v3.0.0.M1
v3.0.0.RC1
v3.0.0.RELEASE
v3.0.1.RELEASE
....
v4.0.0.RELEASE
v5.1.0.RELEASE
v5.1.1.RELEASE
v5.1.2.RELEASE
v5.1.3.RELEASE

​ spring 项目的标签很详细，每个版本都会标记一个相应的标签。由于 spring 项目的维护时间很长，所以已经打了有上百个标签。按照Spring的发布规范，M版本是里程碑版本，RC版本是候选版本，RELEASE 版本是最终稳定版本。

如果你只想关注特定版本的标签，可以使用 * 号模糊搜索：

$ git tag -l v5.*

v5.0.0.M1
v5.0.0.M2
v5.0.0.M3
v5.0.0.RC1
v5.0.0.RELEASE
...

查看标签的详情信息：

$ git show v5.0.0.RELEASE

tag v5.0.0.RELEASE
Tagger: Spring Buildmaster <buildmaster@springframework.org>
Date:   Thu Sep 28 11:28:23 2017 +0000

Release version 5.0.0.RELEASE
commit f4f990b2c900a9b325fd0770d9064a188d073253
Author: Spring Buildmaster <buildmaster@springframework.org>
Date:   Thu Sep 28 11:28:21 2017 +0000

    Release version 5.0.0.RELEASE

可以看到标签名，打标签的人、时间、附带信息，还有与标签相关联的提交信息。

阅读指定版本的源码

​ 使用 git checkout <tagname> 可以检出指定版本的内容，方便开发人员阅读。对于一些迭代周期很长的开源项目，直接阅读高版本的源码可能门槛很高，这时可以通过检出低版本的源码，降低难度，毕竟学习一个东西，先培养兴趣和成就感还是很重要的。

​ 如果想修改历史版本的源码， git checkout -b <branch> <tagname> 可以在指定版本上创建新分支，从而进行完善和修复工作。

打补丁

Git 提供两种补丁方案, 一是使用 git format-patch 生成 git 专用的 .patch 文件; 二是用 git diff 生成 UNIX 标准补丁 .diff 文件;

patch 方式打补丁

语法:

# 打补丁:从指定 [commit id] 起的 n 次提交
git format-patch [commit id] -n
# 打补丁:两次 [commit id] 之间的所有提交
git format-patch [commit id]...[commit id]

示例:

# 一次提交的内容打补丁
git format-patch ba0e1183684c02912b2a1911bbc4e5a7c9ba1e48 -1
# 对两次提交ID之间的所有提交内容打补丁
git format-patch ba0e1183684c02912b2a1911bbc4e5a7c9ba1e48...58ca924607d25c28b94154c61be1124e408dc702

​ 执行命令后，git 会在当前目录生成 .patch 补丁，这是个文本文件，可以打开查看；patch 文件中除了包含基本的补丁内容，还包含邮件所需要的ID、,时间、发送人、主题描述等，非常标准，可以直接通过 git send-email 发送邮件给其他人。

diff 方式打补丁

语法:

git diff [commit id] [commit id] >  [diff文件名]

示例:

# diff 方式打补丁
git diff 58ca924607d25c28b94154c61be1124e408dc702 ba0e1183684c02912b2a1911bbc4e5a7c9ba1e48 > demo.diff

说明:

​ 如果有可能,鼓励使用 git format-patch 而不是 git diff 来生成补丁;

应用补丁

使用 git am 或 git apply 命令应用补丁文件

am (apply mailbox 之意, 设计之初是为了应用通过邮件传来的文本补丁内容)

应用场景

不同的库之间, 不同的分支之间可以使用补丁的方式修改内容.

# 
git 

git 发送邮件

本地打出的补丁文件,可通过 git send-email 发送邮件给其他人。

cherry-pick

对于多分支的代码库，将代码从一个分支转移到另一个分支是常见需求。

这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并（git merge）。另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 Cherry pick。

git cherry-pick <commitHash>

上面命令就是将指定的提交commitHash，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样。

# 将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。
git cherry-pick <HashA> <HashB>
# 转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败
git cherry-pick A..B 

如果pick 过程中有冲突，手动解决代码冲突后，执行

git cherry-pick --continue

分支

Git的分支操作和管理是Git的杀手锏特性，非常轻量级，使它在众多版本控制系统中脱颖而出，鹤立鸡群。

分支的新建、切换、删除

# 新建分支
git branch iss53	
# 切换分支
git checkout master
# 删除本地分支
git branch -d iss53
# 新建一个分支并切换到新分支
git checkout -b iss53

注：

​ git checkout -b 相当于 git branch 和 git checkout 两条指令的执行结果。

切换分支

​ 切换分支是有前提条件的，当前工作目录必须是“干净”的，即已追踪的文件没有需要提交的内容，才可以切换到其他分支。工作目录中存在未追踪的文件不会影响切换分支。

$ git status

On branch master
nothing to commit, working directory clean

​ 如果工作目录中以追踪的文件没有全部提交到仓库，那么是无法切换分支的。此时想要切换分支，可以有三种做法：

1. 提交修改内容；（commit）
2. 撤回修改内容；（checkout，reset）
3. 暂存修改内容；（stash）

分支合并

使用 git merge 命令进行分支合并：

# 切换当前分支为 master
git checkout master
# 将iss53分支的内容合并到 master上
git merge develop

合并冲突

​ 在团队协作中，难免会有多个人同时修改了同一个文件的时候，如果修改的是同一个地方，那么两个分支在合并的时候就会发生冲突。

$ git merge develop

Auto-merging mikai.txt
CONFLICT (content): Merge conflict in mikai.txt
Automatic merge failed; fix conflicts and then commit the result.

冲突后Git 会在相应的文件中做冲突标记：

<<<<<<< HEAD
int currRow = details.size();
=======
int cur = details.size();
>>>>>>> develop

​ <<<<<<< HEAD 到 ======= 之间的内容表示当前分支的内容，======= 到 >>>>>>> 之间的内容表示develop 分支的内容，发生冲突后，两个分支的内容都会保存下来，并做上特殊的冲突标记，等待开发人员处理。

处理冲突 （fix conflicts）

​ 处理冲突很简单，手动修改冲突内容，然后再次提交就解决冲突了。

查看分支

使用 git branch 查看分支信息:

# 查看本地分支
git branch
# 查看所有分支(包括远程分支)
git branch -a

# 查看本地分支(包含最后一次提交信息)
git branch -v
# 查看本地分支(包含最后一次提交信息和上游分支信息)
git branch -vv

$ git branch
  HAYA-12
  HAYA-213
  HAYA-67
  develop_haya
* haya-168
  haya-68
  master

注：

​ *号代办 HEAD 指针指向的分支，也就是当前分支。

跟踪分支

与远程分支关联的本地分支叫做跟踪分支，跟踪分支“跟踪”的分支叫“上游分支”。

语法： git checkout -b <branch> <remote>/<branch>

# 基于远程分支创建本地跟踪分支(十分常用)
git checkout -b iss53 origin iss53
# 因为此操作很常用，git提供了快捷命令 --track
git checkout --track origin/serverfix

# 设置或修改上游分支
git branch -u origin/develop
# 将本地分支内容推送到远程指定分支，并跟踪该分支
git push -u origin develop

# 查看本地分支的上游分支信息
git branch -vv

删除远程分支

使用带有 –delete 选项的 git push 命令删除一个远程分支：

# 删除远程分支
git push origin --delete iss53

工作原理

Git在进行提交时，保存的是当时文件的快照信息，而非差异比较信息。这是Git与其他版本控制系统的主要区别。

master 分支

Git仓库初始化的时候，会默认创建一个 master 的分支。

当创建一个新分支，新分支关联最新一次提交的引用：

HEAD 指针

Git 通过 HEAD 指针指向当前所在分支：

切换分支，HEAD 指针会发生变化：

在当前分支上继续提交数据，分支会往前推进：

再次切换到master 分支：

在 master 分支上继续提交数据：

团队分支管理实践

创建项目时（一般是服务型项目，工具型或辅助型项目可以简单一些），会针对不同环境创建三个常设分支：

1. develop：开发环境的稳定分支，公共开发环境基于该分支构建。
2. pre-release：测试环境的稳定分支，测试环境基于该分支构建。
3. master：生产环境的稳定分支，生产环境基于该分支构建。仅用来发布新版本，除了从pre-release或生产环境Bug修复分支进行merge，不接受任何其它修改

平时开发工作中，会根据需要由开发人员创建两类临时分支：

1. 功能（feature）分支：为了开发某个特定功能，从develop分支上面分出来的。开发完成后，要merge到develop分支。功能分支的命名，可以采用feature- 的形式命名(为任务单号)
2. Bug修复（fixbug）分支：为了修复某个bug，从常设分支上面分出来的。修复完成后，再merge到对应的分支。Bug修复分支的命名，可以采用fixbug- 的形式命名（为bug单号）

分支模式

分支是Git的强大特性，在项目开发中，分支模式不止一种。

主流的分支模式有如下几种：

• 主干开发模式
• Git-Flow模式
• GitHub-Flow模式
• GitLab-Flow模式

主干开发模式

​ Trunk Based Development，又叫主干开发。开发人员之间通过约定，向被指定为主干，一般为 master，的分支提交代码，以此来抵抗因为长期存在的多分支导致的开发压力。这样可以避免分支合并的困扰，保证随时拥有可发布的版本。

使用主干开发后，只有一个 master 分支了，所有新功能也都提交到 master 分支上，保证每次提交后 master 分支都是可随时发布的状态。

Git-Flow模式

​ Git-Flow 是为了解决不同特性之间并行开发所需要的一种开发模式。

GitHub-Flow模式

GitLab-Flow模式

Gitlab flow 分成两种情形来应付不同的开发流程：

• 持续发布
• 版本发布

持续发布

对于持续发布的项目，它建议在 master 分支以外，再建立不同的环境分支，每个环境都有对应的分支。比如，开发环境的分支是 master，预发环境的分支是 pre-production，生产环境的分支是 production。

开发分支 master 用于发布到测试环境，该分支为受保护的分支。

预发分支 pre-production 用于发布到预发环境，上游分支为 master。

正式分支 production 用于发布到正式环境，上游分支为 pre-production。

如果生产环境（production）发生错误，则要建一个新分支修改完后合并到最上游的开发分支（master）此时就是（Upstream first），且经过测试，再继续往 pre-production 合并，要经过测试没有问题了才能够再往下合并到生产环境。

版本发布

对于版本发布的项目，建议的做法是每一个稳定版本，都要从 master 分支拉出一个分支，比如 2-3-stable、2-4-stable 等。

在出现 bug 后，根据对应的 release branch 创建一个修复分支，修复工作完成后，一样要按照上游优选的原则，先合并到 master 分支，经过测试才能够合并到 release 分支，并且此时要更新小版本号。

小结

优点：

• 可以区分不同的环境部署。
• 对持续交付和持续集成友好。

缺点：

分支多，流程管理复杂。

master 发布分支

develop 开发测试分支

feature 特性分支

fixbug

master和develop 是长期开发分支

一般情况下feature与issue 一一对应，并且GitLab提供了支持

高级进阶

裸仓库

指定某个目录成为中心仓库（裸仓库）

git init --bare <repo> 

​ 这个命令执行后，将在本地创建一个名为 repo 的文件夹， 里面包含着 Git 的基本目录， 我们一般会将这个文件夹命名为后面加 .git 的形式，如 repo.git （这也是为什么我们从 GitHub clone 仓库的时候，地址都是 xxx.git 这样的形式的原因）。效果如下：

​ 使用 –bare 参数初始化的仓库，我们一般称之为裸仓库， 因为这样创建的仓库并不包含工作区 ，也就是说，我们并不能在这个目录下执行我们一般使用的 Git 命令。

​ 这个命令执行后，将在本地创建一个名为 repo 的文件夹， 里面包含着 Git 的基本目录，

托管平台

GitHub

​ GitHub 是一个面向开源和私有的软件项目托管平台，使用Git进行版本管理，目前GitHub已拥有上千万的开发者用户，是全球最大的软件项目托管平台。

发展历史

• 2008年，GitHub 正式上线；
• 2018年，微软以75亿美元的股票交易收购GitHub；
• 2020年，GitHub 收购npm，保证npm将永久免费；

Gitee

​ 开源中国推出的基于Git 的软件项目托管平台，服务器在中国，所以网速比较快。

GitLab

​ 越来越多的公司和组织使用 GitLab 搭建自己的软件项目托管平台。我们公司就是使用 GitLab 进行代码管理。

README

作者：银法王

版权声明：本文遵循知识共享许可协议3.0（CC 协议）： 署名-非商业性使用-相同方式共享 (by-nc-sa)

参考：

​ 《Pro Git》第二版

修改历史：

　　2020-07-01 第一次修订