导读目录

• 1. 为什么要用 Git 版本控制
• 2.Git 文件构造和存储原理
• 3.GitFlow 分支开发标准
• 4.Git 常见问题和解决方案
• 5. 继续集成和麻利开发

1. 为什么要用 Git 版本控制

以后的版本控制系统有以下几种:

1. Git 是目前世界上最先进的分布式版本控制系统，应用 Git 和 Gitlab 搭建版本控制环境是当初互联网公司最风行的版本控制形式
2. SVN TortoiseSVN 是一款十分易于应用的跨平台的 版本控制 / 版本控制 / 源代码控制软件。
3. HG Mercurial 是一种轻量级分布式版本控制系统，采纳 Python 语言实现，易于学习和应用，扩展性强。
4. CVS 是版本控制系统，是源配置管理（SCM）的重要组成部分。

SVN 存在的缺点

Git 的劣势

1.Git 把内容按元数据形式存储,hash 存储形式, 每一次提交都是一个整个我的项目的镜像.

2. 每个客户端的源, 都能够作为 clone 对象. 蕴含所有核心版本库的元素.

两者差别

源于 linux 的一句话, 所有零碎皆为文件, svn 右边, git 左边. Git 每次提交, 都是一个对我的项目的 残缺快照.

[传送门]svn 转 Git 治理教程

2.Git 文件构造和存储原理

Git 的文件构造

当在一个新目录或已有目录执行 git init 时，Git 会创立一个 .git 目录。这个目录蕴含了简直所有 Git 存储和操作的对象。

所有零碎都是有文件形成. 这些文件治理着 一个我的项目的版本.

Git 存储构造

Git 的文件存储构造, 不失当的类比 java 中 hashMap 的存储的(位桶数组 + 单向链表或红黑树) 桶链存储构造, 艰深的讲: 先用桶用分类规定. 把一堆数据, 装进筒子里, 如下图所示.

Git 的存储形式

文件存储, 版本越多, 存储信息越大, 运行也就越慢.

下图, 是 一次 commit 产生的一棵树(一个快照).

只有文件内容雷同, 那么就是一个 blob, (不论他的门路是否一样),

Git 的一次提交, commit 信息会刷新, 这次产生变动的文件的 hash 值, 也就是 blob,

git 应用 hash 值作为文件名，次要是为了比照差别，只有文件变了，那么该文件的 hash 值就会变，与老版本的文件名就不同，就能够据此断定有差别，这个信息会随着文件夹向上传递，也就催生了不同的 tree 蕴含这些不同的 blob。

Emm…沿着思路想上来..

一个文件, 批改后, 内容变动了, 产生两个 blob,
批改次数越多, blob 越多. 内存占用越来越大?

git gc 理解一下….

Git 往磁盘保留对象时默认应用的格局叫涣散对象 (loose object) 格局。Git 时不时地将这些对象打包至一个叫 packfile 的二进制文件以节俭空间并提高效率。当仓库中有太多的涣散对象，或是手工调用 git gc 命令，或推送至近程服务器时，Git 都会这样做.

为什么 Git 新建分支速度快?

关上我的项目 Git 目录, 寻找出一个分支, 并关上, 查看外面的 sha- 1 字符串.

咱们能够在分支间随便切换，并且都是霎时切换实现。

Git 根本命名

Git 的基本操作命令，在这里不做过多赘述，本节会着重解说 Git 中的两个纳闷点。

Reset 和 Revert 区别

git reset
回滚代码到 某 commit 点, 删除之前版本(想复原到之前某个提交的版本，且那个版本之后提交的版本咱们都不要了，就能够用这种办法).

Git revert
如果咱们想复原之前的某一版本, 而不删除之前版本（该版本不是 merge 类型，然而又想保留该指标版本前面的版本，记录下这整个版本变动流程，就能够用这种办法）。

工作区和暂存区

add 命令 当初临时有两个作用：1 将文件增加到被跟踪状态 2：将文件从工作区放到暂存区
Commit 文件，提交到版本库。

1. 仓库级的配置文件：在仓库的 .git/.gitconfig，该配置文件只对所在的仓库无效。
2. 全局配置文件：Mac 零碎在 ~/.gitconfig，Windows 零碎在 C:Users< 用户名 >.gitconfig。
3. 零碎级的配置文件：在 Git 的装置目录下（Mac 零碎下装置目录在 /usr/local/git）的 etc 文件夹中的 gitconfig。

明确了为啥要用 git 了, 那这里就要开始筹备 SVN 迁徙 git 啦~ []()

明确了为啥要用 git 了, 那这里就要学习 git 的分支治理和 gitflow 流程啦~ []()

3.GitFlow 分支开发标准

骨干分支 master(为我的项目公布的最新版本),

也是用于部署生产环境的分支，确保 master 分支稳定性
master 分支个别由develop 以及 hotfix 分支合并，任何工夫都不能间接批改代码

develop(为最新的代码)

develop 为开发分支，始终保持最新实现以及 bug 修复后的代码
个别开发的新性能时，feature 分支都是基于 develop 分支下创立的

业务分支 module

货运, 调度 , 等等.
业务线module/ 货运

个性分支 feature

开发新性能时，以 develop 为根底创立 feature 分支
结尾的为个性分支，例如实验性且成果不好的代码变更
能够从 develop 分支发动 feature 分支
代码必须合并回 develop 分支

分支命名: feature/
命名规定:feature/ 分享性能、module/ 货运_feature/login 性能、feature/sonar 扫描谬误批改

release 分支

release 分支专为 公布版本而建的分支. 也能够叫预生产环境. 也能够用 master 分支 +tag 形式来代替.

