玩转微服务-基础篇-Git
第一节 Git简介
Git是一款分布式源代码管理工具(版本控制工具) 。
Git得其数据更像是一系列微型文件系统的快照。使用Git，每次提交或保存项目状态时，Git基本上都会记录当时所有文件的外观，并存储对该快照的引用。为了提高效率，如果文件没有改变，Git不会再次存储文件，只是指向它已存储的上一个相同文件的链接。Git认为它的数据更像是一个快照流，会将数据作为项目的快照存储一段时间。可以有效、高速地处理从很小到非常大的项目版本管理。 也是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。
1. 数据库介绍
Git中的大多数操作只需要本地文件和资源来运行 - 通常不需要来自网络上另一台计算机的信息。当您在Git中执行操作时，几乎所有操作都只将数据添加到Git数据库。很难让系统做任何不可撤销的事情或者以任何方式擦除数据。与任何VCS一样，您可能会丢失或搞乱尚未提交的更改，但在将快照提交到Git之后，很难丢失，尤其是在您经常将数据库推送到另一个存储库时。
2. 作用
当你需要做一个大工程的时候，文件的管理无疑是非常庞大的工作，因为你需要不断的修改更新文件内容，同时可能还要保留旧版本保证可以复原，这样就需要备份多个版本的文件。
并且在大多数情况下一个工程需要在多数人来共同维护，那么这种情况下不同人之间修改内容的合并也是非常麻烦的，这时使用git就可以很轻松的解决这些问题。
3. 集中式和分布式
集中式版本控制系统：版本库集中存放在中央服务器。最大的毛病就是必须联网才能工作。
分布式版本控制系统：没有“中央服务器”，每个人的电脑上都是一个完整的版本库。你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
第二节 环境搭建
下载地址：Git (git-scm.com)
环境配置：本地path中，添加git的安装目标地址，使其可以再全局中使用。
第三节 Git的工作机制
简介
1、工作区：存放代码的地方
2、暂存区（stage 或 index）：临时存储，将工作区的代码让git知道，通过git add将代码放到暂存区
3、本地库：将暂存区的代码提交到本地库，就会生成对应的历史版本，这个代码就无法删除
4、远程库：将本地库的代码推送到远程库
流程示意
- 图中左侧为工作区，右侧为版本库。在版本库中标记为 “index” 的区域是暂存区（stage/index），标记为 “master” 的是 master 分支所代表的目录树。
- 图中我们可以看出此时 “HEAD” 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
- 图中的 objects 标识的区域为 Git 的对象库，实际位于 “.git/objects” 目录下，里面包含了创建的各种对象及内容。
- 当对工作区修改（或新增）的文件执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
- 当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。
- 当执行 git reset HEAD 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。
- 当执行 git rm --cached 命令时，会直接从暂存区删除文件，工作区则不做出改变。
- 当执行 git checkout . 或者 git checkout – 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区中的改动。
- 当执行 git checkout HEAD . 或者 git checkout HEAD 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。
工作流图
第四节 Git命令
一. 基础命令
git --version 查看系统的git版本；
git help 查看git的帮助命令
二. 全局配置
git config --global user.name 用户名
git config --global user.email 设置用户邮箱
git config --global credential.helper cache 开启密码缓存功能：
git config --global credential.helper 'cache --timeout=3600' 开启后Git会在明文形式下缓存密码。缓存的时间默认为15分钟，可以通过以下命令修改缓存时间
// 存储密码到文件
git config --global credential.helper store
git config --global credential.helper 'store --file ~/.git-credentials' 设置密码文件路径
// 以上命令将密码保存到~/.git-credentials文件中。注意，密码保存在明文文件中，需要注意保护文件。
三.仓库操作
1. 创建仓库
git init 创建仓库
git status 查看项目仓库状态
git clone 克隆远程仓库
git clone https://username:[email protected]/user/repo.git // 带用户信息访问，密码不能包含@符号
2. 查看日志
git reflog 查看本地工作区中的历史记录
git log 查看提交历史记录
git log --pretty=oneline 显示单行
3. 分支管理
git branch 查看已经创建的分支
git branch -v
git branch -av
git branch 分支名 创建分支
git checkout 分支名 切换分支
git branch -d 分支名 删除分支
git merge 分支名称 合并指定的分支到当前分支
git checkout 分支名称 切换分支
git checkout -b 分支名称 创建新分支并切换
4. 文件操作
git add . 添加所有位处理的文件到暂存区
git add 文件名称 添加指定的文件到暂存区
git commit -m 提交的信息内容
git commit -m “日志信息” 文件名 按照文件的
git diff 可以对比两个版本的差异
git diff 文件.. 本地工作区和暂存区的diff信息：git diff 或者 git diff file
git diff --cached 暂存区和版本库的diff信息（使用git add 将工作区修改保存到了暂存区后）
git diff commit1 commit2 或 git diff branch1 branch2
版本库中不同commit、分支的diff信息（使用git commit 将暂存区修改提交到了版本库）
分支Diff
git diff branch1 branch2 --stat //--stat参数，显示两分支简单diff信息
git diff branch1 branch2 //显示两分支详细的diff信息
git diff branch1 branch2 path //显示两分支指定路径下文件的详细diff信息
git diff branch1 branch2 file_name(带路径) //显示两分支指定文件的详细diff信息
5. 版本管理
git remote add 添加远程仓库
git push 推送本地内容到远程仓库
git remote set-url 修改本地指向的远程仓库地址
git fetch 刷新服务器与本地状态，并以远程更新
git pull 获取远程数据的变更 pull一般是的当前分支
git remote [-v] 查看远程仓库信息
git brache --set-upstream origin/ 建立本地分支和远程分支的关联
git push origin -delete 分支名称 删除远程分支
6. 标签管理
git tag -a -m 创建标签
git tag 所有标签
git show xxx 指定标签
git tag -d 删除本地标签
// 删除远程仓库
git push origin :refs/tags/
git push origin --delete
git push origin :
// 推送标签到远程
git push origin 推送单个标签到远程
git push origin -tags 推送所有未推送的标签到远程
7. 暂存修改
git stash --help 查看修改的命令
git stash 进行储藏
git stash -m "xxxxx" 储藏添加信息
git stash list 查看储藏
git stash apply 应用储藏，
git stash pop 应用最近一次储藏\
git stash drop 删除应用的储藏
git stash clear
对特定范围文件进行储藏
git stash [-u|--include-untracked]：对未追踪文件也进行储藏
git stash [-S|--staged]: 只对暂存区文件进行储藏
git stash [-a|--all]: 对所有文件进行储藏
第五节 Git的工作流
一. 简介
Gitflow是一个Git自带的Git工作流，它最初是一种用于管理Git分支的破坏性和新颖的策略。是现代连续软件开发和DevOps实践的最佳实践。Giflow是另一种Git分支模型，它涉及到特征分支和多个主分支的使用。最早由文森特·德里森在nvie首次出版并广受欢迎。与传统的开发相比，Giflow拥有众多、寿命更长的分支和更大的提交。在此模型下，开发人员创建一个功能分支，并延迟将其合并到主干分支，直到功能完成。这些长期存在的功能分支需要更多的协作才能合并，并且偏离主干分支的风险更高。
二. 常用的分支管理
| 分支名称 | 分支说明 |
|---|---|
| Production/master | 生产分支，即 Master分支。只能从其他分支合并，不能直接修改 |
| Release | 发布分支，基于 Develop 分支创建，待发布完成后合并到 Develop 和 Production 分支去 |
| Develop | 主开发分支，包含所有要发布到下一个 Release 的代码，该分支主要合并其他分支内容 |
| Feature | 新功能分支，基于 Develop 分支创建，开发新功能，待开发完毕合并至 Develop 分支 |
| Hotfix | 修复分支，基于 Production 分支创建，待修复完成后合并到 Develop 和 Production 分支去，同时在 Master 上打一个tag |
三. 分支介绍
Git Flow的核心就是分支(Branch），通过在项目的不同阶段对分支的不同操作（包括但不限于创建、合并、变基等）来实现一个完整的高效率的工作流程。Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支包含主要分支和开发分支，用于组织与软件开发、部署相关的活动；辅助分支包含功能分支、预发分支、热修复分支以及其他自定义分支，是为了解决特定的问题而进行的各种开发活动。 与主分支不同，这些分支总是有有限的生命时间，因为它们最终将被移除。
> 主分支：master分支、develop分支；辅助分支：feature分支、release分支、hotfix分支
master
主要分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，主要分支上的代码要被更新。同时，每一次更新，都需要在主要分支上打上对应的版本号。
任何人不允许在主要分支上进行代码的直接提交，只接受其他分支的合入。原则上主要分支上的代码必须是合并自经过多轮测试及已经发布一段时间且线上稳定的预发分支。
master分支只存放历史发布(release)版本的源代码。即用于存放对外发布的版本，任何时候在这个分支获取到的都是稳定的已发布的版本。各个版本通过tag来标记。上图里的v0.1和v0.2就是tag。
Develop
开发分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当开发分支到达一个稳定的点并准备好发布时，应该从该点拉取一个预发分支并附上发布版本号。也有人称开发分支为集成分支，因为会基于该分支和持续集成工具做自动化的构建。
开发分支接受其他辅助分支的合入，最常见的就是功能分支，开发一个新功能时拉取新的功能分支，开发完成后再并入开发分支。需要注意的是，合入开发的分支必须保证功能完整，不影响开发分支的正常运行。
develop分支则用来整合各个feature分支。开发中的版本的源代码存放在这里。即用于日常开发，存放最新的开发版。
功能分支（Feature）
功能分支一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。功能分支要求足够细粒度以避免成为长期存在的功能分支，应当小步合并而不是一次合并大量代码。
功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃。
每一个特性(feature)都必须在自己的分支里开发，feature分支派生自develop分支。
feature分支只存在于开发者本地，不能被提交到远程库。当feature开发完毕后，要合并回develop分支。feature分支永远不会和master分支打交道。
预发分支（Release）
预发分支一般命名为 Release/1.2（后面是版本号），该分支专为测试—发布新的版本而开辟，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。
预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署。
预发分支只能拉取自开发分支，合并回开发分支和主要分支。
release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。
我们用这个分支干所有和发布有关的事情，比如：
把这个分支打包给测试人员测试
在这个分支里修复bug
编写发布文档
所以，在这个分支里面绝对不会添加新的特性。
当和发布相关的工作都完成后，release分支合并回develop和master分支。
单独搞一个release分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。
热修复分支（Hotfix）
热修复分支一般命名为Hotfix/1.2.1（后面是版本号），当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的tag版本（比如1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责代码修复的人并行、独立的开展工作。
热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。
一个项目发布后或多或少肯定会有一些bug存在，而bug的修复工作并不适合在develop上做，这是因为
develop分支上包含还未验证过的feature
用户未必需要develop上的feature
develop还不能马上发布，而客户急需这个bug的修复。
这时就需要新建hotfix分支，hotfix分支派生自master分支，仅仅用于修复bug，当bug修复完毕后，马上回归到master分支，然后发布一个新版本，比如，v0.1.1。
同时hotfix也要合并回develop分支，这样develop分支就能享受到bug修复的好处了。
四. 工作流程
五. 版本号
版本号（公开）
对外正式发布的版本号，一般只需要通过三位数字的版本号：主版本号.次版本号.修订号：
- 主版本号：做了一些不兼容的API修改，可以理解为一个大的产品更新。
- 次版本号：新增了一些功能，可以理解为合并了一个feature。
- 修订号：修复了一些bug，可以理解为合并了一个hotfix。
版本号（测试）
假如我们想要发布 1.0.1 版本，在开发团队内部，可能会提交多次的测试版本，交付给测试人员测试。这时候需要基于 1.0.1 版本号后面，加上一些其他的版本号。
- alpha：内测版，一般不向外部发布，bug会比较多，功能也不全，一般只有测试人员使用。
- beta：公测版，该版本仍然存在很多bug，但比alpha版本稳定一些。这个阶段版本还会不断增加新功能。
- RC：发行候选版本，基本不再加入新的功能，主要修复bug。是最终发布成正式版的前一个版本，将bug修改完就可以发布成正式版了。
- Release：正式发布版，官方推荐使用的版本。在正式发布的时候，可以不加Release，即 1.0.1 等同于 1.0.1-Release
可能基于这些版本号还有更细致的划分，这个可以根据实际项目情况调整。例如：v1.0.0-beta.1、v1.0.0-beta.2，或v1.0.0-200910-beta等。
这里提一下用的比较广泛的：语义化版本控制
六.GitFlow工具
这里使用IDEA插件：Git Flow Integration /Git Flow Integration plus 推荐
git-flow-avh: 流程管理工具