常规的Git管理流程

一、前言

Git是目前流行的版本管理工具,大家应该都使用过。虽然Git能为我们的项目管理提供极大的帮助,但是如果使用不当也会造成一些不必要的麻烦,特别是在多人协作的情况下。本文将讲述我们在项目开发中使用的常规Git管理流程。

欢迎大家关注微信公众号:码途有道

二、Git常规管理流程

1、常用的开发分支

  • master 分支 : 主分支,不轻易改动,主要做正式发版使用,一般发版的包都从 master 分支中构建
  • pre-release 分支 : 预发布分支,是在正式发版前的测试使用分支,测试使用的包都从此处构建,测试完成后合并到 master 分支进行发版
  • developer 分支 : 开发分支,每个版本的所有需求开发所在分支
  • feature 分支 : 具体的需求开发分支,因为开发大都是团队协作,开发成员负责自己的需求开发时,一般建议从 developer 分支中重新拉一条分支出来,作为成员自己的开发分支,最后再合并到 developer 分支中,所以 feature 分支一般会有多个
  • hotfix 分支 : 紧急修复分支,如果线上版本遇到bug,则一般建议从 master 分支拉出一条分支,作为紧急修复分支,在 hotfix 测试没有问题后,合并到 master 进行紧急发版

2、常用的Git管理流程

从上述常用分支介绍中,我们可以大致了解团队开发时的Git管理流程,此处我们再详细介绍一下常用的管理流程。

Step 1 : 项目创建 master 分支。
Step 2 : 从 master 分支中拉出一条 developer 分支,作为所有的开发需求的汇总分支。
Step 3 : 进行具体的需求开发时,每位开发成员从 developer 分支中拉出一条分支,作为自己的 feature 分支进行具体的需求开发。
Step 4 : 开发完成后的 feature 合并到 developer。
Step 5 : 所有的需求都开发完成后,从 developer 分支中拉出一条 pre-release 分支,提供给 QA 进行测试。不过,有时为了效率,pre-release 分支可能会被省略,直接使用 developer 分支代替。但是如果项目开发时会出现交叉开发,那么个人认为 pre-release 分支的存在还是很重要的。例如本期版本需求还未测试完毕,进行发版,下一期需求就要进行开发,则此时 developer 分支中可能就会混入下期需求代码,那么 pre-release 分支的存在就很有必要了。
Step 6 : 测试完成后,pre-release 分支合并到 master 分支进行发版,并且每次发版都需要打标签,方便后续对历史版本复盘。
Step 7 : 如果线上版本出现紧急bug,则从 master 分支拉出一条 hotfix 分支,对 bug 进行紧急修复,测试完成后将 hotfix 分支合并到 master 进行紧急发版,同时也需合并到 developer 分支。

PS : 所有的远程分支合并,个人建议最好通过 Pull Request (即PR) 来进行。 例如我们要将自己的 feature 分支合并到远程的 developer 分支,可以首先创建一个 PR,然后让其他成员简单的 review 代码的改动,其他同事 approve 后再合并到 developer。使用此种方式,能更有效的追踪代码的改动。

三、必须知道的Git常识

1、Git小常识

Git的三个区域
  • 工作区 : 当前的工作区域
  • 暂存区 :git add 后的文件所在区域
  • 历史记录区 : 已提交历史,git commit 后的提交文件所在区域
Git的三种状态
  • 已修改 (modified) : 表示修改了文件,但还没保存到本地仓库中
  • 已暂存 (staged) : 表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的暂存区中
  • 已提交 (committed) : 表示数据已经安全地保存在本地仓库中

2、Git基本命令

git init : 初始化仓库

在当前目录创建一个Git仓库,如果需要在指定目录创建可以使用 git init [目录]

git add : 添加文件到暂存区
  • git add [file1] [file2] … : 将指定文件添加到暂存区。
  • git add [dir] : 将指定目录添加到暂存区。
  • git add . : Git 1.x版本时,将新文件 (new) 和被修改 (modified) 文件添加到暂存区,不包括被删除 (deleted) 文件;在Git 2.x版本时,被删除文件也会被添加到暂存区域。
  • git add -u (git add --update的缩写) : 将被修改 (modified) 和被删除 (deleted) 文件添加到暂存区,不包括新文件 (new)。
  • git add -A (git add --all的缩写): 提交所有变化,是 add .add -u 的合集。
git commit : 将暂存区内容提交到本地仓库中
  • git commit -m [message] : 将暂存区内容提交到本地仓库中,message 是本次提交的描述信息
  • git commit [file1] [file2] … -m [message] : 将指定文件提交到本地仓库中
  • git commit -a : -a 参数设置修改文件后不需要执行 git add 命令,直接来提交
  • git commit -am [message] : -a 参数设置修改文件后不需要执行 git add 命令,直接来提交
git reset : 版本回退

git reset 的常用命令格式:git reset [–mixed | --soft | --hard | --merge | --keep] [HEAD],默认是**–mixed**。

  • HEAD 说明
    HEAD 是当前分支版本顶端的别名,指向我们在当前分支的最近一次提交。例如下面一共进行了A、B、C三次提交,则 HEAD 指向 C
