git merge 之后文件被删除

最新推荐文章于 2025-11-22 20:45:00 发布
原创 最新推荐文章于 2025-11-22 20:45:00 发布 · 1.5w 阅读 · 5 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#git merge

本文深入探讨Git中的合并策略，特别是当分支中文件被删除或修改时的处理方式。通过实例说明快速合并如何处理文件删除，并解释在不同场景下产生的冲突及解决办法。

git merge 快速合并时会以某个文件新的操作为准，如果master将一个dev合并进来，而dev分支中对某个文件进行过删除操作，那么merge之后master就会将那个文件删除。

举个例子：

master 分支创建文件 1.txt 并 commit -> 创建分支 dev -> dev 删除1.txt 并 commit

此时如果在master分支git merge dev ， master分支的1.txt 被删除，成功快速合并；而如果是在dev分支 git merge master， 会显示already up-to-date， 因为1.txt在dev分支已经被删除了，不必更新。

如果操作改为：

master 分支创建文件 1.txt 并 commit -> 创建分支 dev -> dev 删除1.txt 并 commit -> master 修改1.txt 并commit

此时如果进行merge操作，就会产生冲突。master分支也对该文件进行了修改，dev分支也对该文件进行了修改，合并时就要手动解决冲突，commit之后再merge。

我考虑这个问题的缘由是，fork了他人的仓库，进行了commit，之后原仓库的分支也推进了，打算合并下，于是就创建了个branch，删除所有文件，拷贝原仓库分支的文件，再本地进行merge。然后我的更新就被快速合并删除掉了。。。解决方式是直接进行拷贝，覆盖（我额外添加的文件merge之后不变，我没有的文件merge之后添加，同时改动的文件以他的为准，merge之后进行合并处理）

或者删除之后再恢复那些文件 

git checkout [commit id] -- [被删除的文件/文件夹]