个别从 develope 分支创立. 当 develop 分支上的代码 曾经 蕴含了所有将公布的版本中打算的性能 ，并且 已通过所有测试 时，咱们就能够思考筹备创立 release 分支.

也就是说, 开发实现, 测试结束后, 筹备公布版本的分支release/v1.0.0 ,

创立后, 只容许做小的缺点修改, 以及筹备公布版本所需的各项阐明信息（版本号、公布工夫, 渠道散布等等). 确定没问题合并到 master 和 develop，能够删除分支, 前期有须要间接从 master 分支的 tag 中找到并 checkout 为 release/xxx 分支, 进行 bug 修复.

等公布胜利后, 切记要把将新的 release/v1.0.0 的代码合并到 develope 中.

其余分支

issue 分支: 用于我的项目代码评审, 或者整改 gitlab 提出的 issue. 命名为issue/ 代码平安加固

hotfix 分支: 用于线上 bug 修复, 在特定 release 分支上创立, 实现后须要同时推到 对应 release 分支, 待测试没有问题后, 推送到 develop 分支, 以及 master 分支.

开发迭代思路

一般迭代思路

–> 新建我的项目 -> 创立 develope 分支,master 分支 —> 需要 -> 在 develope 分支进行开发 ->merge 其他人代码 -> 实现性能 -> 测试在 develope 分支进行测试 -> 测试完结 -> 切换到 master 分支,merge develope 代码 -> 封包, 打上 tag 标签 v1.0.0—–> 下一个需要.

麻利迭代思路

4.Git 常见问题和解决方案

1. 如何批改 git commit 的 msg?

不倡议批改某个 commit 的 messge!!!!!!
commit 批改, 会同时批改掉 commitid, 也就意味着这是一次新的提交, 会打乱提交树的程序.

2. 为什么账户名和邮箱名无奈批改?

1.local，在.git/config 外面, 针对以后仓库的配置，git 配置默认为 local 级别

git config [--local] user.name 本仓库的用户名
git config [--local] user.email 本仓库的用户邮箱

2.global，在集体 home 目录下的, 针对以后零碎用户的仓库

git config --global user.name 本仓库的用户名
git config --global user.email  本仓库的用户邮箱

3.system，在 git 装置目录的下, 针对以后操作系统所有用户的仓库。（该级别通常不用于配置用户信息）

git config --system user.name 本仓库的用户名
git config --system user.email 本仓库的用户邮箱

3. 如何疏忽不须要提交的文件?

应用 .ignore 文件

.ignore放到和 .git 同级的目录中. 能够自定义规定

PS: 如果之前增加到了 git 治理, 然而当初想疏忽掉怎么办?

编辑你的 .ignore 文件后, 执行以下命令

git rm -r --cached . 
git add .
git commit -am "Remove ignored files"
git push 你的远端仓库

4. 糟了, 代码不小心 push 到了远端仓库怎么办?

git revert 你的 commitID
// 将代码状态撤回到该commitID 之前.

5. 共事提交代码后, 我的分支只想要他的某几个commit?

cherry-pick 理解一下.

• 切换到 抉择共事的分支
• 抉择几个想要的commit
• 进行 cherry-pick 操作

6. 提交记录不小心弄木有了, 有木有后悔药?

git reflog 理解一下, 联合git rebase 要指向的commitID

7.Idea 的 Git 插件下, 他人分支提交代码,

本人分支 merge 不到, 说他人没提交代码?

Git 是分布式的, 狂点 refresh 没用的!!!…
须要从新 pull 远端代码, 来更新本地仓库. 才会有最新的提交记录.

8. 为什么我 merge, 或者 cherry-pick 后的 commit 记录找不到了?

**Git 的 commit 排序, 是依照工夫排序的!!!!!! Commit 工夫越新, 越靠前
还有看 log 是否是以后 branch.**

9. 其余注意事项

• git push -f 不能应用. 他会清空之前的 commit 记录.
• 公共分支 master和 develop, 不能进行 rebase操作, 原则上只能改本人的分支.
• push 代码之前, 尽量先 pull 代码, 将远端代码更新到本地,merge 结束后, 运行失常后, 再进行 push 操作.
• . 为了防止代码抵触, 本地仓库要及时 push 到近程 gitlab

6. 可继续集成

可继续集成 又叫Continuous integration(CI), 一种软件开发实际，即团队开发成员常常集成它们的工作，通过每个成员每天至多集成一次，也就意味着每天可能会产生屡次集成。每次集成都通过自动化的构建（包含编译，公布，自动化测试）来验证，从而尽早地发现集成谬误。

有两种形式

• gitlab+Jenkins
• gitlab+gitlabCI

生产模型

Jenkins

Jenkins  是一个可扩大的继续集成引擎。

次要性能

• 继续、主动地构建 / 测试软件我的项目.
• 监控一些定时执行的工作.

次要可配置我的项目

• 自定义构建参数
• 执行 gradle,maven 等我的项目脚本
• 定时工作
• 挂载 gitlab,sonar 等第三方平台
• 界面高度可定制化

Jenkins 业务流程

• 我的项目配置
• 自定义构建参数
• 自定义构建 log 日志输入
• 查看 build 日志, 谬误日志
• 指标文件生成
• 构建实现告诉 (钉钉, 测试邮件等等)

Jenkins 管道工作

6. 其余

常用工具

用 Mac, linux, 还是 windows, 都会有对应的 Git 图形治理界面, 次要展现 idea 插件.

• sourcetree
• idea 的 git 插件
• Git 命令
• TortoiseGit

  以 idea 为例

### 如何应用 Git 进行团队 CodeReview?

• GitLab 设置爱护分支 (以后形式)
• Git + Gerrit 联合(步骤繁琐)