Git工作流

这篇具有很好参考价值的文章主要介绍了Git工作流。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

实际开发项目使用到的分支:

main:生产环境,也就是你们在网上可以下载到的版本,是经过了很多轮测试得到的稳定版本。
release: 开发内部发版,也就是测试环境。
dev:所有的feature都要从dev上checkout。
feature:每个需求新创建的分支。
下面介绍一下一个新需求过来的git操作流程:
1.从dev分支上checkout -b new-feature,进行开发
2.开发完后,经过自测没问题了,准备发版
3.merge到release分支上进行发版,并打tag
4.有bug就直接在release上进行修改,改完再次发版,打tag,直到测试人员验证完毕
5.这时可以将release分支合并到dev上,也可以删除掉feature分支了,并等待通知是否将此功能上线(发布正式版本,也就是在正式服务器上运行),如果上线,那就merge到main(master)分支,当然了有可能需要将ip改为生产服务器的地址,并打上一个official tag。
6.如果上线后,发现有bug,如果此时main分支已经又合并上新功能B了,但是这个临时的版本又不想包含B的功能,那么可以切换到上次的official tag,checkout -b一个hotfix分支进行bug修复,hotfix分支要进行保留,不能删除。测试没问题就可以发版了,最后可以合并到main上。
一般的项目这套流程应该就足够了。所有的发版tag都会集中到release,main,hotfix分支上,所有的需求都会从dev上拉取,这样能保证代码是完整可用的,是经过每次release合并过来的

指令及其含义

  • git checkout -b xxx:git checkout xxx是指切换到xxx(用local区的xxx替换disk区文件),-b意味着branch,即创建新分支,这条指令合起来意思是创建并切换到xxx。
  • git diff:查看暂存区与disk区文件的差异。
  • git add xxx:将xxx文件添加到暂存区。
  • git commit:将暂存区内容添加到local区的当前分支中。
  • git push :将local区的LocalBranchName分支推送到RemoteHostName主机的同名分支。(若加-f表示无视本地与远程分支的差异强行push)
  • git pull :同上,不过改成从远程主机下载远程分支并与本地同名分支合并。
  • git rebase xxx:假设当前分支与xxx分支存在共同部分common,该指令用xxx分支包括common在内的整体替换当前分支的common部分(原先xxx分支内容为common->diversityA,当前分支内容为common->diversityB,执行完该指令后当前分支内容为common->diversityA->diversityB)。
  • git branch -D xxx:不加-D表示创建新local分支xxx,加-D表示强制删除local分支xxx。

工作流一:

Git工作流,Git(xx-xuxin),git

  1. git clone remote// 到本地
  2. git checkout -b feature 切换至新分支feature ,没有就创建
  3. 修改或者添加本地代码(部署在硬盘的源文件上)
  4. git diff 查看自己对代码做出的改变
  5. git add 上传更新后的代码至暂存区
  6. git commit 可以将暂存区里更新后的代码更新到本地git
  7. git push origin feature将本地的feature分支上传至github上的git

如果在写自己的代码过程中发现远端GitHub上master分支代码出现改变

  1. git checkout master切换回master分支
  2. git pull origin master将远端修改过的代码再更新到本地
  3. git checkout feature回到feature分支
  4. git rebase master把我的修改先都放在一边,然后把master最新的修改拿过来,接着在这个最新修改的基础之上,再把我的commit尝试弄回去,中途可能会出现rebase conflict手动选择保留哪段代码,就相当于我们在最新的master分支上做了修改 ,这也是使用rebase而不是使用merge的好处
  5. git push -f origin feature把rebase后并且更新过的代码再push到远端github上,由于做了rebase所以需要加上-f ,-f表示强行,强行push
  6. 把更新的代码合并到远程master分支里面,pull request的意思是request项目的主人把我这个新的分支的改变给pull到这个项目里去。原项目主人采用pull request 中的 squash and merge 合并所有不同的commit

