框架5 Git
2019-03-25 本文已影响0人
莫小归
参考:
Git - 简明指南: http://rogerdudler.github.io/git-guide/index.zh.html
图解Git:http://marklodato.github.io/visual-git-guide/index-zh-cn.html
猴子都能懂得Git入门:https://backlog.com/git-tutorial/cn/intro/intro1_1.html
GitFlow:https://blog.csdn.net/xingbaozhen1210/article/details/81386269
一.版本控制
1.定义和作用
- 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统
- 版本控制可以
1）将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点
2）比较文件的变化细节，查出是谁修改了文件从而找到问题出现的原因，或者又是谁报告了某个功能缺陷
2.版本控制系统
-
本地版本控制系统
1）通过复制整个项目目录的方式保存不同的版本，简单但容易犯错
2）无法满足不同开发者的协同工作需要
本地版本控制系统
-
集中化版本控制系统(Centralized Version Control System)
1）由一个单一的集中管理的服务器保存所有文件的修订版本
2）协同工作的开发者们通过客户端连接服务器，提取最新文件或提交更新
3）存在单点故障的问题，且必须联网才能工作
集中化版本控制系统
-
分布式版本控制系统(Distributed Version Control System)
1）客户端不只是提取最新版本的文件快照，而是把代码仓库完整地镜像下来(完整备份)
2）任何一处协同工作用的服务器发生故障，时候都可以用镜像的本地仓库恢复
3）因为每个客户端均有完整的版本库，所以分布式版本控制系统不必联网就可工作，只需将自己的修改推送给别人就可以
分布式版本控制系统
二. Git
1.背景
- Linux内核项目组最先使用分布式版本控制系统BitKeeper来管理和维护代码
- 在BitKeeper与Linux结束合作后，Linux开源社区基于BitKeeper的使用经验，开发了自己的版本控制系统Git
2. Git特性
- Git采用直接记录快照，而非差异比较来存储程序版本
1）差异比较版本控制系统(CVS)以文件变更列表的方式存储信息，将保存的文件信息看作是一组基本文件和基本文件随事件逐步累积的差异增量，通过将基本文件和差异增量相加得到一个文件的最终版本，当差异增量过多时，取得最终文件将耗费大量时间和性能
2）Git在每次提交更新时，将当时的全部文件制作一个快照并保存这个快照的索引。如果文件没有修改，Git将不再重新存储该文件，而是保留一个链接指向之前存储的文件
a.差异比较
b.快照流
- Git的工作区域
1）工作目录(Working Directory)：实际文件
2）暂存区/索引(Staging Area/Index)：缓存区域
3）HEAD(Repository)：本地仓库，指向最后一次提交的结果
Git工作区域
- Git工作流程和三种状态
1）在工作目录中修改文件：已修改(modified)
2）将文件快照放入暂存区域，使其在下次提交时保存到Repository：已暂存(staged)
3）提交更新，将暂存区域的文件永久性存储到本地Git仓库目录：已提交(committed)
三. Git基本使用
1.创建和获取仓库
- 创建新仓库：创建新文件夹，进入并运行
git init - 从本地克隆仓库：
git clone /path/to/repository - 从服务器克隆仓库：
git clone username@host:/path/to/repository
2.添加和提交
- 添加更改到暂存区：单文件
git add <filename>或所有文件git add *或某类型文件git add *.txt - 提交改动到HEAD(还没到远端仓库)：
git commit -m "代码提交信息” - 推送改动到远端仓库：
git push origin master或git push origin <分支名>
3.分支
分支用来绝缘特性开发：创建仓库时master是默认分支，特性开发时在其他分支上进行开发，完成后再合并到master
- 创建分支“feature_x"，并切换过去：
git checkout -b feature_x - 切换回主分支：
git checkout master - 删除分支"feature_x"：
git branch -d feature_x - 将分支推送到远端仓库使他人可见：
git push origin <branch>
4.更新与合并
- 更新本地仓库至最新改动：
git pull
工作目录获取(fetch)并合并(merge)远端的改动 - 合并其他分支到当前分支：
git merge <branch>
自动合并更改可能出现冲突(conflicts)，此时需要修改冲突文件手动合并，修改完之后使用git add <filename>标记为合并成功 - 合并改动之前预览差异：
git diff <source_branch> <target_branch>
5.替换本地改动
- 使用HEAD中最新内容替换工作目录的文件：
git checkout -- <filename>
已添加到暂存区的改动以及新文件不受此影响 - 丢弃本地所有的改动和提交，从服务器获取最新的版本历史，并将本地主分支指向它：
git fetch origin
git reset --hard origin/master
6.查看仓库历史记录
- 输出本地仓库log：
git log - 只看某人的提交记录：
git log --author=bob - 通过ASCII艺术的树形结构展示所有分支，并在每个分支上标识名字与标签
git log --graph --oneline --decorate --all - 看哪些文件有改变：
git log --name-status - 更多git log参数信息参考：
git log --help
四. GitFlow
1.常用分支
- master
1）主分支，产品的功能全部实现后，最终在master分支对外发布
2）只读唯一分支，只能从其他分支(release/hotfix)合并，不能直接修改
3）所有在master分支的推送需要打标签记录 - develop
1）主开发分支，基于master分支克隆
2）当develop分支上的代码已实现需求说明书的所有需求并通过测试后，派生到release - feature
1）功能开发分支，基于develop分支克隆，代码合并回develop分支
2）此分支可仅仅保存在开发者自己的代码块而不提交 - release
1）功能测试分支，基于feature分支合并到develop后，从develop克隆
2）用于提交给测试人员测试，并在本分支修复测试发现的bug
3）修复完成后合并到develop/master分支并推送 - hotfix
1）补丁分支，基于master分支克隆，用于线上版本的紧急bug修复
2）修复完成后合并到develop/master分支并推送，打tag
2.主要工作流程
- 初始化gitflow，默认创建master，然后从master拉取第一个develop分支
- 从develop拉取多个feature进行编码开发(多个开发人员可同时拉取多个feature)
- feature分支完成后，合并到develop(不推送，feature功能还未提测)，当前feature可删除，也可不删除，但不可更改，有问题必须从release分支继续编码修改
- 从develop拉取release分支提测，提测过程中在release分支上修改bug
- release分支上线后，合并release到develop/master并推送，当前release可删除，也可不删除，但不可更改，有问题必须从master拉取hotfix分支进行修改
- master上线后，如有bug，从master拉取hotfix进行修改
- hotfix通过测试上线后，合并hotfix到develop/master并推送，当前hotfix可删除，也可不删除，但补丁未修复，需要从master拉取新的hotfix继续修改
- 在进行一个feature时，若develop分支有变动，如其他开发人员完成功能并上线，则需要将完成的功能合并到自己的分支上(即合并develop到当前feature分支)
- 在进行一个release时，若develop分支有变动，如其他开发人员完成功能并上线，则需要将完成的功能合并到自己的分支上
GitFlow工作流程
寒江天外，隐隐两三烟树
