Malize's blog Malize's blog
首页
  • 设计模式

    • 设计模式总览
    • 工作中用到的设计模式
  • 并发编程

    • 死锁
  • 技术文档

    • Docker 核心命令大全
    • Markdown 使用教程
    • npm 常用命令
    • yaml 语言教程
    • Nodejs 递归读文件
  • 构造问答系统

    • 项目背景
    • 构建答疑机器人
    • 扩展知识范围
    • 优化提示词
    • 自动化评测
    • 优化 RAG 应用
  • 构建 Agent 系统

    • Agent 基础与工具调用
    • 规划与执行
    • 多 Agent 团队协作
    • Memory 积累经验
    • Skill 可复用流程
    • Qwen Code 实践
  • 交付上线

    • 走向生产环境
    • 模型蒸馏
    • 部署模型
    • 生产实践
    • 安全合规
  • 工具手册

    • OpenClaw 命令速查
  • 规范 & 实践

    • 代码规范
    • sharding-jdbc
    • CIM 半导体行业
    • HTML 常用 meta
    • CSS 技巧收藏
  • 微服务

    • feign原理
  • Git

    • Git 笔记总览
    • Git 使用手册
    • Git 修改分支名
    • 团队 Git 分支规范
  • GitHub & 博客

    • GitHub 高级搜索技巧
    • GitHub Actions 自动部署
    • 博客搭建 - 百度收录
  • 优质网站
  • 前端库推荐
  • 成长学习

    • 学习方法
    • 敏捷开发实战
    • 提示词工程
  • 生活

    • 实用技巧
    • 心情杂货
    • 梦境与灵感
  • 技术问题

    • 面试问题备忘
  • 索引

    • 分类
    • 标签
    • 按年归档
GitHub (opens new window)

Malize

持续学习,持续成长
首页
  • 设计模式

    • 设计模式总览
    • 工作中用到的设计模式
  • 并发编程

    • 死锁
  • 技术文档

    • Docker 核心命令大全
    • Markdown 使用教程
    • npm 常用命令
    • yaml 语言教程
    • Nodejs 递归读文件
  • 构造问答系统

    • 项目背景
    • 构建答疑机器人
    • 扩展知识范围
    • 优化提示词
    • 自动化评测
    • 优化 RAG 应用
  • 构建 Agent 系统

    • Agent 基础与工具调用
    • 规划与执行
    • 多 Agent 团队协作
    • Memory 积累经验
    • Skill 可复用流程
    • Qwen Code 实践
  • 交付上线

    • 走向生产环境
    • 模型蒸馏
    • 部署模型
    • 生产实践
    • 安全合规
  • 工具手册

    • OpenClaw 命令速查
  • 规范 & 实践

    • 代码规范
    • sharding-jdbc
    • CIM 半导体行业
    • HTML 常用 meta
    • CSS 技巧收藏
  • 微服务

    • feign原理
  • Git

    • Git 笔记总览
    • Git 使用手册
    • Git 修改分支名
    • 团队 Git 分支规范
  • GitHub & 博客

    • GitHub 高级搜索技巧
    • GitHub Actions 自动部署
    • 博客搭建 - 百度收录
  • 优质网站
  • 前端库推荐
  • 成长学习

    • 学习方法
    • 敏捷开发实战
    • 提示词工程
  • 生活

    • 实用技巧
    • 心情杂货
    • 梦境与灵感
  • 技术问题

    • 面试问题备忘
  • 索引

    • 分类
    • 标签
    • 按年归档