Git找回删除文件的几种方法
WfTest的博客
09-27 5390
本文介绍了使用Git找回删除文件的三种常用方法：使用git checkout命令、使用git reset命令和使用git reflog命令。本文介绍了使用Git找回删除文件的三种常用方法：使用git checkout命令、使用git reset命令和使用git reflog命令。Git是一个广泛使用的分布式版本控制系统，它提供了许多强大的功能，包括找回已删除的文件。Git是一个广泛使用的分布式版本控制系统，它提供了许多强大的功能，包括找回已删除的文件。我们可以使用该命令找回被删除的文件。
git merge后 丢失文件 以及 代码
热门推荐
悟已往之不谏，知来者之可追
07-10 1万+
为什么会丢失文件？ git merge 快速合并时会以某个文件新的操作为准，如果master将一个dev合并进来，而dev分支中对某个文件进行过删除操作，那么merge之后master就会将那个文件删除。 举个例子： master 分支创建文件 1.txt 并 commit -> 创建分支 dev -> dev 删除1.txt 并 commit 此时如果在master分支git mer...
git 在合并时，为什么会删除分支中的文件？
wwwjr00的博客
07-22 1803
7、登出到feature1分支，并删除master.txt,develop.txt,然后提交。2、新建一个分支develop,创建一个文件develop.txt,并提交。问题：最后一次合并，发现git不但没有合并，反而将文件给删除了，why?3、创建分支feature1,新建文件feature.txt，并提交。1、初始化一个仓库，并新建一个master.txt文件，然后提交。8、登出master分支，合并feature1分支。6、删除feature1.txt文件并提交。4、合并develop分支。
记录一个IDEA中使用GIT的严重BUG,导致测试分支合并到主分支,以及代码恢复解决方案
小兀的博客
06-25 5663
在做项目时遇到了一个问题,就是不知道什么时候把test分支合并到了master,导致花了好长时间去恢复master分支的代码,所以研究了一下,到底是什么原因导致的这个问题当我们在test分支时，通过pull拉取更新代码，这时候会有一个进度条 进度条走完之前，我们想要去另一个分支看东西，点了checkout分支master，这时候我们切换到master分支 pull动作走完，这时候会提示合并代码，这时候有两种情况 这时候可能有的同学把代码提交到远程 这将是一个很严重的问题下面是分支版本示意图
Git分支合并：解决冲突，完美融合代码（附实战）
最新发布
fykam的博客
11-22 1130
本文详细介绍了Git分支合并的核心技术与冲突解决方法。主要内容包括：1）分支合并的两种方式（快进合并和三方合并）及适用场景；2）冲突产生的三大原因（同一文件修改、文件删除与修改冲突、同名文件冲突）；3）三种冲突解决方法（手动编辑、图形化工具、撤销合并）；4）通过Python脚本案例演示了完整的冲突解决流程。文章强调掌握这些技能对团队协作开发的重要性，为后续学习Git分支管理打下基础。
git合并代码后，目录被删除了
junjiahuang的博客
06-01 1026
同事y在合并的时候，看到同事x提交过来发分支里面，是对自己提交的分支进行了删除，即目录和文件都是红色，这时候在合并也无法进行其他选择的操作，只能被提交的分支合并的时候直接删除了。同事y在merge-c分支，合并了自己的分支b，然后拉取同事x的分支，发现产生了冲突，解决了冲突后提交。也可以切换到对应的分支去查看当前分支是否目录存在，以此证明问题在哪里。最后发现自己在分支b的目录，在merge-c里面没有了。将自己提交的代码，放在对方的后面，这样应该是不会被删除到。那么，是怎么导致这样的问题的？
git merging两边都被删除的文件
日日留心的技术专栏
09-13 401
git merging两边都被删除的文件
使用Git从其他分支merge个别文件
草根上的须子
02-27 1667
风云变幻，第二天小明按照计划开发B分支，开发到一半，产品经理突然说目前的系统消息功能（位于B分支）比较紧急，需要和列表功能（位于A分支）一起上线，当时小明就懵逼了。当系统消息功能开发完成之后，就需要考虑将系统消息功能（位于B分支）和列表功能（位于A分支）放在一个分支上提测（开发一部分的详情页功能暂先不需要合并）的问题，这时候。产品经理：我们本次开发三个功能，列表页功能、详情页功能、系统消息功能，分两次上线，先上列表功能，再上详情页和系统消息。标记会在分支合并的时候，创建一个新的提交对象，可以避免丢失。
git merge VS git rebase VS git cherry-pick
Android应用开发工程师
07-26 1638
Merge: 适用于希望保留分支历史的场景，通常用于最终合并功能分支到主分支。Rebase: 适用于希望保持线性历史记录的情况，适合于经常需要同步最新变更的开发人员。cherry-pick: 适用于需要快速应用特定修复或功能到现有分支的情况。
git merge覆盖当前分支
skysky97的博客
02-15 7282
git merge覆盖当前分支 有这么一种场景，我们需要merge某个feature分支到master分支，且希望合并后master分支与feature分支的内容完全一致。 当feature分支与master分支没有分叉时，直接merge即可，默认执行fast-forward后两个分支指向同一个commitid。而当feature分支与master分支存在分叉时，git没有对应的命令或参数来完成目标。 查看git merge可以通过-s参数指定合并的策略，其中有个ours策略，合并其他分支的同时可以保持合并
Git常用指令整理、git rebase和git merge的区别、git pull和git fetch区别
Kc635908933的博客
08-23 610
实习期间，公司都用Git来管理代码 这里总结下： 文章目录Git1. 结构图2. 基本命令3. 补充1. git merge 和 git rebase 的区别2. git pull 和 git fetch Git 1. 结构图 Workspace：工作区 Index / Stage：暂存区 Repository：仓库区（或本地仓库） Remote：远程仓 2. 基本命令 # 基本操作 git init # 初始化 git add filename
合并分支时有的文件删除了_Git&Github入门教程笔记(4)之分支管理一
weixin_39998462的博客
11-30 259
八 、分支管理(一)先列出以此小结常用命令：git branch #查看分支git branch + 名 #创建分支git checkout + 名 #切换分支git checkout -b + 名 #创建并切换到此分支(可以记为切换到新创建的分支)git merge #合并某分支到目前的分支git branch -d + 名 #删除分支(可以记为delete开头的d)8.1 分支的基本概念分支有...
05 Git的分支管理策略-Gitflow，基于GitLab演示feature、develop、release、hotfixes branch
TesterAllen的博客
09-24 2383
先以GitLab上的一张经典的图打头，作为一个总体概览，也方便理解分支的管理和走向： 1、场景预设 现假设公司有名为Hogwarts_Online2的开发项目，其中包含了上线分支master，开发分支develop，测试分支release，和个人开发的特性分支<feature branch> 2、特性分支与develop分支 2.1）与远程仓库建立连接，在本地创建自己的分支，并拉取...
Git 笔记
CCyutaotao的博客
10-16 414
git 笔记
执行git merge，合并两个分支的代码，其中某个分支的文件或代码被删除或被覆盖
卜小超超的博客
04-30 8605
项目情景：现有一套公司产品源码V1.0，我的工作任务是要在产品源码上进行二次开发 针对于git 项目，假设现有远程分支master（产品源码），将代码克隆下来，在此基础上进行开发，并将开发的代码推送到master分支（虽然我一早就知道最好不要在主分支开，但是由于这个项目就我一个人负责，于是我便将master分支占为己有，小朋友千万不要学我哦~~~） 项目进行到这个时候，技术经理突然通知我，产品源码V1.0已经升级到了V2.0，需要将我二次开发的代码跟新版本源码V2.0进行合并！！！！ 于是我先将产品源
Git之创建、合并、删除分支
jiaomubai的博客
09-04 565
Git中的分支并不是我们所理解的类似于岔路口的那种，其实这里的分支更多的则是类似于我们所说的平行宇宙。简单来说就是你在做这件事情的时候完全不影响另一件事情的发展，也就是说，你本人在这个宇宙里做着这件事，另一个你在平行宇宙里做着和你不一样的另一件事，到了某个时间节点，你发现，两件事情你都做了。 那么分支到底有什么实际作用呢？我们还是通过例子来说明吧，假如现在有一个半成品的项目，大概完成了50%，你现在正在开发一个新的功能，完成之后，这个项目整体的完成度就会是70%，但是你现在的这个功能只开发了50%，此时老
git 删除文件 解决误删
LZJWXJ树袋熊
08-06 607
如果我们在工作区中使用rm 文件名，删除了一个文件，，此时有两种情况， 一种是确实需要删除，那么需要执行：       git rm 文件名       git commit -m "删除了XX文件" 另一种是误删，则可以使用       git checkout -- 文件名：即将版本库中的内容替换工作区中的内容。...
GIT版本合并，代码删除问题
qq_37570710的博客
07-20 1443
git是比较时间戳的。如果分支的代码比主干的代码新，那么无论代码多少都会应用分支的代码。 场景：原计划722上线某个功能，在722新增代码。后来协调需要720上线。又在720新增这段代码，722删除了这段代码。 分析：720版本、722版本 有相同的一段代码，我们在720中保留了，722中删除了。 最终合并代码之后，这段代码就会被删除。 解决方案：当遇到此类情况的时候，版本靠后的不能删除相应的代码. ...
SVN代码回滚命令之---merge的使用
圆非非 -- 做非非常的产品
12-08 486
一、改动还没被提交的情况（未commit） 这种情况下，见有的人的做法是删除work copy中文件，然后重新update，恩，这种做法达到了目的，但不优雅，因为这种事没必要麻烦服务端。 其实一个命令就可以搞定：   1 &lt;code class="hljs bash"&gt;&lt;span class="hljs-comment"&gt;# svn r...
怎么查看git merge有没有忽略某些文件
09-14
<think> 我们正在讨论如何检测Git合并过程中是否存在文件被忽略的情况。用户之前遇到了分支合并显示"already up to date"但实际未合并的问题，现在转向另一个具体问题：如何检查合并操作是否忽略了某些文件。 核心概念： 1. Git合并基于三路合并（three-way merge），需要共同祖先（base）、当前分支（ours）和目标分支（theirs）的版本。 2. 合并忽略文件的情况通常发生在以下场景： - 文件被.gitattributes中的合并策略设置影响（例如合并驱动程序设置为不合并或忽略） - 文件存在冲突但被标记为已解决（但实际上可能被丢弃） - 合并过程中由于某些规则（如大小写敏感问题）导致文件未被正确合并 解决方法分为两个层面： A. 检查合并过程中哪些文件被特殊处理（忽略、冲突等） B. 检查合并结果是否遗漏了某些文件的更改 具体操作步骤： ### 步骤1：检查合并过程中的文件处理状态 合并操作会留下痕迹，我们可以通过以下命令查看合并状态： ```bash # 查看合并过程中涉及的文件及其状态（冲突、修改等） git status # 更详细地查看每个文件的冲突标记（如果有） git diff --name-status ``` 如果合并已经完成，我们可以查看合并提交中的文件修改情况： ```bash # 查看最近一次合并提交的更改 git show --name-only <merge-commit-hash> ``` 但是，如果合并已经完成，我们想检查合并过程中是否有文件被忽略，我们需要比较合并前后的状态。 ### 步骤2：检查.gitattributes中的合并设置 合并行为可能受到`.gitattributes`文件的影响。例如，某些文件可能被设置为使用`binary`属性，导致合并时不会尝试合并，而是直接使用"ours"或"theirs"版本。 ```bash # 检查项目中是否有.gitattributes文件 ls -a .gitattributes # 查看.gitattributes内容 cat .gitattributes ``` 在`.gitattributes`中，如果看到类似以下设置，则表明这些文件的合并行为被改变： *.pdf binary *.png merge=ours 其中`merge=ours`表示合并时遇到冲突直接保留当前分支的版本（忽略目标分支的修改）[^1]。 ### 步骤3：模拟合并并检查差异 我们可以模拟一次合并（不实际提交），然后检查工作区与当前分支的差异： ```bash # 确保当前分支是干净的 git checkout your-branch git reset --hard # 注意：这会丢弃未提交的更改，确保先提交或保存 # 模拟合并dev分支（不提交） git merge --no-commit --no-ff dev # 此时合并暂停，可以检查哪些文件被修改、添加、删除或冲突 git status git diff --cached # 查看已暂存的合并更改 git diff # 查看未暂存的更改（通常是冲突） # 如果发现某些文件没有出现在更改列表中，可能意味着这些文件的合并被忽略了 ``` 然后取消这次模拟合并： ```bash git merge --abort ``` ### 步骤4：比较合并前后文件差异 如果我们已经完成了合并，但怀疑某些文件没有被正确合并，我们可以比较合并前（当前分支的基点）和合并后以及目标分支的差异。 首先，找到合并基（base commit）： ```bash git merge-base your-branch dev ``` 假设合并基的哈希值为`<base-hash>`，我们可以比较从base到目标分支（dev）的更改，以及从base到合并后版本的更改： ```bash # 查看目标分支（dev）相对于合并基的更改（即这次合并应该引入的更改） git diff <base-hash> dev --name-only # 查看合并后版本相对于合并基的更改（即实际合并进来的更改） git diff <base-hash> HEAD --name-only ``` 然后，我们可以对比这两个文件列表，看是否有文件在目标分支的更改列表中出现，但在合并后的更改列表中没有出现。如果有，说明这些文件的更改没有被合并进来。 我们也可以具体查看某个文件的差异： ```bash # 比较目标分支（dev）和合并基的某个文件差异 git diff <base-hash> dev -- path/to/file # 比较合并后版本和合并基的同一个文件差异 git diff <base-hash> HEAD -- path/to/file ``` ### 步骤5：检查合并冲突解决后的文件状态 如果在合并过程中有冲突，而你在解决冲突时不小心丢弃了某些更改，可以使用以下命令检查： ```bash # 查看合并冲突解决后的文件状态（在合并提交之前） git status ``` 冲突解决后，每个冲突文件都需要使用`git add`添加到暂存区。如果某个文件有冲突但你没有解决（即没有使用git add），那么合并过程不会完成。所以，如果合并已经完成，说明所有冲突文件都被标记为已解决。但是，有可能在解决冲突时手动丢弃了目标分支的更改。 此时，我们可以使用`git log`查看合并提交的详细信息： ```bash git show <merge-commit-hash> # 显示合并提交的详细信息 git show --name-only <merge-commit-hash> # 显示合并提交更改的文件列表 ``` ### 特殊案例：大小写不敏感的文件系统 在大小写不敏感的文件系统（如Windows和macOS默认）上，如果两个分支分别重命名了文件名的大小写（例如`File.txt`和`file.txt`），Git可能无法正确合并，导致其中一个版本的更改丢失。可以通过以下方式检查： ```bash # 查看文件系统的实际状态 git ls-files ``` 如果发现文件名的大小写与预期不符，可能需要调整Git的大小写敏感设置或手动修复。 总结步骤： 1. 模拟合并（--no-commit）并检查文件状态。 2. 检查.gitattributes中是否有文件被设置为忽略合并。 3. 比较合并基到目标分支和合并基到合并后版本的差异。 4. 检查合并提交中的文件更改。 通过这些步骤，我们可以定位到合并过程中被忽略的文件。 相关问题： 1. 如何配置Git合并策略以保留特定文件的更改? 2. 如何解决Git合并时文件名大小写冲突? 3. 如何在合并后恢复被错误丢弃的文件更改? 4. 如何强制Git在合并时尝试合并二进制文件? 参考： [^1]: [Git - gitattributes Documentation](https://git-scm.com/docs/gitattributes) </think> 要精确检测 Git 合并过程中是否忽略了特定文件，可通过以下方法逐步排查： --- ### 🔍 **1. 检查合并冲突标记** 当文件内容冲突时，Git 会生成特殊标记（`<<<<<<<`、`=======`、`>>>>>>>`）。若文件无冲突标记却未被合并，可能是被静默忽略： ```bash # 查找所有包含冲突标记的文件 grep -rHn "<<<<<<<" . --include="*" ``` --- ### 📜 **2. 验证 .gitattributes 规则** Git 通过 `.gitattributes` 控制合并行为，某些文件类型可能被设置为**不合并**： ```bash # 检查项目中的属性规则 cat .gitattributes git check-attr -a -- <可疑文件路径> ``` 若输出包含 `merge=binary` 或 `merge=union`，表示该文件使用特殊合并策略： - `binary`：视为二进制文件，不尝试内容合并[^1] - `union`：保留双方修改（可能导致重复内容） --- ### ⚙️ **3. 分析三路合并差异** Git 合并基于共同祖先（base）、当前分支（ours）和目标分支（theirs）。手动对比差异： ```bash # 查找共同祖先提交 BASE=$(git merge-base HEAD dev) # 比较三方版本 git diff $BASE HEAD -- <文件路径> # 查看当前分支改动 git diff $BASE dev -- <文件路径> # 查看目标分支改动 git diff HEAD dev -- <文件路径> # 查看最终合并结果 ``` 若目标分支改动未出现在最终结果中，说明被忽略[^2]。 --- ### 📊 **4. 使用模拟合并监测** 通过 `--no-commit` 暂停合并过程，检查工作区状态： ```bash git merge dev --no-commit --no-ff git status # 查看待提交文件列表 git diff --cached # 检查暂存区内容 git merge --abort # 完成后取消合并 ``` 若文件出现在 `git diff $BASE dev` 中，但未出现在待提交列表里，则被忽略。 --- ### 🔧 **5. 检查合并驱动配置** 某些文件类型可能被全局配置跳过合并： ```bash # 查看全局合并配置 git config --get merge.ff git config --get merge.renormalize # 检查二进制文件识别配置 git grep -I --name-only "冲突内容" # -I 跳过二进制文件 ``` 若文件被识别为二进制类型（即使扩展名非二进制），Git 可能跳过内容合并[^3]。 --- ### **解决方案** 若确认文件被错误忽略： ```bash # 强制重新合并单个文件 git checkout dev -- <文件路径> # 直接采用目标分支版本 git checkout HEAD -- <文件路径> # 采用当前分支版本 # 提交修复后的合并 git commit -m "手动修复被忽略的文件" ``` --- ### 📝 **预防措施** 1. **显式声明合并策略** 在 `.gitattributes` 中为敏感文件设置合并驱动： ```ini *.json merge=union # 尝试合并JSON文件 *.data merge=binary # 明确二进制文件不合并 ``` 2. **合并前检查属性规则** ```bash git check-attr merge -- <文件路径> ``` 3. **启用合并日志** ```bash git log --merge -p # 显示合并涉及的差异文件 ``` --- ### ❓ **相关问题** 1. 如何强制Git尝试合并二进制文件？ 2. `.gitattributes`中的`diff`和`merge`属性有何区别？ 3. 合并时如何保留特定文件夹的完整结构？ 4. 如何恢复因合并策略错误丢失的文件内容？ [^1]: [Git属性文档 - 合并策略](https://git-scm.com/docs/gitattributes#_merge) [^2]: [Git三路合并算法解析](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging) [^3]: [Git二进制文件处理机制](https://git-scm.com/docs/gitattributes#_binary)
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值