一、 Git介绍
1. Git vs SVN
Git 和SVN 孰优孰劣,每个人都有不同的体验
-
Git是分布式的,SVN是集中式的
SVN只有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。
Git每一个终端都是一个仓库,客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整地镜像下来。每一次的提取操作, 实际上都是一次对代码仓库的完整备份。Git不仅仅是个版本控制系统,它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN背景的人,你需要做一定的思想转换,来适应Git提供的一些概念和特征。
-
Git复杂概念多,SVN简单易上手
Git命令太多,日常工作需要掌握add、commit、status、fetch、push、rebase等,若要熟练掌握,还需要掌握rebase和merge的区别、fetch和pull的区别,除此之外,还有cherry-pick、submodule、stash等功能。
从易用性的角度看,SVN简单易上手,对新手很友好,但是从另一方面看,Git命令多意味着功能多,如果我们掌握大部分的Git的功能,体会到其中的奥妙,就会发现再也回不去SVN的时代了。
-
Git分支廉价、SVN分支昂贵
在版本管理中,分支是很常用的功能,如发布需要发布分支,特定需求开发需要feature分支,大团队还会有开发分支,稳定分支等,在开发过程中常常存在床架你分支、切换分支的需求。
Git分支是指针指向某次提交,而SVN分支是拷贝的目录,这个特性使Git的分支切换特别迅速,创建成本低。
而且Git分支有本地分支、SVN无本地分支,在实际开发过程中,经常会遇到有些代码没写完,但是需紧急处理其他问题,如果我们使用Git,可以通过创建本地分支存储没写完的代码,待问题处理完成后,再回到本地分支继续写代码。
2 Git命令操作
2.1 基本介绍
- Workspace:工作区
- Index / Stage:暂存区
- Repository:仓库区(或本地仓库)
- Remote:远程仓库
git init:初始化本地库
git status:查看工作区、暂存区的状态
git add <file name>:将工作区的“新建/修改”添加到暂存区
git rm --cached <file name>:移除暂存区的修改
git commit -m "提交日志" <file name>:文件从暂存区到本地库
2.2 日志查看
git log:查看历史提交
tip:空格向下翻页,b向上翻页,q退出
git log --pretty=oneline:以漂亮的一行显示,包含全部哈希索引值
git log --oneline:以简洁的一行显示,包含简洁哈希索引值
git reflog:以简洁的一行显示,包含简洁哈希索引值,同时显示移动到某个历史版本所需的步数
2.3 版本控制
git reset --hard 简洁/完整哈希索引值:回到指定哈希值所对应的版本
git reset --hard HEAD:强制工作区、暂存区、本地库为当前HEAD指针所在的版本
git reset --hard HEAD^:后退一个版本
tip:一个^表示回退一个版本
git reset --hard HEAD~1:后退一个版本
tip:波浪线~后面的数字表示后退几个版本
2.4 比较差异
git diff:比较工作区和暂存区的所有文件差异
git diff <file name>:比较工作区和暂存区的指定文件的差异
git diff HEAD|HEAD^|HEAD~|哈希索引值 <file name>:比较工作区跟本地库的某个版本的指定文件的差异
2.5 分支操作
git branch -v:查看所有分支
git branch -d <分支名>:删除本地分支
git branch <分支名>:新建分支
git checkout <分支名>:切换分支
git merge <被合并分支名>:合并分支
tip:如master分支合并 hot_fix分支,那么当前必须处于master分支上,然后执行 git merge hot_fix 命令
tip2:合并出现冲突
①删除git自动标记符号,如<<<<<<< HEAD、>>>>>>>等
②修改到满意后,保存退出
③git add <file name>
④git commit -m "日志信息",此时后面不要带文件名
2.6 举一个例子
# 克隆一个项目
git clone https://github.com/NQLoong/gittest.git
# 新增一个文件
$ vim readme.text
$ git add .
$ git commit -m "init project"
[master (root-commit) 04c24d1] init project
1 file changed, 1 insertion(+)
create mode 100644 readme.text
#创建一个dev分支
$ git branch dev
$ git branch -a
dev
* master
#切换到dev分支
$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean
#push到远程分支
git push --set-upstream origin master #建立远程关联
二、 Git 工作流
1. Git的优势
- 分布式的版本管理,可以离线工作
- 记录整个分支的变更记录
- 切换分支很快
2. 中心式协同工作流
2.1 介绍
- 从服务器上 git pull origin master把代码同步下来
- git commit到本地仓库
- git push orgin master远程仓库
2.2 异常情况
如果在第 3 步发现 push 失败,因为别人已经提交了,那么你需要先把服务器上的代码给 pull 下来,为了避免有 merge 动作,你可以使用 git pull --rebase 。这样就可以把服务器上的提交直接合并到你的代码中,对此,Git 的操作是这样的。
3 功能分支协同工作流
3.1介绍
- git checkout -b new-feature 创建“new-feature”分支(针对某一功能)
- 负责该分支的人员进行add、commit操作
- 开发完成后git push -u orgin new-feature 把分支push到服务器上
- 其他人员 git pull -rebase 拿到最新的这个分支的代码
- 最后 Pull Request 方式Code Review后合并到Master分支上
3.2 分支模型图
4. GitFlow 协同工作流
4.1 背景需求
- 有一个分支保持干净,永远可以发布到线上
- 代码可以上线时依旧可以开发下一个版本的代码
- 已经发布的代码可以做Bug-Fix,而且不会把正在开发的代码提交到生产线上去
4.2 介绍
4.3 分支类型
- master分支:主干分支,用作发布环境,上面的每一次提交都是可以发布的。
- Feature分支:功能分支,用于开发功能,对应开发环境
- Developer分支:开发分支,一旦功能开发完成,就把功能分支向Developer分支合并,合并完成后删除功能分支。这个分支对应集成测试环境
- Release分支:当Developer分支测试达到可以发布时,开出一个Release分支做发布前的准备工作(对应预发环境) Release分支可以上线时,把Release分支向Master分支和Developer分支同时合并,保证代码一致性,然后把Release分支删除
- HotFix分支:处理线上Bug分支,从Master分支拉出,处理完成后向 Developer和Release分支合并
5 GitHub Flow
5.1 介绍
-
把官方库的代码fork到自己的代码库
-
开发人员再自己的代码库中任意开发
-
开发人员的代码库中配置两个远程仓库,一个自己的远程昂库,一个官方仓库
-
本地建“功能分支”,在该分支上做代码开发
-
功能被push到开发人员自己的代码仓库中
-
向“官方库”发起pull request,并做Code Review,一旦通过就向官方库合并。
比较依赖好的CI/CD工具
6 GitLab Flow
6.1 介绍
相比GitHub Flow,引入环境分支
7 协同工作流的本质
- 不同团队能尽可能地并行开发
- 不同软件版本和代码的一致性
- 不同环境和代码的一致性
- 生产环境上的代码总是能对应到稳定的代码上
三、 运维中心开发模式
- 每周拉取一个时间戳的发布分支2020_07_12
- 开发小组成员拉取功能分支到本地,进行开发,每天对分支进行commit 、pull
- 发布分支集成测试通过后合并到master分支(打上tag标志稳定版本),继续从master拉取下一个功能分支开发