首页 › Github/Gitee开源交流 › gitee分支

我欣飞扬 發表於 2026-1-19 18:47:00

gitee分支

<h1 id="核心操作命令与步骤总结">核心操作命令与步骤总结</h1>
<h2 id="一分支创建与推送">一、分支创建与推送</h2>
<h3 id="1-基于已有分支创建并切换新分支">1. 基于已有分支创建并切换新分支</h3>
<pre><code class="language-bash"># 切换到基础分支A
git checkout 分支A名称
# 拉取分支A最新远端代码
git pull origin 分支A名称
# 创建并切换到新分支B
git checkout -b 分支B名称
# 推送新分支B到远端（绑定跟踪关系）
git push -u origin 分支B名称
</code></pre>
<h3 id="2-分支推送同名--不同名">2. 分支推送（同名 / 不同名）</h3>
<pre><code class="language-bash"># 同名推送（推荐）
git push origin 本地分支名
# 不同名推送
git push origin 本地分支名:远端分支名
# 已绑定跟踪关系，直接推送
git push
</code></pre>
<h2 id="二分支开发与提交确保修改归属当前分支">二、分支开发与提交（确保修改归属当前分支）</h2>
<pre><code class="language-bash"># 查看修改状态
git status
# 将所有修改/新增文件加入暂存区（追踪文件）
git add .
# 提交到本地分支（备注清晰）
git commit -m "分支X：备注信息"
</code></pre>
<h2 id="三分支切换与隔离避免污染">三、分支切换与隔离（避免污染）</h2>
<h3 id="1-切换分支前清理紧急修复">1. 切换分支前清理（紧急修复）</h3>
<pre><code class="language-bash"># 放弃已追踪文件的未提交修改
git checkout -- .
# 删除未追踪的新文件/文件夹
git clean -fd
</code></pre>
<h3 id="2-切换分支">2. 切换分支</h3>
<pre><code class="language-bash">git checkout 目标分支名
</code></pre>
<h3 id="3-暂存当前分支未提交修改开发间隙切换">3. 暂存当前分支未提交修改（开发间隙切换）</h3>
<pre><code class="language-bash"># 暂存修改
git stash
# 切换分支后恢复暂存的修改
git stash pop
</code></pre>
<h2 id="四版本回退放弃当前修改">四、版本回退（放弃当前修改）</h2>
<pre><code class="language-bash"># 查看历史提交记录（获取Commit ID）
git log --oneline
# 回退到指定Commit ID版本（彻底放弃当前修改）
git reset --hard 目标Commit ID
</code></pre>
<h2 id="五忽略文件配置">五、忽略文件配置</h2>
<h3 id="1-全局--子目录忽略提交到远端团队共享">1. 全局 / 子目录忽略（提交到远端，团队共享）</h3>
<ul>
<li>根目录 / 对应子目录创建<code>.gitignore</code>，写入忽略规则（如<code>dist/</code>、<code>node_modules/</code>）</li>
</ul>
<h3 id="2-本地临时忽略仅当前仓库生效不提交">2. 本地临时忽略（仅当前仓库生效，不提交）</h3>
<ul>
<li>编辑<code>.git/info/exclude</code>，写入忽略规则（如<code>test-local.txt</code>）</li>
</ul>
<h2 id="六关键检查与操作">六、关键检查与操作</h2>
<table>
<thead>
<tr>
<th style="text-align: center">操作目的</th>
<th style="text-align: center">命令</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center">检查分支 / 文件状态</td>
<td style="text-align: center">git status</td>
</tr>
<tr>
<td style="text-align: center">删除本地未追踪文件</td>
<td style="text-align: center">rm -rf 文件名 / 文件夹名</td>
</tr>
<tr>
<td style="text-align: center">拉取远端分支代码</td>
<td style="text-align: center">git pull origin 分支名</td>
</tr>
</tbody>
</table>
<h2 id="核心步骤精简">核心步骤精简</h2>
<ol>
<li><strong>分支开发</strong>：切换基础分支→拉取最新代码→创建新分支→开发时<code>git add + commit</code>→推送备份；</li>
<li><strong>分支切换</strong>：<code>git status</code>检查（无未追踪文件）→清理 / 暂存修改→切换分支；</li>
<li><strong>忽略文件</strong>：团队规则写<code>.gitignore</code>，个人临时规则写<code>.git/info/exclude</code>；</li>
<li><strong>版本回退</strong>：查 Commit ID→<code>git reset --hard</code>回退。</li>
</ol>
<h1 id="tortoisegit-创建分支时四个-基于-选项的区别">TortoiseGit 创建分支时，四个 “基于” 选项的区别</h1>
<p><img src="https://gitee.com/milchs/node-images/raw/master/typora/image-20260119184517061.png"></p>
<h2 id="headh-master">HEAD(H) (master)</h2>
<ul>
<li><strong>含义</strong>：基于当前工作区所在分支的最新提交（HEAD 指针指向的提交）创建新分支。</li>
<li><strong>场景</strong>：你当前在 <code>master</code> 分支，想基于 <code>master</code> 的最新代码开新分支开发新功能。</li>
<li><strong>特点</strong>：直接复用当前分支的最新状态，最常用的日常开发场景。</li>
</ul>
<hr>
<h2 id="分支-b">分支 (B)</h2>
<ul>
<li><strong>含义</strong>：选择一个已存在的分支（如 <code>dev</code>、<code>release</code>），基于该分支的最新提交创建新分支。</li>
<li><strong>场景</strong>：你当前在 <code>master</code>，但想基于 <code>dev</code> 分支的代码开新分支修复问题。</li>
<li><strong>特点</strong>：可跨分支创建，无需先切换到目标分支。</li>
</ul>
<hr>
<h2 id="标签-t">标签 (T)</h2>
<ul>
<li><strong>含义</strong>：选择一个已打标签的版本（如 <code>v1.0</code>、<code>v2.1</code>），基于该标签对应的提交创建新分支。</li>
<li><strong>场景</strong>：线上版本 <code>v1.0</code> 出现 Bug，需要基于该稳定版本开分支修复，不影响主干开发。</li>
<li><strong>特点</strong>：标签是代码的 “快照”，适合回溯到特定发布版本进行维护。</li>
</ul>
<hr>
<h2 id="提交-c">提交 (C)</h2>
<ul>
<li><strong>含义</strong>：选择一个历史提交记录（通过 Commit ID 或日志定位），基于该提交创建新分支。</li>
<li><strong>场景</strong>：发现某条历史提交引入了问题，需要基于该提交之前的版本开分支回滚修复。</li>
<li><strong>特点</strong>：精准定位到某一次提交，用于复杂的历史问题排查与修复。</li>
</ul>
<h1 id="本地分支名字和远端分支名字关系">本地分支名字和远端分支名字关系</h1>
<blockquote>
<p>push时，本地分支名称和远程分支名，不需要完全同名，但同名是最常见且推荐的做法</p>
</blockquote>
<h2 id="核心规则">核心规则</h2>
<h3 id="默认行为推荐同名">默认行为（推荐同名）</h3>
<ul>
<li>当你执行 <code>git push origin my_branch</code> 时，如果本地分支叫 <code>my_branch</code>，Git 会默认把它推送到远端同名的 <code>my_branch</code> 分支。</li>
<li>这种做法让分支管理更清晰，避免混淆，是团队协作中的标准规范。</li>
</ul>
<h3 id="允许不同名推送">允许不同名推送</h3>
<ul>
<li>你可以通过 <code>git push origin 本地分支名:远端分支名</code> 的格式，把本地分支推送到一个不同名的远端分支。</li>
<li>例如：<code>git push origin work01_code:remote_work01</code>，会把本地 <code>work01_code</code> 分支推送到远端的 <code>remote_work01</code> 分支。</li>
</ul>
<h3 id="跟踪关系的影响">跟踪关系的影响</h3>
<ul>
<li>如果在创建本地分支时设置了 “跟踪”（TortoiseGit 里的 “跟踪 (K)” 选项），Git 会记住本地分支与远端分支的对应关系。</li>
<li>之后只需执行 <code>git push</code> 就能自动推送到对应的远端分支，无需每次都指定完整的分支名</li>
</ul>
<hr>
<h2 id="小贴士">小贴士</h2>
<ul>
<li><strong>团队协作场景</strong>：建议保持本地与远端分支同名，这样所有人都能清晰对应分支用途，减少沟通成本。</li>
<li><strong>临时推送场景</strong>：如果只是临时推送测试，可以用不同名，但测试完成后建议清理掉这类不规范的远端分支。</li>
</ul>
<h1 id="为什么切换分支后能看到其他分支的文件">为什么切换分支后能看到其他分支的文件？</h1>
<p><img src="https://p9-flow-imagex-sign.byteimg.com/tos-cn-i-a9rns2rl98/fcbce3fe14cd44c582f0d4da87a79b6a.png~tplv-a9rns2rl98-image.png?lk3s=8e244e95&amp;rcl=202601171435482DE8BFAFC82FFF0664E4&amp;rrcfp=dafada99&amp;x-expires=2084855748&amp;x-signature=UOrIDcPjpV5kehFtqzQMSCoGdZs%3D"></p>
<h2 id="分支的本质是-指针">分支的本质是 “指针”</h2>
<ul>
<li>Git 中的分支本质上只是一个指向特定提交的<strong>指针</strong>，并不是独立的文件夹。</li>
<li>当你切换分支时，Git 会把当前工作区的文件替换成目标分支对应提交的文件。</li>
<li>如果两个分支共享一些文件（比如基础的配置、公共组件），这些文件就会在切换后保留在工作区。</li>
</ul>
<h2 id="未被-git-追踪的文件">未被 Git 追踪的文件</h2>
<ul>
<li>如果某个文件在之前的分支里没有被 <code>git add</code> 和 <code>git commit</code> 过（即 Git 未追踪），它就不属于任何分支。</li>
<li>切换分支时，Git 不会动这些未追踪的文件，所以它们会一直留在工作区里。</li>
<li>你看到的 <code>map</code>、<code>addlist</code> 这类文件夹，很可能就是在之前分支里没有被提交到 Git 的文件。</li>
</ul>
<h2 id="被多个分支共同包含的文件">被多个分支共同包含的文件</h2>
<ul>
<li>如果某个文件在两个分支的提交历史中都存在（比如项目的基础框架文件），切换分支时 Git 就不会删除它，只会更新那些有差异的文件。</li>
<li>只有当目标分支里完全没有这个文件时，Git 才会把它从工作区中移除。</li>
</ul>
<hr>
<h2 id="快速排查方法">快速排查方法</h2>
<h3 id="在当前分支下执行-git-status看看这些文件是显示为-untracked未追踪还是已被追踪">在当前分支下执行 <code>git status</code>，看看这些文件是显示为 <strong>Untracked</strong>（未追踪）还是已被追踪。</h3>
<ul>
<li>
<p>如图：<img src="https://gitee.com/milchs/node-images/raw/master/typora/image-20260119184547606.png"></p>
</li>
<li>
<p>状态解读：</p>
<ol>
<li>
<p><strong>当前分支</strong></p>
<p>你现在在本地的 <code>work01_code</code> 分支，并且这个分支已经和远端的 <code>origin/work01_code</code> 保持同步（<code>up to date</code>）。</p>
</li>
<li>
<p><strong>核心信息：Untracked files（未被 Git 追踪的文件）</strong></p>
<p>这是关键部分。<code>addlist/</code>、<code>editaddress/</code>、<code>map/</code> 这几个文件夹，以及 <code>../unpackage/dist/dev/</code> 路径下的 <code>.js</code>、<code>.wxss</code> 等文件，都是 Git <strong>没有记录的新文件</strong>。</p>
<ul>
<li>这些文件在之前的分支里没有被 <code>git add</code> 和 <code>git commit</code> 过，所以不属于任何分支。</li>
<li>切换分支时 Git 不会删除未追踪的文件，所以它们会一直留在你的工作区里，这也是你在切换分支后还能看到它们的原因。</li>
</ul>
</li>
<li>
<p><strong>Git 的提示</strong></p>
<pre><code>(use "git add &lt;file&gt;..." to include in what will be committed)
</code></pre>
<p>这是在告诉你，如果想让 Git 开始追踪这些文件，需要执行 <code>git add</code> 命令把它们加入暂存区，之后再 <code>git commit</code> 就能提交到当前分支了。</p>
</li>
</ol>
<hr>
</li>
<li>
<p>你可以做的操作</p>
<ul>
<li>
<p>如果这些文件是你需要提交的：</p>
<p>执行<code>git add addlist/ editaddress/ map/</code> 来追踪它们，然后<code>git commit -m "新增xxx页面"</code>提交。</p>
</li>
<li>
<p>如果这些文件是临时生成的（比如编译后的文件）：</p>
<p>把它们添加到项目根目录的 <code>.gitignore</code>文件里，让 Git 永远忽略它们，避免每次都看到这些干扰项。</p>
</li>
<li>
<p>如果这些文件是误生成的：</p>
<p>直接用<code>rm -rf addlist/ editaddress/ map/</code>删除它们（注意：这个操作不可逆，确认不需要再删）。</p>
</li>
</ul>
</li>
</ul>
<h3 id="如果是未追踪说明它们从未被提交到任何分支可以直接删除或用-gitignore-忽略">如果是未追踪，说明它们从未被提交到任何分支，可以直接删除或用 <code>.gitignore</code> 忽略。</h3>
<h3 id="如果是已追踪说明这些文件确实是两个分支共享的属于正常现象">如果是已追踪，说明这些文件确实是两个分支共享的，属于正常现象。</h3>
<h1 id="如何让让分支-ab-完全独立切换后互不影响">如何让让分支 A、B 完全独立，切换后互不影响</h1>
<blockquote>
<p>需求本质是 <strong>“分支隔离”</strong> —— 分支 A 保留初始代码，分支 B 基于 A 开发新功能，切换时两边的修改互不干扰。</p>
<p>当前问题的核心是：分支 B 的修改没有被完全 “提交到 B 分支”，导致切换到 A 时，未提交的修改被带到了 A 分支。</p>
</blockquote>
<p>下面分「紧急修复（解决当前问题）」和「规范流程（避免后续再犯）」两步说明：</p>
<h2 id="第一步紧急修复--让分支-a-恢复纯净当前已切换到-a-分支看到-b-的修改">第一步：紧急修复 —— 让分支 A 恢复纯净（当前已切换到 A 分支，看到 B 的修改）</h2>
<p>现在需要先清理分支 A 中 “被带过来的 B 分支修改”，让 A 回到初始状态：</p>
<h3 id="先确认当前分支和修改状态">先确认当前分支和修改状态</h3>
<p>打开终端（或 TortoiseGit 的 “Git Bash”），执行：</p>
<pre><code class="language-bash">git status
</code></pre>
<p>会看到类似 <code>modified: xxx文件</code>（已修改但未提交）或 <code>Untracked files: xxx</code>（新文件未追踪）的内容 —— 这些就是从 B 分支带过来的 “脏数据”。</p>
<h3 id="放弃分支-a-中所有未提交的修改关键">放弃分支 A 中所有未提交的修改（关键！）</h3>
<p>这一步会删除分支 A 中所有 “非提交过的修改”（包括 B 分支带过来的修改），让 A 回到最近一次提交的纯净状态：</p>
<ul>
<li>
<p>命令行方式（推荐，精准）：</p>
<pre><code class="language-bash"># 放弃所有已修改但未提交的文件（已追踪文件）
git checkout -- .
# 同时删除所有未追踪的新文件/文件夹（比如分支B新增的addlist/、map/等）
git clean -fd
</code></pre>
</li>
<li>
<p>TortoiseGit 图形化方式：</p>
<p>右键项目 → TortoiseGit → 放弃更改(A)... → 勾选「包括未追踪的文件 (U)」→ 点击「确定」。</p>
</li>
</ul>
<h3 id="验证分支-a-是否恢复">验证分支 A 是否恢复</h3>
<p>此时打开分支 A 的代码，应该已经回到初始状态，看不到分支 B 的任何修改了。</p>
<h2 id="第二步规范流程--后续开发确保-ab-完全独立从-b-分支开发到切换-a-分支">第二步：规范流程 —— 后续开发确保 A、B 完全独立（从 B 分支开发到切换 A 分支）</h2>
<p>以后按这个流程操作，切换分支时绝对不会互相影响：</p>
<blockquote>
<p>分支 B 开发并推送的完整流程（确保修改只留在 B）</p>
</blockquote>
<h3 id="在分支-b-上开发时及时提交修改到-b-分支">在分支 B 上开发时，及时提交修改到 B 分支</h3>
<p>每完成一个小功能 / 修改，就把修改 “固化到 B 分支”，避免修改留在 “工作区”：</p>
<ul>
<li>
<p>命令行步骤：</p>
<pre><code class="language-bash"># 1. 查看当前修改的文件（确认要提交的内容）
git status
# 2. 把所有修改/新增的文件加入暂存区（追踪新文件+标记已修改文件）
git add .# （. 表示所有文件，也可以指定具体文件，比如 git add 文件名）
# 3. 提交到本地B分支（备注清晰，比如“新增地图功能”）
git commit -m "分支B：新增xxx功能（或修改xxx文件）"
# 4. 推送到远端B分支（可选，备份用）
git push origin 分支B名称:分支B名称# 同名推送，比如 git push origin work01_code:work01_code
</code></pre>
</li>
<li>
<p>TortoiseGit 图形化步骤：</p>
<p>右键项目 → TortoiseGit → 提交(C)... → 勾选所有要提交的文件（包括新增的文件夹）→ 填写提交备注 → 点击「提交」→ 提交完成后，再右键 → TortoiseGit → 推送(P)... → 直接推送（默认推送到同名远端分支）。</p>
</li>
</ul>
<h3 id="确认分支-b-的修改已完全提交关键检查">确认分支 B 的修改已完全提交（关键检查）</h3>
<p>提交后务必执行 <code>git status</code>，输出显示：</p>
<pre><code>nothing to commit, working tree clean
</code></pre>
<p>说明工作区没有未提交的修改了 —— 此时切换分支，不会带任何 “脏数据”。</p>
<h3 id="切换到分支-a放心修改">切换到分支 A，放心修改</h3>
<ul>
<li>
<p>命令行：<code>git checkout 分支A名称</code>（比如 <code>git checkout master</code>）</p>
</li>
<li>
<p>TortoiseGit：右键 → TortoiseGit → 切换(S)... → 选择分支 A → 点击「确定」</p>
<p>此时分支 A 是纯净的初始状态，修改 A 的代码完全不会影响 B，反之亦然。</p>
</li>
</ul>
<blockquote>
<p>分支 A 修改后，如何独立提交（不影响 B）</p>
</blockquote>
<p>在分支 A 修改完代码后，同样按 “提交→推送” 流程固化到 A 分支：</p>
<pre><code class="language-bash">git add .# 加入暂存区
git commit -m "分支A：修改初始代码xxx"# 提交到A分支
git push origin 分支A名称:分支A名称# 推送到远端A分支（备份）
</code></pre>
<h2 id="为什么之前会互相影响避坑总结">为什么之前会互相影响？（避坑总结）</h2>
<p>你遇到的问题，本质是以下 2 个操作漏了一个：</p>
<ol>
<li>分支 B 的修改没有 <code>git add + git commit</code>（修改留在了工作区，没固化到 B 分支）；</li>
<li>切换分支前，工作区有未追踪的新文件（比如分支 B 新增的文件夹，没被 Git 记录，切换时不会被删除）。</li>
</ol>
<p>按上面的流程，只要确保「切换分支前，当前分支的工作区是干净的（<code>git status</code> 显示 clean）」，就绝对不会出现修改互相渗透的情况。</p>
<h2 id="快速验证是否独立">快速验证是否独立</h2>
<ol>
<li>分支 B 提交并推送后，<code>git status</code> 显示 clean → 切换到 A；</li>
<li>分支 A 修改代码，不提交 → 切换回 B → 分支 B 的代码不会有 A 的修改（因为 A 的修改没提交，留在了 A 的工作区）；</li>
<li>分支 A 的修改提交后，切换到 B → 依然看不到 A 的修改，完全独立。</li>
</ol>
<h2 id="理解">理解</h2>
<blockquote>
<p>分支 B 提交并推送后，git status 显示 clean → 切换到 A； 分支 A 修改代码，不提交 → 切换回 B → 分支 B 的代码不会有 A 的修改（因为 A 的修改没提交，留在了 A 的工作区）； 分支 A 的修改提交后，切换到 B → 依然看不到 A 的修改，完全独立。</p>
</blockquote>
<p>这个验证的核心是帮你理解 <strong>“Git 工作区、暂存区、分支提交” 的隔离逻辑</strong> —— 不是只有 “提交推送” 后才隔离，而是 “未提交的修改会绑定在当前分支的工作区”，切换分支时 Git 会自动 “暂存” 这些未提交修改，所以不会污染其他分支。</p>
<p>我用通俗的比喻和步骤拆解，帮你彻底搞懂：</p>
<h3 id="核心比喻分支--独立的-工作间未提交修改-桌面上的临时文件">核心比喻：分支 = 独立的 “工作间”，未提交修改 =“桌面上的临时文件”</h3>
<ul>
<li>每个分支就像一个<strong>独立的工作间</strong>，分支的 “提交记录” 是工作间里 “已经归档好的文件”（永久保存，属于这个分支）；</li>
<li>你在分支上 “未提交的修改”（包括改了已追踪的文件、新增未追踪的文件），就像在当前工作间的<strong>桌面上放的临时文件</strong>（没归档，只属于这个工作间）；</li>
<li>当你切换分支（从 A 切到 B），Git 会做两件事：
<ol>
<li>把当前工作间（A）的 “桌面临时文件”（未提交修改）悄悄 “收起来”（暂存）；</li>
<li>打开目标工作间（B）的 “归档文件”（B 的最近提交），并恢复 B 之前没提交完的 “桌面临时文件”（如果 B 之前有未提交修改）。</li>
</ol>
</li>
</ul>
<p>所以，<strong>未提交的修改不会跟着你 “跨工作间”</strong> —— 它只属于你修改时所在的分支。</p>
<h3 id="验证步骤逐句拆解结合比喻">验证步骤逐句拆解（结合比喻）</h3>
<p>假设：分支 A 是 “初始工作间”，分支 B 是 “新功能工作间”，两者已通过之前的流程确保独立。</p>
<h4 id="分支-b-提交并推送后git-status-显示-clean--切换到-a">分支 B 提交并推送后，<code>git status</code> 显示 clean → 切换到 A</h4>
<ul>
<li>含义：B 的工作间里，所有修改都已 “归档”（提交），桌面是空的（<code>clean</code>）；</li>
<li>切换到 A：打开 A 的工作间，桌面是 A 上次离开时的状态（纯净初始状态，无临时文件）。</li>
</ul>
<h4 id="分支-a-修改代码不提交--切换回-b--b-不受影响">分支 A 修改代码，不提交 → 切换回 B → B 不受影响</h4>
<ul>
<li>分支 A 修改代码（不提交）：相当于在 A 的工作间 “桌面” 放了临时文件（未归档）；</li>
<li>切换到 B：Git 先把 A 工作间的 “临时文件”（未提交修改）收起来，再打开 B 的工作间（B 的桌面是空的，因为之前<code>clean</code>）；</li>
<li>结果：B 的工作间里只有自己的 “归档文件”（无 A 的临时修改），所以 B 不受影响。</li>
</ul>
<p>👉 关键：<strong>未提交的修改是 “分支级别的临时数据”，不是 “全局共享数据”</strong> —— 你在 A 分支改了但没提交，这些修改只属于 A，切换到 B 时会被 Git 暂时隐藏，不会出现在 B 里。</p>
<h4 id="分支-a-的修改提交后切换到-b--依然看不到-a-的修改">分支 A 的修改提交后，切换到 B → 依然看不到 A 的修改</h4>
<ul>
<li>分支 A 提交修改：相当于把 A 工作间 “桌面的临时文件” 归档到 A 的 “文件柜”（成为 A 分支的永久记录）；</li>
<li>切换到 B：打开 B 的工作间，文件柜里是 B 自己的归档文件，桌面依然干净；</li>
<li>结果：A 的归档修改只属于 A，B 的文件柜和桌面都没有 A 的内容，完全独立。</li>
</ul>
<h3 id="你疑惑的核心解答为什么不提交也能隔离">你疑惑的核心解答：“为什么不提交也能隔离？”</h3>
<p>你之前误以为 “必须提交推送才不会影响”，其实是混淆了 <strong>“隔离” 和 “备份”</strong>：</p>
<ul>
<li>✅ 隔离（不污染其他分支）：只要修改 “没被提交到错误的分支”，哪怕不提交，切换分支也不会污染 —— 因为未提交修改绑定当前分支工作区；</li>
<li>📤 备份（防止本地数据丢失）：“提交推送” 的作用是把分支的修改 “永久保存到本地仓库”（提交）和 “同步到远端服务器”（推送），是为了防止本地电脑坏了、误删等情况，<strong>和 “隔离” 是两回事</strong>。</li>
</ul>
<p>简单说：</p>
<ul>
<li>想 “切换分支不污染其他分支”：只要当前分支的修改 “要么提交（归档），要么留在当前分支的工作区（不跨分支带过去）”，就能实现；</li>
<li>想 “修改不丢失”：才需要提交并推送（备份到远端）。</li>
</ul>
<h3 id="反例什么时候未提交修改会-污染-其他分支">反例：什么时候未提交修改会 “污染” 其他分支？</h3>
<p>只有一种情况会出问题：<strong>在分支 A 有未提交修改，切换到分支 B 时，B 的文件和 A 的未提交修改有冲突</strong>—— 此时 Git 会提示 “切换失败”，让你先提交 A 的修改或放弃修改，不会强制切换（避免冲突污染）。</p>
<p>比如：</p>
<ol>
<li>分支 A 修改了<code>index.js</code>（不提交）；</li>
<li>分支 B 之前也修改过<code>index.js</code>并提交；</li>
<li>切换到 B 时，Git 会报错：<code>error: Your local changes to the following files would be overwritten by merge</code>，阻止切换。</li>
</ol>
<p>这种情况只要按提示，要么提交 A 的修改，要么放弃 A 的修改，再切换就没问题了。</p>
<h3 id="最终结论记牢这-2-点">最终结论（记牢这 2 点）</h3>
<ol>
<li>未提交的修改<strong>只属于当前分支的工作区</strong>，切换分支时会被 Git 暂时隐藏，不会污染其他分支（只要没冲突）；</li>
<li>提交的作用是 “固化当前分支的修改”（让修改成为分支的永久记录），推送的作用是 “备份到远端”，两者都不是 “隔离” 的必要条件，但提交能避免切换分支时的冲突报错。</li>
</ol>
<p>按之前的规范流程操作，你完全可以放心在 A、B 分支间切换 —— 未提交的修改不会串味，提交后的修改也互不影响，实现真正的分支独立！</p>
<blockquote>
<p>那为什么之前切换的时候又出现了污染，哪里不一样</p>
</blockquote>
<p>之前切换分支出现 “污染”，和现在验证时 “不提交也不污染” 的核心区别是：<strong>之前你的分支 B 存在 “未被 Git 追踪的新文件”，而验证时的修改是 “Git 已追踪文件的修改”</strong> —— 这两种情况的处理逻辑完全不同，也是你之前踩坑的关键！</p>
<p>我用表格先清晰对比两种情况的差异，再逐句拆解：</p>
<table>
<thead>
<tr>
<th style="text-align: center">场景</th>
<th style="text-align: center">修改类型</th>
<th style="text-align: center">Git 是否 “认识” 这些文件</th>
<th style="text-align: center">切换分支时的行为</th>
<th style="text-align: center">结果（是否污染）</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center">你之前的坑</td>
<td style="text-align: center">分支 B 新增了<code>addlist/</code>、<code>map/</code>等文件夹</td>
<td style="text-align: center">不认识（未执行<code>git add</code>，属于「未追踪文件」）</td>
<td style="text-align: center">Git 不会隐藏 / 删除这些文件，会留在工作区</td>
<td style="text-align: center">切换到 A 后，A 的工作区出现这些文件 → 污染</td>
</tr>
<tr>
<td style="text-align: center">验证时的情况</td>
<td style="text-align: center">分支 A 修改了已存在的代码文件（比如<code>index.js</code>）</td>
<td style="text-align: center">认识（这些文件在分支 A 创建时就已被 Git 追踪）</td>
<td style="text-align: center">Git 会暂时隐藏这些未提交的修改</td>
<td style="text-align: center">切换到 B 后，看不到 A 的修改 → 不污染</td>
</tr>
</tbody>
</table>
<h3 id="-关键原因git-对未追踪文件和已追踪文件的修改的处理逻辑完全不同">🎯 关键原因：Git 对「未追踪文件」和「已追踪文件的修改」的处理逻辑完全不同</h3>
<p>我们再结合你之前的操作，把 “污染” 的过程拆解开，你就明白哪里不一样了：</p>
<h4 id="第一步你之前在分支-b-的操作导致污染的根源">第一步：你之前在分支 B 的操作（导致污染的根源）</h4>
<ol>
<li>分支 B 基于 A 创建后，你新增了<code>addlist/</code>、<code>map/</code>等文件夹（这些是「未追踪文件」，因为你没执行<code>git add</code>让 Git 认识它们）；</li>
<li>你可能只提交了部分修改（比如修改了已追踪的旧文件），但<strong>新增的文件夹没被<code>git add + git commit</code></strong> —— 这些文件夹依然是 “未追踪状态”；</li>
<li>你执行<code>git status</code>时，会看到<code>Untracked files</code>（就是之前截图里的内容），但你没处理就切换了分支。</li>
</ol>
<h4 id="第二步切换分支时git-的-区别对待">第二步：切换分支时，Git 的 “区别对待”</h4>
<ul>
<li>对于分支 B 中「已追踪文件的修改」（比如你改了旧的<code>index.js</code>并提交了）：Git 会正常归档到 B 分支，切换到 A 时不会带过去；</li>
<li>对于分支 B 中「未追踪的新文件 / 文件夹」（<code>addlist/</code>等）：Git 的规则是「不干预未追踪文件」—— 因为 Git 不知道这些文件是你要保留的还是临时的，所以切换分支时不会隐藏、不会删除，会原封不动留在工作区；</li>
<li>结果：切换到 A 分支后，A 的工作区里既有自己的初始代码，又多了分支 B 留下的 “未追踪新文件”，看起来就像 “A 被 B 污染了”。</li>
</ul>
<h4 id="第三步验证时为什么不污染">第三步：验证时为什么不污染？</h4>
<p>验证时你在分支 A 修改的是「已被 Git 追踪的文件」（比如 A 本身就有的初始代码文件）：</p>
<ul>
<li>这些文件是 Git “认识” 的（从分支 A 创建时就被<code>git add + git commit</code>过）；</li>
<li>你修改后不提交，这些修改属于「已追踪文件的未提交变更」；</li>
<li>切换到 B 时，Git 会自动把这些 “已追踪文件的未提交变更” 暂时隐藏（因为 Git 知道这些变更属于 A 分支），所以 B 的工作区不会出现这些修改。</li>
</ul>
<h3 id="-总结你之前和验证时的核心差异点">🚫 总结：你之前和验证时的核心差异点</h3>
<table>
<thead>
<tr>
<th style="text-align: center">对比维度</th>
<th style="text-align: center">你之前的操作</th>
<th style="text-align: center">验证时的操作</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center">分支 B 的新增文件</td>
<td style="text-align: center">未执行<code>git add</code>，属于「未追踪文件」</td>
<td style="text-align: center">无新增文件，只修改「已追踪文件」</td>
</tr>
<tr>
<td style="text-align: center">切换分支前的<code>git status</code></td>
<td style="text-align: center">显示<code>Untracked files</code>（有未追踪文件）</td>
<td style="text-align: center">显示<code>modified: xxx</code>（只有已追踪文件的修改，无未追踪文件）</td>
</tr>
<tr>
<td style="text-align: center">Git 切换时的处理</td>
<td style="text-align: center">不干预未追踪文件，留在工作区 → 污染</td>
<td style="text-align: center">隐藏已追踪文件的未提交修改 → 不污染</td>
</tr>
</tbody>
</table>
<h3 id="-避坑关键切换分支前务必处理未追踪文件">💡 避坑关键：切换分支前，务必处理「未追踪文件」</h3>
<p>只要记住：<strong>未追踪文件是 “全局工作区的孤儿”，不属于任何分支，切换分支时会一直留在原地，导致 “污染”</strong>。</p>
<p>所以切换分支前，一定要执行<code>git status</code>检查，遇到<code>Untracked files</code>，必须二选一处理：</p>
<ol>
<li>要保留的文件：执行<code>git add + git commit</code>，把它归到当前分支（让 Git 认识它，切换时会被隐藏）；</li>
<li>不要的文件：直接删除，或加入<code>.gitignore</code>（让 Git 永远忽略，不会再显示）。</li>
</ol>
<p>这样处理后，再切换分支，就和验证时一样，完全不会出现 “污染” 了！</p>
<blockquote>
<p>所以原因是因为之前修改的代码没有add,而不是因为没有commit和push 对吗?</p>
</blockquote>
<p><strong>不完全对，核心原因是 “没有<code>git add</code>（未追踪文件）”，但 “没有<code>commit</code>” 在某些情况下也可能间接导致问题 —— 关键要分清 “未追踪文件” 和 “已追踪文件的未提交修改” 的区别</strong>：</p>
<p>用一句话总结核心结论：</p>
<ul>
<li>✅ 你之前遇到的 “污染”（切换后看到新增文件夹）：<strong>直接原因是 “没有<code>git add</code>”</strong>（新增文件没被 Git 追踪，属于 “孤儿文件”，切换时不被处理）；</li>
<li>❌ 不是 “没有<code>push</code>”：<code>push</code>只是把本地提交同步到远端，和 “本地分支切换是否污染” 完全无关；</li>
<li>⚠️ “没有<code>commit</code>” 的影响：如果是 “已追踪文件的修改”（比如改了旧文件没<code>commit</code>），不会导致污染（Git 会隐藏）；但如果是 “新增文件没<code>add</code>”（未追踪），哪怕你想<code>commit</code>也做不到（<code>commit</code>只处理已暂存的文件），所以本质还是 “没<code>add</code>” 导致的。</li>
</ul>
<h3 id="用通俗的逻辑拆解">用通俗的逻辑拆解：</h3>
<p>Git 处理文件的流程是：<code>未追踪文件</code> →（<code>git add</code>）→ <code>已暂存文件</code> →（<code>git commit</code>）→ <code>已提交文件</code></p>
<ol>
<li><strong>只有 “已追踪文件”（执行过<code>git add</code>），Git 才会管它的分支归属</strong>：
<ul>
<li>哪怕你没<code>commit</code>（比如改了已追踪的旧文件，<code>git add</code>后没<code>commit</code>，或没<code>add</code>但文件本身是已追踪的），切换分支时 Git 都会 “暂时隐藏” 这些修改，不会污染其他分支；</li>
<li>但如果文件 “没<code>git add</code>”（未追踪），Git 根本不认为它属于任何分支，切换时就会留在工作区，造成 “污染”。</li>
</ul>
</li>
<li><strong><code>commit</code>的作用是 “固化分支修改”，不是 “避免污染”</strong>：
<ul>
<li><code>commit</code>是把 “已暂存的修改” 变成分支的永久记录，防止本地修改丢失；</li>
<li>就算你没<code>commit</code>，只要文件是 “已追踪” 的（之前执行过<code>git add</code>），切换分支也不会污染 —— 这和你验证时的情况一致。</li>
</ul>
</li>
<li><strong><code>push</code>的作用是 “远端备份”，和本地分支污染无关</strong>：
<ul>
<li><code>push</code>只是把本地分支的提交同步到远端服务器，不管你推不推，本地分支切换的逻辑都不会变；</li>
<li>就算你没<code>push</code>，只要本地处理好<code>add</code>和<code>commit</code>，切换分支也不会污染。</li>
</ul>
</li>
</ol>
<h3 id="最终简化结论记牢这-2-句">最终简化结论（记牢这 2 句）：</h3>
<ol>
<li>本地切换分支是否 “污染”，只看「有没有未追踪文件（没<code>git add</code>的新增文件）」—— 有就可能污染，没有就不会；</li>
<li><code>commit</code>是为了 “保存修改”，<code>push</code>是为了 “远端备份”，两者都不是 “避免污染” 的必要条件，但<code>git add</code>（让文件被追踪）是关键。</li>
</ol>
<p>以后只要切换分支前，用<code>git status</code>检查：</p>
<ul>
<li>没有<code>Untracked files</code>（未追踪文件），不管有没有<code>commit</code>，切换都不会污染；</li>
<li>有<code>Untracked files</code>，先<code>add</code>（归到当前分支）或删除，再切换就没问题了！</li>
</ul>
<h1 id="总结分支独立开发完整操作步骤确保两分支互不影响">总结：分支独立开发完整操作步骤（确保两分支互不影响）</h1>
<blockquote>
<p>我下次想要在某分支基础上创建新分支，增加新功能，但是不想两个分支受影响，应该怎么操作，步骤是什么</p>
</blockquote>
<p>核心原则：<strong>让每个分支的修改 “被 Git 追踪并归属该分支”，切换前清理未追踪文件</strong>，按以下步骤操作，可彻底避免分支互相影响：</p>
<h2 id="一前置准备基于原分支创建新分支以-分支-a-为基础创建分支-b-开发新功能-为例">一、前置准备：基于原分支创建新分支（以 “分支 A 为基础，创建分支 B 开发新功能” 为例）</h2>
<ol>
<li>切换到基础分支 A（确保 A 是纯净状态）：
<ul>
<li>命令行：<code>git checkout 分支A名称</code>（如<code>git checkout master</code>）</li>
<li>TortoiseGit：右键项目 → <code>TortoiseGit</code> → <code>切换(S)...</code> → 选择分支 A → 确定</li>
</ul>
</li>
<li>拉取分支 A 的最新远端代码（避免本地 A 分支不是最新）：
<ul>
<li>命令行：<code>git pull origin 分支A名称</code></li>
<li>TortoiseGit：右键 → <code>TortoiseGit</code> → <code>拉取(L)...</code> → 直接确定</li>
</ul>
</li>
<li>基于分支 A 创建并切换到新分支 B：
<ul>
<li>命令行：<code>git checkout -b 分支B名称</code>（如<code>git checkout -b feature_B</code>）</li>
<li>TortoiseGit：右键 → <code>TortoiseGit</code> → <code>创建分支(B)...</code> → 分支名称填 “分支 B 名称” → 勾选 “切换到新分支 (S)” → 确定</li>
</ul>
</li>
<li>（可选）将新分支 B 推送到远端（方便团队协作或备份）：
<ul>
<li>命令行：<code>git push -u origin 分支B名称</code>（<code>-u</code>绑定本地 B 和远端 B 的跟踪关系，后续可直接<code>git push</code>）</li>
<li>TortoiseGit：右键 → <code>TortoiseGit</code> → <code>推送(P)...</code> → 远端分支名称填和本地一致的 “分支 B 名称” → 确定</li>
</ul>
</li>
</ol>
<h2 id="二分支-b-开发新功能关键确保修改归属-b-分支">二、分支 B 开发新功能（关键：确保修改归属 B 分支）</h2>
<ol>
<li>开发过程中，及时提交修改（避免修改成为 “未追踪文件” 或 “游离修改”）：
<ul>
<li>步骤 1：查看修改状态（确认要提交的文件）
<ul>
<li>命令行：<code>git status</code></li>
<li>TortoiseGit：右键 → <code>TortoiseGit</code> → <code>提交(C)...</code>（自动显示修改文件）</li>
</ul>
</li>
<li>步骤 2：将所有修改 / 新增文件加入暂存区（让 Git 追踪）
<ul>
<li>命令行：<code>git add .</code>（<code>.</code>表示所有文件，也可指定单个文件，如<code>git add 文件名</code>）</li>
<li>TortoiseGit：在提交窗口勾选所有要提交的文件（包括新增的文件夹 / 文件）</li>
</ul>
</li>
<li>步骤 3：提交到本地分支 B（备注清晰，方便后续回溯）
<ul>
<li>命令行：<code>git commit -m "分支B：新增xxx功能（或修改xxx文件）"</code></li>
<li>TortoiseGit：填写提交备注 → 点击 “提交”</li>
</ul>
</li>
<li>步骤 4：推送到远端分支 B（可选，建议每天开发完推送备份）
<ul>
<li>命令行：<code>git push</code>（因之前绑定了跟踪关系，无需再写分支名）</li>
<li>TortoiseGit：右键 → <code>TortoiseGit</code> → <code>推送(P)...</code> → 直接确定</li>
</ul>
</li>
</ul>
</li>
<li>开发间隙需切换到分支 A 时，务必先检查工作区状态：
<ul>
<li>执行<code>git status</code>，确保输出显示：<code>nothing to commit, working tree clean</code>（无未追踪文件、无未提交修改）</li>
<li>若有<code>Untracked files</code>（未追踪文件）：要么<code>git add + git commit</code>归到 B 分支，要么直接删除 / 加入<code>.gitignore</code></li>
<li>若有<code>modified: xxx</code>（已追踪文件未提交）：要么<code>git commit</code>保存，要么<code>git stash</code>暂存（后续可恢复）</li>
</ul>
</li>
</ol>
<h2 id="三切换到分支-a-修改确保-a-不受-b-影响">三、切换到分支 A 修改（确保 A 不受 B 影响）</h2>
<ol>
<li>切换分支 A（此时 A 是纯净初始状态）：
<ul>
<li>命令行：<code>git checkout 分支A名称</code></li>
<li>TortoiseGit：右键 → <code>TortoiseGit</code> → <code>切换(S)...</code> → 选择分支 A → 确定</li>
</ul>
</li>
<li>在分支 A 修改代码（独立开发，不影响 B）：
<ul>
<li>修改后按 “<code>git add .</code> → <code>git commit -m "分支A：修改xxx"</code> → <code>git push</code>” 的流程提交推送（和分支 B 的提交逻辑一致）</li>
</ul>
</li>
<li>切换回分支 B 继续开发：
<ul>
<li>直接切换即可（Git 会自动恢复分支 B 的最新提交状态，看不到 A 的修改）</li>
<li>若之前用<code>git stash</code>暂存过 B 的修改，切换回 B 后执行<code>git stash pop</code>恢复修改</li>
</ul>
</li>
</ol>
<h2 id="四核心避坑要点必看">四、核心避坑要点（必看）</h2>
<ol>
<li>永远不要让 “未追踪文件”（没执行<code>git add</code>的新增文件）留在工作区切换分支 —— 这是之前污染的根源；</li>
<li><code>commit</code>的作用是 “固化当前分支的修改”，<code>push</code>只是 “远端备份”，两者都不是 “避免污染” 的必要条件，但<code>git add</code>（让文件被追踪）是关键；</li>
<li>切换分支前，必做<code>git status</code>检查：无未追踪文件、无未提交修改（或已暂存），再切换；</li>
<li>分支命名建议规范（如<code>feature_功能名</code>、<code>fix_ bug名</code>），方便区分和协作。</li>
</ol>
<p>按以上步骤操作，分支 A 和 B 会完全独立：A 的修改只属于 A，B 的新功能只属于 B，切换时互不干扰！</p>
<h1 id="三个-gitignore-存放位置的区别">三个 <code>.gitignore</code> 存放位置的区别</h1>
<p><img src="https://gitee.com/milchs/node-images/raw/master/typora/image-20260119184602091.png"></p>
<blockquote>
<p>它们的核心差异在于<strong>作用范围</strong>和<strong>是否被提交到远端</strong></p>
</blockquote>
<h2 id="gitignore-放在版本库的根目录">.gitignore 放在版本库的根目录</h2>
<ul>
<li><strong>作用范围</strong>：对整个项目仓库生效，所有子目录都会遵循这个文件里的忽略规则。</li>
<li><strong>是否提交到远端</strong>：会被 <code>git add</code> 和 <code>git commit</code> 提交到远端，团队成员拉取代码后会自动共享这些忽略规则。</li>
<li><strong>适用场景</strong>：项目全局通用的忽略规则，比如编译输出目录（<code>dist/</code>）、依赖文件夹（<code>node_modules/</code>）、编辑器配置文件（<code>.vscode/</code>）等。</li>
</ul>
<hr>
<h2 id="gitignore-放在文件--文件夹所在的目录">.gitignore 放在文件 / 文件夹所在的目录</h2>
<ul>
<li><strong>作用范围</strong>：仅对当前目录及其子目录生效，其他目录不受影响。</li>
<li><strong>是否提交到远端</strong>：会被提交到远端，团队成员拉取后也会在对应目录生效。</li>
<li><strong>适用场景</strong>：某个子目录特有的忽略规则，比如前端项目里 <code>pages/</code> 目录下的临时生成文件。</li>
</ul>
<hr>
<h2 id="gitinfoexclude">.git/info/exclude</h2>
<ul>
<li><strong>作用范围</strong>：仅对当前本地仓库生效，不会被提交到远端，其他团队成员看不到。</li>
<li><strong>是否提交到远端</strong>：完全不会提交，只保存在本地的 <code>.git</code> 目录里。</li>
<li><strong>适用场景</strong>：个人本地的临时忽略需求，比如自己电脑上的测试文件、本地日志，不想影响团队其他人。</li>
</ul>
<h2 id="选择建议">选择建议</h2>
<ul>
<li><strong>团队协作项目</strong>：优先选「根目录的 <code>.gitignore</code>」，确保所有人共享统一的忽略规则。</li>
<li><strong>子目录特有规则</strong>：选「放在对应目录的 <code>.gitignore</code>」，让规则更精准。</li>
<li><strong>个人本地临时忽略</strong>：用 <code>.git/info/exclude</code>，避免把个人规则提交到远端。</li>
</ul>
<h1 id="个人本地临时忽略的文件在每个分支中都存在吗">个人本地临时忽略的文件在每个分支中都存在吗</h1>
<blockquote>
<p>个人本地临时忽略的文件（通过 <code>.git/info/exclude</code> 配置），<strong>是否在每个分支中存在，取决于文件本身的状态，而非忽略规则</strong>—— 核心结论先明确：</p>
</blockquote>
<p>忽略规则（<code>.git/info/exclude</code>）：对本地所有分支都生效，但不会提交到远端；</p>
<p>被忽略的文件：如果是「未追踪的本地临时文件」，会在所有分支的工作区中存在（因为 Git 不处理未追踪文件）；如果是「已被分支提交过的文件」，忽略规则仅阻止其后续修改被追踪，文件本身仍属于对应分支。</p>
<h2 id="分两种情况详细说明">分两种情况详细说明</h2>
<p>假设你在本地通过 <code>.git/info/exclude</code> 忽略了 <code>test-local.txt</code>（个人测试文件）：</p>
<h3 id="情况-1test-localtxt-是未追踪的本地临时文件从未-git-add--commit-过">情况 1：<code>test-local.txt</code> 是「未追踪的本地临时文件」（从未 <code>git add + commit</code> 过）</h3>
<ul>
<li>规则生效：所有分支中，Git 都会忽略这个文件（<code>git status</code> 不会显示它，<code>git add</code> 也无法追踪它）；</li>
<li>文件存在性：这个文件会<strong>一直留在本地工作区</strong>—— 无论你切换到分支 A、B 还是其他分支，它都会存在（因为它是未追踪文件，Git 切换分支时不会删除 / 隐藏）；</li>
<li>实际效果：看起来 “每个分支都有这个文件”，但它不属于任何分支，只是本地工作区的 “全局临时文件”，不会影响任何分支的提交记录。</li>
</ul>
<h3 id="情况-2test-localtxt-是某分支已提交过的文件比如之前在分支-b-中-git-add--commit-过">情况 2：<code>test-local.txt</code> 是「某分支已提交过的文件」（比如之前在分支 B 中 <code>git add + commit</code> 过）</h3>
<ul>
<li>规则生效：忽略规则仅阻止 “后续修改被追踪”—— 比如你在分支 B 中修改了 <code>test-local.txt</code>，Git 不会显示它为 “modified”，也不会让你提交修改；</li>
<li>文件存在性：
<ul>
<li>切换到分支 B：文件会存在（因为它是 B 分支的提交记录之一），但修改不会被追踪；</li>
<li>切换到分支 A：如果 A 分支从未提交过 <code>test-local.txt</code>，则工作区中不会有这个文件（除非你手动在 A 分支的工作区创建了它）；</li>
</ul>
</li>
<li>实际效果：文件仅在 “提交过它的分支” 中存在，忽略规则不影响文件的分支归属，只阻止后续修改被追踪。</li>
</ul>
<h3 id="常见误区以为-忽略规则会让文件在分支间消失">常见误区：以为 “忽略规则会让文件在分支间消失”</h3>
<p>很多人会误以为：配置了 <code>.git/info/exclude</code> 忽略文件后，切换分支文件就会不见 —— 但实际上：</p>
<ul>
<li>忽略规则的作用是「让 Git 不追踪文件的修改 / 提交」，而不是「删除文件或控制文件在分支间的显示」；</li>
<li>未追踪的临时文件，本质是 “工作区的独立文件”，和分支无关，所以切换分支依然存在；</li>
<li>若想让临时文件只在某个分支存在，需要手动在其他分支删除它（或仅在目标分支创建它）。</li>
</ul>
<h3 id="实用建议个人本地临时文件的最佳处理方式">实用建议：个人本地临时文件的最佳处理方式</h3>
<p>如果想让临时文件 “只在当前开发分支存在，切换到其他分支后不显示”，推荐这样做：</p>
<ol>
<li>仅在需要临时文件的分支（比如分支 B）中创建它，并用 <code>.git/info/exclude</code> 忽略；</li>
<li>切换到其他分支（比如分支 A）前，手动删除这个临时文件（或移动到项目外的文件夹）；</li>
<li>切换回分支 B 后，若需要再重新创建临时文件（或从外部移回）。</li>
</ol>
<p>这样既能满足个人临时使用需求，又不会让临时文件在其他分支中 “捣乱”，不影响分支的纯净性。</p>
<h1 id="回到之前版本的两种常用方法">回到之前版本的两种常用方法</h1>
<blockquote>
<p>根据是否需要保留当前修改，分两种场景来操作</p>
</blockquote>
<h2 id="场景-1彻底放弃当前修改直接回退到历史版本">场景 1：彻底放弃当前修改，直接回退到历史版本</h2>
<p>如果当前代码的问题无法修复，且不需要保留现有修改，可以用这种方式直接 “穿越” 到历史版本。</p>
<h3 id="步骤命令行方式">步骤（命令行方式）</h3>
<h4 id="查看历史提交记录">查看历史提交记录</h4>
<p>先找到你想要回退到的那个版本的 Commit ID：</p>
<pre><code class="language-bash">git log --oneline
</code></pre>
<p>输出会像这样：</p>
<pre><code>a1b2c3d (HEAD -&gt; work01_code) 新增地图功能
d4e5f6g 修复购物车Bug
7h8i9j0 初始代码提交# 这是你想回到的版本
</code></pre>
<p>记住目标版本的 Commit ID（比如 <code>7h8i9j0</code>）。</p>
<h4 id="硬重置到目标版本">硬重置到目标版本</h4>
<p>这个命令会把当前分支的 HEAD 指针直接指向目标版本，并且清空工作区的所有修改：</p>
<pre><code class="language-bash">git reset --hard 7h8i9j0
</code></pre>
<p>执行后，你的代码就会完全回到 <code>7h8i9j0</code> 这个版本的状态。</p>
<h4 id="可选推送到远端覆盖历史">（可选）推送到远端覆盖历史</h4>
<p>如果需要让远端仓库也同步回退到这个版本，需要强制推送（仅在个人分支或明确团队共识时使用）：</p>
<pre><code class="language-bash">git push -f origin 分支名
</code></pre>
<p><strong>强制推送的风险与注意事项</strong></p>
<ul>
<li><strong>仅限个人分支使用</strong>：如果这个分支只有你一个人在开发，强制推送是安全的。但如果是多人协作的分支（如 <code>master</code>、<code>dev</code>），强制推送会覆盖其他人的提交，导致他们的代码丢失，<strong>绝对禁止</strong>这么做。</li>
<li><strong>提前沟通</strong>：如果必须在协作分支上回退，一定要先和团队成员沟通，让他们先提交自己的修改，再统一执行回退和强制推送。</li>
<li><strong>替代方案</strong>：在协作分支上，更稳妥的做法是用 <code>git revert</code> 生成一个 “反向提交” 来撤销错误代码，而不是直接回退历史。这样不会改变已有的提交记录，对其他开发者更友好。</li>
</ul>
<h2 id="场景-2保留当前修改先切换到历史版本查看--测试">场景 2：保留当前修改，先切换到历史版本查看 / 测试</h2>
<p>如果你不确定要不要彻底放弃当前修改，只是想临时回到旧版本看看，推荐用 “创建新分支” 的方式，避免破坏当前分支。</p>
<h3 id="步骤命令行方式-1">步骤（命令行方式）</h3>
<h4 id="基于历史版本创建新分支">基于历史版本创建新分支</h4>
<pre><code class="language-bash">git checkout 7h8i9j0 -b old_version_7h8i9j0
</code></pre>
<p>这样会创建一个名为 <code>old_version_7h8i9j0</code> 的新分支，并且代码直接是目标版本的状态。</p>
<h4 id="在新分支中测试--修改">在新分支中测试 / 修改</h4>
<p>你可以在这个新分支里随意测试旧版本代码，不会影响原来的 <code>work01_code</code> 分支。</p>
<h4 id="切换回原分支">切换回原分支</h4>
<p>测试完成后，切回原来的分支继续开发：</p>
<pre><code class="language-bash">git checkout work01_code
</code></pre>
<hr>
<h2 id="-tortoisegit-图形化操作适合不喜欢命令行的同学">📌 TortoiseGit 图形化操作（适合不喜欢命令行的同学）</h2>
<h3 id="查看历史版本">查看历史版本</h3>
<p>右键项目 → TortoiseGit → 显示日志，在日志列表里找到目标版本。</p>
<h3 id="硬重置到目标版本-1">硬重置到目标版本</h3>
<p>选中目标版本 → 右键 → 重置 "当前分支名" 到此版本... → 选择 硬重置 (Hard) → 确定。</p>
<h3 id="强制推送到远端">强制推送到远端</h3>
<p>右键项目 → TortoiseGit → 推送... → 在推送窗口勾选 强制推送 (Force) → 确定。</p>
<hr>
<h2 id="重要提醒">重要提醒</h2>
<ul>
<li><strong>硬重置是高危操作</strong>：<code>git reset --hard</code> 会永久删除当前工作区和暂存区的所有修改，执行前务必确认这些修改不需要保留。</li>
<li><strong>强制推送要谨慎</strong>：<code>git push -f</code> 会覆盖远端分支的历史，仅在你是该分支的唯一开发者，或已和团队沟通确认后再使用。</li>
<li><strong>保留修改的稳妥方式</strong>：如果只是想临时查看旧版本，优先用 “创建新分支” 的方法，避免破坏现有代码。</li>
</ul>
<h2 id="避免-白回退-的正确顺序">避免 “白回退” 的正确顺序</h2>
<p>如果你已经在本地回退了版本，并且希望让远端也同步到这个旧版本，正确的操作顺序是：</p>
<ol>
<li>本地执行 <code>git reset --hard 目标版本ID</code></li>
<li>执行 <code>git push -f origin 你的分支名</code> 强制推送，让远端也回退到旧版本</li>
<li>之后再执行 <code>git pull</code>，就不会出现代码被覆盖的问题</li>
</ol>
<p>如果在执行 <code>git push -f</code> 之前就执行了 <code>git pull</code>，本地回退的旧版本就会被远端的新版本覆盖，等于白做了回退操作。</p>
<h1 id="把分支-b-合并到-master-的正确步骤">把分支 B 合并到 master 的正确步骤</h1>
<p>为了保证合并过程安全、不冲突，推荐按下面的标准流程操作：</p>
<hr>
<h2 id="第一步确保分支-b-和-master-都是最新状态">第一步：确保分支 B 和 master 都是最新状态</h2>
<h3 id="切换到分支-b">切换到分支 B</h3>
<pre><code class="language-bash">git checkout work01_code
</code></pre>
<p>（TortoiseGit：右键 → TortoiseGit → 切换(S)... → 选 work01_code）</p>
<h3 id="拉取远端分支-b-的最新代码">拉取远端分支 B 的最新代码</h3>
<pre><code class="language-bash">git pull origin work01_code
</code></pre>
<p>（TortoiseGit：右键 → TortoiseGit → 拉取(L)...）</p>
<h3 id="切换到-master-分支">切换到 master 分支</h3>
<pre><code class="language-bash">git checkout master
</code></pre>
<p>（TortoiseGit：同上，切换到 master）</p>
<h3 id="拉取远端-master-的最新代码">拉取远端 master 的最新代码</h3>
<pre><code class="language-bash">git pull origin master
</code></pre>
<p>这一步很关键！确保你本地的 master 是团队最新的状态，避免合并时出现不必要的冲突。</p>
<h2 id="第二步执行合并操作">第二步：执行合并操作</h2>
<h3 id="在-master-分支上合并分支-b">在 master 分支上合并分支 B</h3>
<pre><code class="language-bash">git merge work01_code
</code></pre>
<p>（TortoiseGit：右键 → TortoiseGit → 合并(M)... → 选择要合并的分支 work01_code → 确定）</p>
<h3 id="处理可能的冲突">处理可能的冲突</h3>
<ul>
<li>
<p>如果 Git 提示有冲突，打开冲突文件，找到带 <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code>、<code>=======</code>、<code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code> 的部分，手动修改并保留正确代码。</p>
</li>
<li>
<p>解决完所有冲突后，执行：</p>
<pre><code class="language-bash">git add .
git commit -m "解决合并冲突"
</code></pre>
</li>
<li>
<p>如果没有冲突，Git 会自动生成合并提交。</p>
</li>
</ul>
<h2 id="第三步推送合并后的-master-到远端">第三步：推送合并后的 master 到远端</h2>
<h3 id="推送本地-master-到远端">推送本地 master 到远端</h3>
<pre><code class="language-bash">git push origin master
</code></pre>
<p>（TortoiseGit：右键 → TortoiseGit → 推送(P)...）</p>
<h3 id="可选删除已完成任务的分支-b">（可选）删除已完成任务的分支 B</h3>
<p>如果你不再需要分支 B 了，可以删除它：</p>
<pre><code class="language-bash"># 删除本地分支
git branch -d work01_code
# 删除远端分支（需团队确认）
git push origin --delete work01_code
</code></pre>
<h2 id="关键注意事项">关键注意事项</h2>
<ul>
<li><strong>合并前拉取最新代码</strong>：这是避免冲突的核心前提，一定要确保两边都是最新的。</li>
<li><strong>优先在本地解决冲突</strong>：冲突只会出现在你的本地合并过程中，解决完再推送到远端，不会影响团队其他成员。</li>
<li><strong>保护 master 分支</strong>：很多团队会设置 master 分支为 “受保护分支”，需要通过 Pull Request（PR）来合并，而不是直接本地合并推送。如果你的团队有这个规范，就需要先在 Git 平台（如 GitHub/Gitee）上发起 PR，经审核后再合并。</li>
</ul><br><br>
来源：https://www.cnblogs.com/LackyQueen/p/19503451

查看完整版本: gitee分支