不了解Git?看这篇文章就够了

  • Git和SVN的区别
  • Git核心知识
    • Git结构
    • Git相关命令和结构的关系
      • 提交版本
      • 发布版本
      • 取回更新
      • 分支与合并
      • 更多
  • Git Flow

Git和SVN的区别

  • SVN是集中式版本控制系统,即项目版本库存放在“中央服务器”,开发人员都是基于中央版本库上的项目进行开发。中央服务器就好比是一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了,再放回图书馆。
image
  • Git是分布式版本控制系统,即每个人的电脑上都有一个完整的版本库,例如在同一局域网内,A可以把本地版本库推送给B,B也可以推送给其他开发人员。但是,在实际开发中,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,开发人员在自己本地版本库上进行开发,再把本地版本库代码推送到远程“中央服务器”。例如:github、码云等平台。
image
image

Git核心知识

使用Git前,需要先建立一个仓库(repository)。可以使用一个已经存在的目录作为Git仓库或创建一个空目录。
使用您当前目录作为Git仓库,我们只需使他初始化。
git init
使用我们指定目录作为Git仓库。
git init <name>

Git结构

image

工作区、暂存区、版本库和远程仓库

  • 工作区

就是你在电脑里能看到的目录,比如我的 git-demo 文件夹就是一个工作区。

image
  • 暂存区

英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件(.git/index)中,所以我们把暂存区有时也叫作索引(index)。

  • 版本库

工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。

  • 远程仓库

即中央服务器,例如:github、码云等平台。

Git相关命令和结构的关系

image

添加新文件

我们有一个仓库,但什么也没有,可以使用add命令添加文件。


# 添加单个文件

git add <fileName>

# 添加多个文件

git add <fileName1> <fileName2>

# 添加所有文件

git add --all

提交版本

现在我们已经添加了这些文件,我们希望它们能够真正被保存在Git仓库。</br>

为此,我们将它们提交到仓库。


git commit -m "some message"

当我们修改了很多文件,而不想每一个都add,想commit自动来提交本地修改,我们可以使用-a标识。


git commit -a -m "some message"

git commit命令的-a选项可将所有被修改或者已删除的且已经被git管理的文档提交到仓库中。

千万注意,-a不会造成新文件被提交,只能修改。

发布版本

假设我们本地版本库是由远程仓库克隆下来的,那么你一开始执行的命令应该是


git clone http://123.123.123.1:9099/group/demo.git

现在,我们本地版本库的改动可以推送到服务器


git push http://123.123.123.1:9099/group/demo.git

取回更新

如果您已经按上面的进行push,下面命令表示,将远程版本库的改动同步到本地。


git pull

分支与合并

分支在本地完成,速度快。要创建一个新的分支,我们使用branch命令。


git branch <name>

branch命令不会将我们带入分支,只是创建一个新分支。所以我们使用checkout命令来更改分支。


git checkout <name>

如果想将其它分支的改动合并到当前分支,使用merge命令


git merge <其它分支>

如果您想删除分支,我们使用-d标识。


git branch -d <name>

更多

  1. git status

命令用于显示工作目录和暂存区的状态。使用此命令能看到那些修改被暂存到了, 哪些没有, 哪些文件没有被Git tracked到.

  1. git diff

查看工作区和暂存区的区别

  1. git diff --chached

查看暂存区和本地仓库的区别

  1. git log

查看版本库的提交记录

  1. git reflog

用来记录你的每一次命令

  1. git reset

版本回退

Git Flow

Git flow是基于git之上的一种软件开发迭代模型。Git flow是使用git进行源代码管理的一套行为规范。

Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题,提高开发效率。

clipboard (5).png

Git Flow中的分支

Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动;辅助分支为了解决特定的问题而进行的各种开发活动。

主分支

  • master分支

master 分支为主分支,用于部署生产环境,需要确保master分支的稳定性。

  • develop分支

develop 为开发环境主干分支,基于 master 分支检出。

辅助分支

  • feature分支

feature 分支为功能开发分支,由开发人员基于 develop 分支创建 feature-<功能模块> 分支。

  • release分支

release 分支为预上线分支,基于 develop 或 master 分支检出。用于准备发布新阶段版本或者修复线上bug版本。

  • hotfix分支

生产环境 bug 修复分支,基于 master 分支检出。

  • bugfix分支

预上线 bug 修复分支,基于 release 分支检出。

工作流程

项目开始(master、develop)

  1. 开发组长,基于master主干创建develop分支。master和develop就作为仓库的两个主干,并且将它们的加权限限制,只有管理员可修改。

开发阶段(master、develop、feature)

  1. 基于develop创建多个feature分支(如:feature/login),对应功能模块的开发人员,基于该分支开发新功能。

  2. 开发人员,测试新功能完成以后,在git上发起pull request把代码合并到到develop分支上。

  3. 开发组长,在确认代码没有问题后,通过该pull request 的合并请求。当所有的功能都开发完了,所有的feature分支都合并到develop上。

测试阶段-开始测试(master、develop、release)

  1. 开发组长,基于develop分支创建一个release预发布分支(如:release/1.0.0),并设置release分支只有管理员有权限修改。

  2. 基于release/1.0.0分支的代码进行测试。

测试阶段-测试中(master、develop、release、bugfix)

  1. 当测试发现bug时,基于当前release/1.0.0分支创建bugfix分支(如:bugfix/问题编号),开发人员基于该bugfix分支进行bug修复。

  2. 开发人员在bug修复后,向release/1.0.0分支提交 pull request 申请。

  3. 开发组长在确认bug修复完成后,通过该pull request 的合并请求。所有bug修复完成后,当前release版本下,所有bugfix分支都合并到release/1.0.0上。

测试阶段-测试完毕(master、develop、tag)

  1. 开发组长发起pull request,把release/1.0.0代码合并到到master分支上。

  2. 基于master分支创建一个里程碑版本(tag)名为1.0.0-Release,并且在github上发布一个Release,可以将当前master代码以及相关包存档。

  3. 原则上只需保留master、develop两个分支,和1.0.0-Release里程碑版本(tag)。删除完成使命的其他分支:多个feature分支、多个bugfix分支和release/1.0.0。

线上bug-master(master、develop、hotfix)

  1. 线上版本出现bug,可以基于最新版本(master)进行修复,可以基于master创建hotfix分支(如:hotfix/问题编号),开发人员基于该hotfix分支进行bug修复。

  2. 开发人员在bug修复后,向master分支提交 pull request 申请。

  3. 开发组长在确认bug修复完成后,通过该pull request 的合并请求。基于master分支创建一个里程碑修复版本(tag),假如当前版本为1.2.0-Release,则修复版本为1.2.1-Release。

线上bug-历史版本(master、develop、tag、hotfix)

  1. 用户基于某个里程碑版本tag(如:1.0.0-Release)提出bug,创建一个issue。如果master版本已经发布到1.0.0以后了(如:1.2.0-Release),但是该bug修复只能基于历史的1.0.0修复,就需要基于该里程碑版本(tag)1.0.0-Release,创建一个release/1.0.1分支,和hotfix分支(如:hotfix/问题编号),开发人员基于该分支修复bug。

  2. 开发人员在bug修复后,向release/1.0.1分支提交 pull request 申请。

  3. 开发组长在确认bug修复完成后,通过该pull request 的合并请求。基于release/1.0.1分支创建一个里程碑修复版本(tag),名为1.0.1-Release。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容