GitHub (opens new window)
  • 技术文档

  • GitHub技巧

  • Nodejs

  • 博客搭建

  • CIM

  • 代码规范

  • 前端基础

  • 微服务

  • Git

    • 《Git》学习笔记
    • Git使用手册
    • Git修改分支名
    • 团队Git分支管理、迭代发布、分批投产标准化规范
    • 手册

    • 文档笔记

      • Git基础与命令
      • Git分支-分支原理
      • Git分支的新建与合并-分支操作
        • Git分支管理-查看分支
        • Git分支开发工作流
        • Git分支-远程分支
        • Git分支-变基
        • Git工具-查看修订版本
        • Git工具-交互式暂存
        • Git工具-重写历史
        • Git工具-重置揭密
    • 技术
    • Git
    • 文档笔记
    malize
    2020-11-18
    目录

    Git分支的新建与合并-分支操作

    # Git分支的新建与合并-分支操作

    文档:Git 分支 - 分支的新建与合并 (opens new window)

    # 创建分支并切换

    此时有一个需求需要在新的分支iss53上工作:

    $ git checkout -b iss53  # b表示branch
    
    1

    它是下面两条命令的简写:

    $ git branch iss53
    $ git checkout iss53
    
    1
    2

    # 切换分支

    突然有一个紧急问题要解决,需要在原来的master分支进行修复:

    $ git checkout master
    
    1

    在切换到master之前,需要iss53分支保持好一个干净的状态(修改都已提交)。

    注意:切换分支Git 会重置你的工作目录。

    checkout 中文含义 “检出”,checkout <branch> 检出分支 => 检出指定分支的代码 => 重置工作目录并切换分支。

    接下来,你要修复这个紧急问题。 建立一个 hotfix 分支,在该分支上工作直到问题解决:

    $ git checkout -b hotfix
    
    # 中间过程在hotfix上修改了代码并提交
    $ echo 'test' > ./hotfix.txt
    $ git add .
    $ git commit -m 'fixed'
    
    1
    2
    3
    4
    5
    6

    # 合并分支

    $ git checkout master # 首先切回master分支
    $ git merge hotfix # 把 hotfix 分支合并过来
    
    1
    2

    # 删除分支

    $ git branch -d hotfix # d表示delete
    
    # 然后切回iss53继续工作
    $ git checkout iss53
    
    1
    2
    3
    4

    注意删除分支是在 branch 命令上

    # 多次提交之后合并分支

    假设你已经修正了 #53 问题,打算合并到master分支:

    $ git checkout master
    $ git merga iss53
    
    1
    2

    这看似和之前的合并区别不大。此时你的开发历史从一个更早的地方开始分叉开来(diverged)。 因为,master 分支所在提交并不是 iss53 分支所在提交的直接祖先,Git 不得不做一些额外的工作。 出现这种情况的时候,Git 会使用两个分支的末端所指的快照以及这两个分支的公共祖先,做一个简单的三方合并。

    和之前将分支指针向前推进所不同的是,Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交,它的特别之处在于他有不止一个父提交。

    # 遇到冲突时的分支合并

    如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git 就没法干净的合并它们,就产生了冲突。

    合并过程中出现CONFLICT提升,表示有冲突

    $ git merge iss53
    Auto-merging index.html
    CONFLICT (content): Merge conflict in index.html
    Automatic merge failed; fix conflicts and then commit the result.
    
    1
    2
    3
    4

    使用git status查看未合并状态。

    任何因包含合并冲突而有待解决的文件,都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记,这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段,看起来像下面这个样子:

    <<<<<<< HEAD:index.html
    <div id="footer">contact : email.support@github.com</div>
    =======
    <div id="footer">
     please contact us at support@github.com
    </div>
    >>>>>>> iss53:index.html
    
    1
    2
    3
    4
    5
    6
    7

    你需要手动解决冲突,解决了所有文件里的冲突之后,对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件,Git 就会将它们标记为冲突已解决。

    如果你对结果感到满意,并且确定之前有冲突的的文件都已经暂存了,这时你可以输入 git commit 来完成合并提交。

    编辑 (opens new window)
    #Git
    Git分支-分支原理
    Git分支管理-查看分支

    ← Git分支-分支原理 Git分支管理-查看分支→

    最近更新
    01
    feign原理
    07-15
    02
    团队Git分支管理、迭代发布、分批投产标准化规范
    07-15
    03
    面试问题备忘
    07-07
    更多文章>
    Theme by Vdoing | Copyright © 2023-2026 Malize | GitHub | 桂ICP备2024034950号 | 桂公网安备45142202000030
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式