远端完成更新后

  1. github删除个人远程分支feature
  2. 本地切换到主分支git checkout master && git branch -d feature删除本地的git分支
  3. git pull origin master 再把远端的最新代码拉至本地,这时我们的本地仓库就又和远程一样了。

工作流二:

远程仓库有两个master和test分支

  1. git clone remote克隆仓库
  2. git checkout -b feature切换分支,没有就会新创建并切换
  3. 编写代码并提交本地仓库
  4. 推送到远程test分支
  5. git checkout -b test origin/test意思是切换一个分支,如果分支不存在就会创建并切换到test分支,后面origin/test是指从远程test克隆下来,并与本地test分支建立联系,这时,文件里没有新编写的代码。
  6. 切换到feature分支使用git log查看提交历史记录,记录以前提交的哈希值
  7. 切换到test分支,使用git cherry-pick 哈希值,这时代码就同步过来了,可以再次使用git log查看。
  8. git push到远程test分支
  9. 同步到远程master分支,如果此时远程master分支有更新,需要切换到master分支使用git pull保证本地master分支是最新的,然后使用git cherry-pick 哈希值,这时代码就同步过来了,可以再次使用git log查看,再push到远程分支。

工作流三: git pull(本地push之前先执行pull,拉取最新代码,解决冲突防止覆盖他人最新提交的代码)

  1. 本地修改代码,远程也更新代码,产生冲突
  2. 使用git pull后需要手动merge
  3. git add .
  4. git commit -m “合并冲突”
  5. git push
  6. git log --graph
    Git工作流,Git(xx-xuxin),git

缺点:提交记录出现分叉,出现很多奇怪的提交记录。

工作流四: git pull --rebase优化提交记录

现象:提交记录出现分叉,出现很多奇怪的提交记录。

业务场景:

在本地分支完成了我功能的开发,现在需要合并到test 分支上,于是我的目标是在test 分支上执行git cherry-pick操作将我的代码检出到test上,因为我要避免有人更新过test分支,所以我在此之前先执行了一下git pull ,出现了一个Merge的vi窗口(过去我一直没注意, 直接就wq出去
.了),其实这个就是导火索! vi窗口如下:
Git工作流,Git(xx-xuxin),git

原因

git pull 其实是一个组合操作,其会执行git fetch + git merge (过去其实完全不知道) , 因为
有git merge的存在,所以最后的提交记录看起来就会很乱。

解决方案

使用git pull --rebase 来进行合并本地和远程分支。既可以完美解决这个问题!
git pull --rebase 也是一个组合操作, 其会执行git fetch + git rebase ,我们知道git rebase 就
是解决凌乱记录的一个大杀器,所以可以完美的解决!

  1. 本地修改代码,远程也更新代码,产生冲突
  2. 使用git pull --rebase origin test需要手动处理冲突
    Git工作流,Git(xx-xuxin),git
    current change变为了远程,意味着更新版本是以远程为基础的大的提交,不会是含有本地每次小的提交。
  3. git add .
  4. git rebase --continue
  5. wq即可
  6. git push
  7. git log --graph
    Git工作流,Git(xx-xuxin),git
    这样操作之后我们的提交记录就是非常干净的一条链路了!
    Git工作流,Git(xx-xuxin),git
    补充:
git log --graph

更加清晰的结构查看log记录。文章来源地址https://www.toymoban.com/news/detail-690893.html

