【Git】git rebase+fix conflict+git add+git rebase --continue或git merge+fix conflict+git add+git commit

最新推荐文章于 2024-06-27 23:34:07 发布
原创 最新推荐文章于 2024-06-27 23:34:07 发布 · 876 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

博客围绕Git操作展开，介绍了git rebase和git merge过程中遇到冲突时的处理方法，包括使用git add添加修改，以及通过git rebase --continue或git commit完成操作，属于信息技术中版本控制相关内容。
            
【Git系列】git rebase和git merge用法详解
优快云明星博主，认证博客专家，视频、Matlab领域优质创作者。
12-31 1410
DATE: 2020.12.28 文章目录1、参考2、git-rebase的命令格式3、git-rebase用法4、git rebase冲突解决5、git rebase与git merge的区别 1、参考 git rebase命令 【Git】rebase 用法小结 2、git-rebase的命令格式 git rebase [-i | --interactive] [options] [--onto ] [] git rebase [-i | --interactive] [options] --ont
git-rebase进阶使用
xiaojiangkf的博客
07-30 3052
git rebase进阶使用 推荐书籍: 《git pro》 推荐教程: atlassian 本地获取帮助: git help <command> rebase最强大的地方在于可以按需移动提交并对其进行编辑更改，当然前提是在个人分支上 最好对git中的一些概念预先有一定的了解 再次强调：git rebase相关命令只允许在个人分支上使用 目录： 本文alias说...
Git的提交说明规范
星图
09-07 1638
好的提交规范，有助于作业者回顾前面工作内容，方便自己和他人查阅代码记录，也是个人职业形象的延伸。 提交代码时，说明文字应包括三个部分：header，body 和 footer。 <type>(<scope>): <subject> //记得空1行 <body> //记得空1行 <footer> 其中type和subject为必须，body和footer可以省略。 feat或add：新功能 update: 更新 fix：修复的缺陷 docs
Git实战（五）| 让工作更高效，Git的分支管理
软件测试小迷糊
04-14 216
上一篇讲到Git的分支管理实操，在线合并和本地合并都进行了实操。毕竟：光说不练是假把式。而只练不整理，只能是傻把式了。分支管理到底如何进行管理呢？ 先以GitLab上的一张经典的图打头，作为一个总体概览，也方便理解分支的管理和走向： 现假设公司有名为Hogwarts_Online2的开发项目，其中包含了上线分支master，开发分支develop，测试分支release，和个人开发的特性分支 1.1）与远程仓库建立连接，在本地创建自己的分支，并拉取develop分支的文件： 1.2）在当前分支中创建新的文件
再不学Git就晚啦，一篇文章让你学会Git
别下完这场雪
07-11 436
很早之前就听说过Git和Github，但是并没有很放在心上，觉得可能不是很重要，而且英文的界面让我直接劝退。心想等着以后需要的时候再学习应该也不晚，随着了解知识的增加，现在越来越觉得Git和Github的重要性。工欲善其事必先利其器，Git，Maven登工具就是我们的“器”，用的好可以起到事半功倍的效果。 简介 Git历史 git是目前世界上最先进的分布式版本控制系统。 提到Git，就不得不提起Linux。 Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统
git基础命令（小白适合看）
m0_65683419的博客
12-18 669
9.我还遇到情况就是，如果没改好的代码，已经将补丁提交到本地，但是没提交到服务器的情况。type(修改的文件名，无需加后缀，如果是多个的话，可以写上一级的文件夹名称）：什么用户解决了什么问题，添加了什么功能，修改了什么bug等。或者直接打开补丁看看。这个xx就是生成的补丁名字，自己取的，当然还是要详细点比较好，就可以生成补丁，可以在目录找。就比如git add xx/xx/xx.x，记得加后缀，然后如果是几个文件，就加空格。而且有可能遇到补丁里面有很多内容，特别多，又没用的信息，也是我操作遇到的问题。
项目中的 Git 使用规范
12-03 329
0. 我们可能面临的问题 试想遇到以下这些问题，你会采取怎样的方式去解决： 需要线上某个历史版本的源码，直接在 develop 分支根据提交记录和时间找对应的节点？ 线上版本出现严重 bug 需要紧急修复发版本，而你的项目就一个分支，上个版本发布之后已经有大量改动了，怎么办？ 某个提交改动了部分代码，涉及到 10 几个文件，现在这个改动不需要了，此时要一个个找出这些文件然后再改回去么？ 出现了一个 bug，之前好像处理过，但是现在忘了当初怎么处理的了，在一堆写着 “fix bug”、“update
Git - Rebase命令介绍
guoqx的专栏
06-05 1136
Git rebase 是版本控制系统 Git 中一个功能强大、使用广泛的命令。它用于将一个分支中的改动整合到另一个分支中。rebase与merge不同， merge会创建一个新的提交，而rebase则是将一系列提交移动或合并到一个新的基础提交中。
Git实战（3）之merge与rebase区别
thinkers
03-03 764
4，如果在使用rebase过程中不小心进行了commit操作导致最后git rebase --continue完后git push时仍然存在未push的老代码，此时有一种简单处理方式：删掉该本地分支，重新创建一个即可。git pull做了两个操作分别是‘获取’和合并。所以加了rebase就是以rebase的方式进行合并分支，默认为merge。1，采用merge和rebase后，git log的区别，merge命令不会保留merge的分支的commit。
Git：Pull【git pull=git fetch+git merge】（将远端仓库的所有代码覆盖本地仓库，每次修改代码前进行）
u013250861的博客
06-27 1149
【代码】Git：Pull【git pull】【git fetch】【git merge】
git的突出解决--git rebase之abort、continue、skip
weixin_33809981的博客
05-18 2740
（1）应用实例描述 假设在github或者gitoschina上建立了一个项目，默认分支为master分支，远程master分支上c.sh文件内容： 开发者A、B分别将项目拷贝到自己本地进行开发 某一天，开发者B提交c.sh，并且提交成功， 之后，开发者A在本地代码并没有和远程master分支的代码同步的情况下，对本地的c.sh进行了修改，修改后c.sh内容如下： ...
git reset（回退add操作）
热门推荐
yaoming168的专栏
08-23 9万+
在git的一般使用中，如果发现错误的将不想提交的文件add进入index之后，想回退取消，则可以使用命令：git reset HEAD ...，同时git add完毕之后，git也会做相应的提示，比如： 引用   # Changes to be committed:  #   (use "git reset HEAD..." to unstage)  #  # new file:
git fix conflict git解决冲突（一）
small fish鱼果果
12-25 2694
因为这个解决冲突的命令，自己总也记不住，为了不再每次上网搜索，写在自己的博客里，接下来，我会利用闲暇时间，将自己的web前端工作获取的知识进行整理，输出，希望可以帮到更多的web前端从业人员 git pull 代码时会遇到冲突，conflict需要fix conflict 1.解决冲突后，git add 冲突文件 2.git commit -m "添加注释" 3.git merge 4.git status /*查看下本地更改了哪些文件*/ 5.git push /*提交修改到远端仓库*/ 注意，里面的
git提交规范，规范自己的提交标准
weixin_44292923的博客
04-22 1万+
为了规范我的git提交内容，提交的时候commit -m “备注的信息”，但是每个人的备注信息千奇百怪，为了统一，我们进行了git的规范。 首先要全局安装commitizen npm i -g commitizen@4.2.4 然后安装插件 npm i cz-customizable@6.3.0 --save-dev 在package.json中添加代码 "config": { "commitizen": { "path": "node_modules/cz-customizable
git rebase -i 中edit和fixup的简单使用
not_say的博客
08-29 1万+
一、edit的使用 1、当在某个分支上面存在多个commit，但是又必须在之前的commit进行修改的时候，可以使用edit来对旧的commit进行修改。 将改动分别提交为两个commit 两次commit的test文件分别是这样子的： 2、使用git log查看commit 历史日志信息 红色线标注的两个commit是刚刚提交的，蓝色线标注的是此分支依赖的分支的最近的...
git 命令提交代码的个人经验
popstarqq的博客
04-14 162
1、git add -A,如果有新增文件，则先执行这一步，意思是保存到暂存区stage 2、git commit -m '随意写个提交信息' ，将暂存区内容提交到本地仓库，则stage中无内容 3、git fetch 拉去远程仓库的内容下来 4、git merge 看是否有冲突 5、修改冲突，继续执行1/2/3/4 ...
git add 和git_git技巧和窍门，以改善您的git工作流程
weixin_26720753的博客
09-01 714
git add 和git.gitkeep，GIT跳转，GIT日志，GIT存放，差异化(.gitkeep, GIT Jump, GIT Log, GIT Stash, diff-so-fancy) The Git system is a powerful tool for tracking source code changes. Commonly used by developers and pr...
Git-rebase 黑魔法之打磨 commit 颗粒度
浅浅同学的开发笔记
03-07 5461
又是一个 rebase 黑魔法篇 写在前面 今天的主题是 rebase 的第二个黑魔法-交互式 rebase,与 rebase 用做两个分支见的遍及合并不同，交互式一般用于同一个分支中的提交整理。从命令上看，两者是 rebase 和 rebase -i的区别。 需要特别说明的是，rebase -i的 GET 也会让你的帅气值+10～ rebase -i 开启黑暗世界 reba...
git的提交突出--git rebase之abort、continue、skip
weixin_39570093的博客
11-06 2155
git的提交突出–git rebase之abort、continue、skip http://www.mamicode.com/info-detail-1812492.html （1）应用实例描述 假设在github或者gitoschina上建立了一个项目，默认分支为master分支，远程master分支上c.sh文件内容： 开发者A、B分别将项目拷贝到自己本地进行开发 某一天，开发者B提交c....
Git pull与git pull --rebase
最新发布
11-15
<think> 我们参考了引用[1][2][3]的内容，用户询问的是git pull和git pull --rebase的区别。根据引用内容，我们可以总结如下： 1. **本质区别**： - `git pull` = `git fetch` + `git merge` - `git pull --rebase` = `git fetch` + `git rebase` 2. **合并方式**： - `git pull`：使用合并（merge）方式，可能会产生一个合并提交（Merge Commit）。 - `git pull --rebase`：使用变基（rebase）方式，将本地提交重新应用到拉取的最新代码之上，形成线性历史。 3. **提交历史**： - `git pull`：可能产生分叉和合并点，保留完整的历史记录。 - `git pull --rebase`：保持线性历史，没有额外的合并提交，历史更加清晰。 4. **冲突处理**： - `git pull`：在合并时一次性解决所有冲突（只需要解决一次冲突）。 - `git pull --rebase`：在重新应用每一个提交时都可能遇到冲突，需要逐个提交解决冲突。 5. **适用场景**： - `git pull`：适用于公共分支（如main/master）或者需要保留完整合并历史的场景。 - `git pull --rebase`：适用于个人分支或者追求线性历史的项目，尤其是在协作简单的情况下。但要注意，如果本地提交已经推送到远程，则不应该使用`git pull --rebase`，因为会重写历史，可能导致协作问题。 6. **注意事项**： - 使用`git pull --rebase`时，如果本地有未推送的提交，变基操作会改变这些提交的哈希值（重写历史）。因此，如果这些提交已经推送到远程仓库，再次推送时需要强制推送（force push），这可能会给其他协作者带来问题。 下面我们用一个例子来说明： 假设远程仓库的main分支上有两个提交：A -> B 你基于提交B创建了本地提交C和D，此时你的本地历史为：A -> B -> C -> D 同时，远程仓库的main分支已经更新了提交E（即远程历史为：A -> B -> E） - 执行`git pull`（即merge方式）： 会生成一个新的合并提交F，将远程的提交E和本地的提交C、D合并。历史变为： ``` A -> B -> C -> D \ / E -> F ``` 实际上，提交F有两个父节点：D和E。 - 执行`git pull --rebase`： 它会将本地的提交C和D重新应用到远程最新的提交E之后，形成新的提交C'和D'（哈希值改变）。历史变为： ``` A -> B -> E -> C' -> D' ``` 因此，如果你希望保持线性历史，使用`git pull --rebase`更合适；如果你想保留完整的分支合并信息，则使用`git pull`。 最后，引用[3]特别提醒：如果本地提交已经推送到远程，使用`git pull --rebase`需要谨慎，因为它会重写历史。在这种情况下，如果必须使用，那么在推送时需要使用`git push --force-with-lease`（或`git push -f`）来覆盖远程历史，但这可能会影响其他协作者。 §§相关问题§§ 1. 为什么 git pull --rebase 会改变提交的哈希值？ 2. 如何设置默认使用 git pull --rebase？ 3. 在团队项目中，使用 git pull --rebase 有哪些注意事项？ 4. 解决 git pull --rebase 冲突的具体步骤是什么？ </think> ### Git Pull vs Git Pull --rebase 核心区别 以下是两者的关键差异对比（基于引用内容[^1][^2][^3]）： | **对比维度** | `git pull` (默认) | `git pull --rebase` | |--------------------|---------------------------------------|-----------------------------------------| | **本质操作** | `git fetch` + `git merge` | `git fetch` + `git rebase` | | **提交历史** | 生成合并提交（Merge Commit） | 线性历史（无额外合并节点） | | **历史结构** | 可能产生分叉（树状结构） | 保持直线型历史 | | **冲突处理** | 一次性解决所有冲突 | 每个提交单独解决冲突 | | **提交哈希值** | 本地提交哈希值不变 | 本地提交生成新哈希值（历史重写） | | **适用场景** | 公共分支（如 main/master） | 个人/私有分支 | | **安全性** | 安全（不重写已推送历史） | 高风险（会重写历史） | --- ### 详细原理说明 #### 1. **工作流程差异** - **`git pull`**（默认合并方式）： ```bash # 等效操作： git fetch origin # 获取远程更新 git merge FETCH_HEAD # 合并到当前分支（生成合并提交）[^2] ``` ![merge](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=1504) - **`git pull --rebase`**： ```bash # 等效操作： git fetch origin # 获取远程更新 git rebase FETCH_HEAD # 将本地提交重放到远程更新之后[^2][^3] ``` ![rebase](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=1504) #### 2. **提交历史对比** **初始状态**（远程有更新，本地有新提交）： ``` 远程： A - B - E (origin/main) 本地： A - B - C - D (main) ``` **执行 `git pull` 后**： ``` C - D / \ A - B - E - - - M (合并提交) ``` **执行 `git pull --rebase` 后**： ``` A - B - E - C' - D' （线性历史） ``` > ⚠️ **关键变化**： > - `C'` 和 `D'` 是重写后的新提交（哈希值改变） > - 原始提交 `C` 和 `D` 被丢弃[^1][^3] --- ### 适用场景建议 | **场景** | **推荐命令** | **原因** | |-------------------------|----------------------|----------------------------------------| | 公共分支协作 | `git pull` | 保留完整历史，避免重写他人依赖的提交 | | 个人分支整理 | `git pull --rebase` | 获得清晰线性历史 | | 已推送的提交 | `git pull` | 禁止重写公共历史[^3] | | 未推送的本地提交 | `git pull --rebase` | 安全整理本地历史 | --- ### 冲突处理对比 - **`git pull` 冲突解决** 一次性解决所有冲突后生成合并提交： ```bash git pull # 修改冲突文件 git add . git commit -m "Merge conflict resolved" ``` - **`git pull --rebase` 冲突解决** 需逐步解决每个冲突点： ```bash git pull --rebase # 遇到冲突时： git add <file> # 标记冲突已解决 git rebase --continue # 继续应用下一个提交 # 或放弃变基： git rebase --abort ``` > 📌 **关键区别**： > Rebase 可能需多次解决相同文件的冲突（每个提交独立处理）[^1][^3] --- ### 配置建议 设置默认使用 rebase 同步： ```bash # 全局配置 git config --global pull.rebase true # 仅当前仓库 git config pull.rebase true ``` > ⚠️ **注意事项**： > 此配置仅适用于**未推送的本地提交**，公共分支仍需用默认 `git pull`[^3]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值