[commit A]--->[commit B]--->[commit C]                      
  • 三种常用模式
  1. –mixed : HEAD 指向指定 commit,暂存区回退到指定 commit 版本,工作区不变。
[commit A]--->[commit B]--->[commit C]---->[commit D]

小例子:看上述例子,共有 A、B、C、D 四个 commit,D 是最近一次提交,则 HEAD 指向 D。此时使用 git reset --mixed [commit B] 进行版本回退,则 HEAD 指向 B,暂存区回退到 B 版本,而 C、D 的 commit 内容会被回撤到工作区(即未被 git add 的状态)。

  1. –soft : HEAD 指向指定 commit,指定 commit 及之后的 commit 的内容被回撤到暂存区,工作区保持不变。

小例子:还是看上述例子,共有 A、B、C、D 四个 commit,D 是最近一次提交,则 HEAD 指向 D。此时使用 git reset --soft [commit B] 进行版本回退,则 HEAD 指向 B,而 C、D 提交的内容则回撤到暂存区中(即已 git add 但未 git commit 状态), C、D 的 commit 记录会被擦除,工作区中的内容不会发生改变。

  1. –hard : 重置暂存区与工作区,回退到指定的 commit 版本。

小例子:还是看上述例子,共有 A、B、C、D 四个 commit,D 是最近一次提交,则 HEAD 指向 D。此时使用 git reset --hard [commit B] 进行版本回退,则 HEAD 指向 B,暂存区回退到 B 版本,工作区回退到 B 版本, C、D 的 commit 内容被丢弃。

另外还有 –keep–merge 两种模式,但是不常用,此处不就不再详述。

常见使用
HEADHEAD~0 表示当前版本
HEAD^HEAD~1 表示上一个版本
HEAD^^HEAD~2 表示上上个版本
HEAD^^^HEAD~3 表示上上上个版本
以此类推…

git reset [模式] HEAD~1,表示回退到上个版本,或者我们也可以使用 git reset [模式] [commit id] 来回退到指定的 commit 版本。

3、Git分支管理

  • git branch [branchname] : 以当前分支为模板,创建新分支
  • git branch -d [branchname] : 删除指定分支
  • git checkout [branchname] : 切换到指定分支我一
  • git checkout -b [branchname] : 创建分支,切换到该分支
  • git merge [branchname] : 将指定分支合并到当前分支
  • git merge --no-ff [branchname] : 关闭 fast-forward 模式,将指定分支合并到当前分支,与 git merge [branchname] 的区别是 git merge --no-ff [branchname] 合并时会创建一个 merge 的 commit,保留原来的分支 commit 历史,一般推荐使用此种合并方式
master分支:[master-commit1]--->[master-commit2]
hotfix分支:[hotfix-commit3]--->[hotfix-commit4]

小例子:如上所示,当前我们在 master 分支,共进行了两次 commit;此外还有一个以 master 分支为模板创建的 hotfix 分支,共进行了两次 commit。

方式一: 我们使用 git merge hotfix 合并 hotfix 到 master 分支上,此时 hotfix 的 commit 记录会完全合并到 master 分支上,那么 master 分支上的 commit 记录为 [master-commit1]—>[master-commit2]—>[hotfix-commit3]—>[hotfix-commit4],如下图左侧的图,master 的分支历史被扰乱。这时我们使用 git reset --hard HEAD^ 进行版本回退,则 master 会回退到 hotfix-commit3 版本。

方式二: 我们使用 git merge --no-ff hotfix 合并 hotfix 到 master 分支上,master 分支的 commit 历史会被保留,如下图右侧图。此时使用 git reset --hard HEAD^ 进行版本回退,则 master 会回退到 master-commit2

git merge 的不同

4、Git远程管理

  • git clone [url] : 克隆项目
  • git pull [远程主机名] [远程分支名]:[本地分支名] : 拉取指定远程分支与本地分支合并

小例子:

  1. git pull origin master:test 将远程的 master 分支拉下来与本地的 test 分支合并
  2. git pull origin master 如果是将远程分支与当前分支合并,则可以省略本地分支名,这里的意思是将远程的 master 分支与本地分支合并
  • git push [远程主机名] [本地分支名]:[远程分支名] : 推送指定本地分支到远程并合并,如果远程分支不存在,则会创建远程分支

小例子:

  1. git push origin test:master 将本地的 test 分支推送到远程 master 分支并合并;如果远程 master 分支不存在,则会在远程创建一个 master 分支
  2. git push origin mater 如果本地分支名与远程分支名相同,则可以省略远程分支名
  • git push origin --delete [远程分支名] : 删除指定的远程分支
  • git tag -l : 显示已有标签
  • git tag [tagname] : 创建标签
  • git push origin [tagname] : 将本地标签推送到远程

如果本文对你有帮助,就关注一下微信公众号:码途有道

微信公众号

  • 2
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值