到了这里,关于Git工作流的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 一步到位!快速精通Git工作流及实战技巧详解

    Git是一个分布式版本控制系统。 1.备份 小明负责的模块就要完成了,就在即将release之前的一瞬间,电脑突然蓝屏。硬盘光荣牺牲!几个月来的努力付之东流。 场景二:代码还原 这个项目中需要一个很复杂的功能,老王摸索了一个星期终于有眉目了,可是这被改得面目全非的

    2024年03月15日
    浏览(45)
  • Git之GitFlow工作流 | Gitflow Workflow(万字整理,已是最详)

    目录 🩸 写在前面 一、 GitFlow 介绍 1.1 什么是 GitFlow 1.2 GitFlow 常用分支说明 1.3 Git flow中的分支介绍 1.3.1 主要分支(Master) 1.3.2 开发分支(Develop) 1.3.3 功能分支(Feature) 1.3.4 预发分支(Release) 1.3.5 热修复分支(Hotfix) 1.4 GitFlow 工作流程 二、GitFlow 实践 2.1 创建 develop 分支

    2024年02月17日
    浏览(27)
  • github使用workflow工作流git push后自动打包部署github pages

    根目录新建.github/workflows/docs.yml .github/workflows/ 目录是用于存放 GitHub Actions 工作流程文件的目录,该目录的文件名必须以 .yml 或 .yaml 为后缀名,否则 GitHub 将无法识别该文件为工作流程文件。这些工作流程文件可用于自动化执行项目中的各种任务,例如构建、测试、部署等。

    2024年02月10日
    浏览(41)
  • 【工作流】Activiti工作流简介以及Spring Boot 集成 Activiti7

    什么是工作流? 工作流指通过计算机对业务流程进行自动化管理,实现多个参与者按照预定义的流程去自动执行业务流程。 文章源码托管:https://github.com/OUYANGSIHAI/Activiti-learninig Activiti5是由Alfresco软件在2010年5月17日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理、

    2024年02月08日
    浏览(38)
  • 云原生离线工作流编排利器 -- 分布式工作流 Argo 集群

    作者:庄宇 在现代的软件开发和数据处理领域,批处理作业(Batch)扮演着重要的角色。它们通常用于数据处理,仿真计算,科学计算等领域,往往需要大规模的计算资源。随着云计算的兴起,阿里云批量计算和 AWS Batch 等云服务提供了管理和运行这些批处理作业的平台。 随

    2024年01月24日
    浏览(64)
  • Camunda 7工作流引擎 API 以及与Springboot集成实现工作流配置全纪录

    项目中需要用到工作流引擎来设计部分业务流程,框架选型最终选择了 Camunda7,关于 Camunda以及 Activity 等其他工作流 引擎的介绍及对比不再介绍,这里只介绍与现有Springboot项目的集成以及具体使用及配置 流程(PROCESS): 通过工具建模最终生成的BPMN文件,里面有整个流程的定

    2024年02月10日
    浏览(40)
  • Activity工作流引擎

    目录 一、了解工作流 1、什么是工作流 2、工作流引擎 3、常见工作流引擎 4、Activiti7概述 4.1、Activiti介绍 4.2、建模语言BPMN 4.3、Activiti使用流程 二、Activiti7 1、Activiti使用 1.1、数据库支持 1.2、Activiti环境 1.3、Activiti常用Service服务接口 1.4、流程设计工具 2、Activiti流程操作 2.1、

    2024年02月13日
    浏览(29)
  • Activiti 工作流简介

    1、什么是工作流         工作流(Workflow),就是通过计算机对业务流程自动化执行管理。它主要解决的是“使在多个参与者之间按照某种预定义的规则自动进行传递文档、信息或任务的过程,从而实现某个预期的业务目标,或者促使此目标的实现”。 1.2、工作流系统   

    2024年02月04日
    浏览(38)
  • 工作流引擎Flowable

    官方手册 一、依赖 二、demo 三、日志文件 在resources中添加日志文件log4j.properties Flowable流程图 Eclipse Designer, 一款Eclipse插件, 用于图形化建模, 测试与部署BPMN2.0流程 FlowableUI Flowable BPMN visualizer, 一款idea插件 从官网下载flowable-6.7.2.zip解压后, 可以看到如下两个文件 将这两个文件

    2024年02月09日
    浏览(38)
  • Docker工作流

    开发应用 编写Dockerfile 构建Docker镜像 运行Docker容器 测试应用 发布镜像到Hub 迭代更新镜像 首先你需要创建一个应用,这个应用可以是后端应用或者前端应用,任何语言都可以。 比如:我使用IDEA 创建一个Java后端应用,基于Maven构建,工程结构如下: 基于自己的工程来编写

    2024年04月29日
    浏览(25)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包