荆州市网站建设_网站建设公司_UI设计师_seo优化

2026/1/19 18:50:08 网站建设项目流程

核心操作命令与步骤总结

一、分支创建与推送

1. 基于已有分支创建并切换新分支

# 切换到基础分支A
git checkout 分支A名称
# 拉取分支A最新远端代码
git pull origin 分支A名称
# 创建并切换到新分支B
git checkout -b 分支B名称
# 推送新分支B到远端（绑定跟踪关系）
git push -u origin 分支B名称

2. 分支推送（同名 / 不同名）

# 同名推送（推荐）
git push origin 本地分支名
# 不同名推送
git push origin 本地分支名:远端分支名
# 已绑定跟踪关系，直接推送
git push

二、分支开发与提交（确保修改归属当前分支）

# 查看修改状态
git status
# 将所有修改/新增文件加入暂存区（追踪文件）
git add .
# 提交到本地分支（备注清晰）
git commit -m "分支X：备注信息"

三、分支切换与隔离（避免污染）

1. 切换分支前清理（紧急修复）

# 放弃已追踪文件的未提交修改
git checkout -- .
# 删除未追踪的新文件/文件夹
git clean -fd

2. 切换分支

git checkout 目标分支名

3. 暂存当前分支未提交修改（开发间隙切换）

# 暂存修改
git stash
# 切换分支后恢复暂存的修改
git stash pop

四、版本回退（放弃当前修改）

# 查看历史提交记录（获取Commit ID）
git log --oneline
# 回退到指定Commit ID版本（彻底放弃当前修改）
git reset --hard 目标Commit ID

五、忽略文件配置

1. 全局 / 子目录忽略（提交到远端，团队共享）

根目录 / 对应子目录创建.gitignore，写入忽略规则（如dist/、node_modules/）

2. 本地临时忽略（仅当前仓库生效，不提交）

编辑.git/info/exclude，写入忽略规则（如test-local.txt）

六、关键检查与操作

操作目的	命令
检查分支 / 文件状态	git status
删除本地未追踪文件	rm -rf 文件名 / 文件夹名
拉取远端分支代码	git pull origin 分支名

核心步骤精简

分支开发：切换基础分支→拉取最新代码→创建新分支→开发时git add + commit→推送备份；
分支切换：git status检查（无未追踪文件）→清理 / 暂存修改→切换分支；
忽略文件：团队规则写.gitignore，个人临时规则写.git/info/exclude；
版本回退：查 Commit ID→git reset --hard回退。

TortoiseGit 创建分支时，四个 “基于” 选项的区别

HEAD(H) (master)

含义：基于当前工作区所在分支的最新提交（HEAD 指针指向的提交）创建新分支。
场景：你当前在 master 分支，想基于 master 的最新代码开新分支开发新功能。
特点：直接复用当前分支的最新状态，最常用的日常开发场景。

分支 (B)

含义：选择一个已存在的分支（如 dev、release），基于该分支的最新提交创建新分支。
场景：你当前在 master，但想基于 dev 分支的代码开新分支修复问题。
特点：可跨分支创建，无需先切换到目标分支。

标签 (T)

含义：选择一个已打标签的版本（如 v1.0、v2.1），基于该标签对应的提交创建新分支。
场景：线上版本 v1.0 出现 Bug，需要基于该稳定版本开分支修复，不影响主干开发。
特点：标签是代码的 “快照”，适合回溯到特定发布版本进行维护。

提交 (C)

含义：选择一个历史提交记录（通过 Commit ID 或日志定位），基于该提交创建新分支。
场景：发现某条历史提交引入了问题，需要基于该提交之前的版本开分支回滚修复。
特点：精准定位到某一次提交，用于复杂的历史问题排查与修复。

本地分支名字和远端分支名字关系

push时，本地分支名称和远程分支名，不需要完全同名，但同名是最常见且推荐的做法

核心规则

默认行为（推荐同名）

当你执行 git push origin my_branch 时，如果本地分支叫 my_branch，Git 会默认把它推送到远端同名的 my_branch 分支。
这种做法让分支管理更清晰，避免混淆，是团队协作中的标准规范。

允许不同名推送

你可以通过 git push origin 本地分支名:远端分支名 的格式，把本地分支推送到一个不同名的远端分支。
例如：git push origin work01_code:remote_work01，会把本地 work01_code 分支推送到远端的 remote_work01 分支。

跟踪关系的影响

如果在创建本地分支时设置了 “跟踪”（TortoiseGit 里的 “跟踪 (K)” 选项），Git 会记住本地分支与远端分支的对应关系。
之后只需执行 git push 就能自动推送到对应的远端分支，无需每次都指定完整的分支名

小贴士

团队协作场景：建议保持本地与远端分支同名，这样所有人都能清晰对应分支用途，减少沟通成本。
临时推送场景：如果只是临时推送测试，可以用不同名，但测试完成后建议清理掉这类不规范的远端分支。

为什么切换分支后能看到其他分支的文件？

分支的本质是 “指针”

Git 中的分支本质上只是一个指向特定提交的指针，并不是独立的文件夹。
当你切换分支时，Git 会把当前工作区的文件替换成目标分支对应提交的文件。
如果两个分支共享一些文件（比如基础的配置、公共组件），这些文件就会在切换后保留在工作区。

未被 Git 追踪的文件

如果某个文件在之前的分支里没有被 git add 和 git commit 过（即 Git 未追踪），它就不属于任何分支。
切换分支时，Git 不会动这些未追踪的文件，所以它们会一直留在工作区里。
你看到的 map、addlist 这类文件夹，很可能就是在之前分支里没有被提交到 Git 的文件。

被多个分支共同包含的文件

如果某个文件在两个分支的提交历史中都存在（比如项目的基础框架文件），切换分支时 Git 就不会删除它，只会更新那些有差异的文件。
只有当目标分支里完全没有这个文件时，Git 才会把它从工作区中移除。

快速排查方法

在当前分支下执行 `git status`，看看这些文件是显示为 Untracked（未追踪）还是已被追踪。

如图：
状态解读：
1. 当前分支
  
  你现在在本地的 work01_code 分支，并且这个分支已经和远端的 origin/work01_code 保持同步（up to date）。
2. 核心信息：Untracked files（未被 Git 追踪的文件）
  
  这是关键部分。addlist/、editaddress/、map/ 这几个文件夹，以及 ../unpackage/dist/dev/ 路径下的 .js、.wxss 等文件，都是 Git 没有记录的新文件。
  - 这些文件在之前的分支里没有被 git add 和 git commit 过，所以不属于任何分支。
  - 切换分支时 Git 不会删除未追踪的文件，所以它们会一直留在你的工作区里，这也是你在切换分支后还能看到它们的原因。
3. Git 的提示
```
(use "git add <file>..." to include in what will be committed)
```
  这是在告诉你，如果想让 Git 开始追踪这些文件，需要执行 git add 命令把它们加入暂存区，之后再 git commit 就能提交到当前分支了。
你可以做的操作
- 如果这些文件是你需要提交的：
  
  执行 git add addlist/ editaddress/ map/ 来追踪它们，然后 git commit -m "新增xxx页面"提交。
- 如果这些文件是临时生成的（比如编译后的文件）：
  
  把它们添加到项目根目录的 .gitignore文件里，让 Git 永远忽略它们，避免每次都看到这些干扰项。
- 如果这些文件是误生成的：
  
  直接用 rm -rf addlist/ editaddress/ map/删除它们（注意：这个操作不可逆，确认不需要再删）。

如果是未追踪，说明它们从未被提交到任何分支，可以直接删除或用 `.gitignore` 忽略。

如果是已追踪，说明这些文件确实是两个分支共享的，属于正常现象。

如何让让分支 A、B 完全独立，切换后互不影响

需求本质是 “分支隔离” —— 分支 A 保留初始代码，分支 B 基于 A 开发新功能，切换时两边的修改互不干扰。

当前问题的核心是：分支 B 的修改没有被完全 “提交到 B 分支”，导致切换到 A 时，未提交的修改被带到了 A 分支。

下面分「紧急修复（解决当前问题）」和「规范流程（避免后续再犯）」两步说明：

第一步：紧急修复 —— 让分支 A 恢复纯净（当前已切换到 A 分支，看到 B 的修改）

现在需要先清理分支 A 中 “被带过来的 B 分支修改”，让 A 回到初始状态：

先确认当前分支和修改状态

打开终端（或 TortoiseGit 的 “Git Bash”），执行：

git status

会看到类似 modified: xxx文件（已修改但未提交）或 Untracked files: xxx（新文件未追踪）的内容 —— 这些就是从 B 分支带过来的 “脏数据”。

放弃分支 A 中所有未提交的修改（关键！）

这一步会删除分支 A 中所有 “非提交过的修改”（包括 B 分支带过来的修改），让 A 回到最近一次提交的纯净状态：

命令行方式（推荐，精准）：

# 放弃所有已修改但未提交的文件（已追踪文件）
git checkout -- .
# 同时删除所有未追踪的新文件/文件夹（比如分支B新增的addlist/、map/等）
git clean -fd

TortoiseGit 图形化方式：

右键项目 → TortoiseGit → 放弃更改(A)... → 勾选「包括未追踪的文件 (U)」→ 点击「确定」。

验证分支 A 是否恢复

此时打开分支 A 的代码，应该已经回到初始状态，看不到分支 B 的任何修改了。

第二步：规范流程 —— 后续开发确保 A、B 完全独立（从 B 分支开发到切换 A 分支）

以后按这个流程操作，切换分支时绝对不会互相影响：

分支 B 开发并推送的完整流程（确保修改只留在 B）

在分支 B 上开发时，及时提交修改到 B 分支

每完成一个小功能 / 修改，就把修改 “固化到 B 分支”，避免修改留在 “工作区”：

命令行步骤：

# 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

TortoiseGit 图形化步骤：

右键项目 → TortoiseGit → 提交(C)... → 勾选所有要提交的文件（包括新增的文件夹）→ 填写提交备注 → 点击「提交」→ 提交完成后，再右键 → TortoiseGit → 推送(P)... → 直接推送（默认推送到同名远端分支）。

确认分支 B 的修改已完全提交（关键检查）

提交后务必执行 git status，输出显示：

nothing to commit, working tree clean

说明工作区没有未提交的修改了 —— 此时切换分支，不会带任何 “脏数据”。

切换到分支 A，放心修改

命令行：git checkout 分支A名称（比如 git checkout master）
TortoiseGit：右键 → TortoiseGit → 切换(S)... → 选择分支 A → 点击「确定」

此时分支 A 是纯净的初始状态，修改 A 的代码完全不会影响 B，反之亦然。

分支 A 修改后，如何独立提交（不影响 B）

在分支 A 修改完代码后，同样按 “提交→推送” 流程固化到 A 分支：

git add .  # 加入暂存区
git commit -m "分支A：修改初始代码xxx"  # 提交到A分支
git push origin 分支A名称:分支A名称  # 推送到远端A分支（备份）

为什么之前会互相影响？（避坑总结）

你遇到的问题，本质是以下 2 个操作漏了一个：

分支 B 的修改没有 git add + git commit（修改留在了工作区，没固化到 B 分支）；
切换分支前，工作区有未追踪的新文件（比如分支 B 新增的文件夹，没被 Git 记录，切换时不会被删除）。

按上面的流程，只要确保「切换分支前，当前分支的工作区是干净的（git status 显示 clean）」，就绝对不会出现修改互相渗透的情况。

快速验证是否独立

分支 B 提交并推送后，git status 显示 clean → 切换到 A；
分支 A 修改代码，不提交 → 切换回 B → 分支 B 的代码不会有 A 的修改（因为 A 的修改没提交，留在了 A 的工作区）；
分支 A 的修改提交后，切换到 B → 依然看不到 A 的修改，完全独立。

理解

分支 B 提交并推送后，git status 显示 clean → 切换到 A；分支 A 修改代码，不提交 → 切换回 B → 分支 B 的代码不会有 A 的修改（因为 A 的修改没提交，留在了 A 的工作区）；分支 A 的修改提交后，切换到 B → 依然看不到 A 的修改，完全独立。

这个验证的核心是帮你理解 “Git 工作区、暂存区、分支提交” 的隔离逻辑 —— 不是只有 “提交推送” 后才隔离，而是 “未提交的修改会绑定在当前分支的工作区”，切换分支时 Git 会自动 “暂存” 这些未提交修改，所以不会污染其他分支。

我用通俗的比喻和步骤拆解，帮你彻底搞懂：

核心比喻：分支 = 独立的 “工作间”，未提交修改 =“桌面上的临时文件”

每个分支就像一个独立的工作间，分支的 “提交记录” 是工作间里 “已经归档好的文件”（永久保存，属于这个分支）；
你在分支上 “未提交的修改”（包括改了已追踪的文件、新增未追踪的文件），就像在当前工作间的桌面上放的临时文件（没归档，只属于这个工作间）；
当你切换分支（从 A 切到 B），Git 会做两件事：
1. 把当前工作间（A）的 “桌面临时文件”（未提交修改）悄悄 “收起来”（暂存）；
2. 打开目标工作间（B）的 “归档文件”（B 的最近提交），并恢复 B 之前没提交完的 “桌面临时文件”（如果 B 之前有未提交修改）。

所以，未提交的修改不会跟着你 “跨工作间” —— 它只属于你修改时所在的分支。

验证步骤逐句拆解（结合比喻）

假设：分支 A 是 “初始工作间”，分支 B 是 “新功能工作间”，两者已通过之前的流程确保独立。

分支 B 提交并推送后，`git status` 显示 clean → 切换到 A

含义：B 的工作间里，所有修改都已 “归档”（提交），桌面是空的（clean）；
切换到 A：打开 A 的工作间，桌面是 A 上次离开时的状态（纯净初始状态，无临时文件）。

分支 A 修改代码，不提交 → 切换回 B → B 不受影响

分支 A 修改代码（不提交）：相当于在 A 的工作间 “桌面” 放了临时文件（未归档）；
切换到 B：Git 先把 A 工作间的 “临时文件”（未提交修改）收起来，再打开 B 的工作间（B 的桌面是空的，因为之前clean）；
结果：B 的工作间里只有自己的 “归档文件”（无 A 的临时修改），所以 B 不受影响。

👉 关键：未提交的修改是 “分支级别的临时数据”，不是 “全局共享数据” —— 你在 A 分支改了但没提交，这些修改只属于 A，切换到 B 时会被 Git 暂时隐藏，不会出现在 B 里。

分支 A 的修改提交后，切换到 B → 依然看不到 A 的修改

分支 A 提交修改：相当于把 A 工作间 “桌面的临时文件” 归档到 A 的 “文件柜”（成为 A 分支的永久记录）；
切换到 B：打开 B 的工作间，文件柜里是 B 自己的归档文件，桌面依然干净；
结果：A 的归档修改只属于 A，B 的文件柜和桌面都没有 A 的内容，完全独立。

你疑惑的核心解答：“为什么不提交也能隔离？”

你之前误以为 “必须提交推送才不会影响”，其实是混淆了 “隔离” 和 “备份”：

✅ 隔离（不污染其他分支）：只要修改 “没被提交到错误的分支”，哪怕不提交，切换分支也不会污染 —— 因为未提交修改绑定当前分支工作区；
📤 备份（防止本地数据丢失）：“提交推送” 的作用是把分支的修改 “永久保存到本地仓库”（提交）和 “同步到远端服务器”（推送），是为了防止本地电脑坏了、误删等情况，和 “隔离” 是两回事。

简单说：

想 “切换分支不污染其他分支”：只要当前分支的修改 “要么提交（归档），要么留在当前分支的工作区（不跨分支带过去）”，就能实现；
想 “修改不丢失”：才需要提交并推送（备份到远端）。

反例：什么时候未提交修改会 “污染” 其他分支？

只有一种情况会出问题：在分支 A 有未提交修改，切换到分支 B 时，B 的文件和 A 的未提交修改有冲突—— 此时 Git 会提示 “切换失败”，让你先提交 A 的修改或放弃修改，不会强制切换（避免冲突污染）。

比如：

分支 A 修改了index.js（不提交）；
分支 B 之前也修改过index.js并提交；
切换到 B 时，Git 会报错：error: Your local changes to the following files would be overwritten by merge，阻止切换。

这种情况只要按提示，要么提交 A 的修改，要么放弃 A 的修改，再切换就没问题了。

最终结论（记牢这 2 点）

未提交的修改只属于当前分支的工作区，切换分支时会被 Git 暂时隐藏，不会污染其他分支（只要没冲突）；
提交的作用是 “固化当前分支的修改”（让修改成为分支的永久记录），推送的作用是 “备份到远端”，两者都不是 “隔离” 的必要条件，但提交能避免切换分支时的冲突报错。

按之前的规范流程操作，你完全可以放心在 A、B 分支间切换 —— 未提交的修改不会串味，提交后的修改也互不影响，实现真正的分支独立！

那为什么之前切换的时候又出现了污染，哪里不一样

之前切换分支出现 “污染”，和现在验证时 “不提交也不污染” 的核心区别是：之前你的分支 B 存在 “未被 Git 追踪的新文件”，而验证时的修改是 “Git 已追踪文件的修改” —— 这两种情况的处理逻辑完全不同，也是你之前踩坑的关键！

我用表格先清晰对比两种情况的差异，再逐句拆解：

场景	修改类型	Git 是否 “认识” 这些文件	切换分支时的行为	结果（是否污染）
你之前的坑	分支 B 新增了`addlist/`、`map/`等文件夹	不认识（未执行`git add`，属于「未追踪文件」）	Git 不会隐藏 / 删除这些文件，会留在工作区	切换到 A 后，A 的工作区出现这些文件 → 污染
验证时的情况	分支 A 修改了已存在的代码文件（比如`index.js`）	认识（这些文件在分支 A 创建时就已被 Git 追踪）	Git 会暂时隐藏这些未提交的修改	切换到 B 后，看不到 A 的修改 → 不污染

🎯 关键原因：Git 对「未追踪文件」和「已追踪文件的修改」的处理逻辑完全不同

我们再结合你之前的操作，把 “污染” 的过程拆解开，你就明白哪里不一样了：

第一步：你之前在分支 B 的操作（导致污染的根源）

分支 B 基于 A 创建后，你新增了addlist/、map/等文件夹（这些是「未追踪文件」，因为你没执行git add让 Git 认识它们）；
你可能只提交了部分修改（比如修改了已追踪的旧文件），但新增的文件夹没被git add + git commit —— 这些文件夹依然是 “未追踪状态”；
你执行git status时，会看到Untracked files（就是之前截图里的内容），但你没处理就切换了分支。

第二步：切换分支时，Git 的 “区别对待”

对于分支 B 中「已追踪文件的修改」（比如你改了旧的index.js并提交了）：Git 会正常归档到 B 分支，切换到 A 时不会带过去；
对于分支 B 中「未追踪的新文件 / 文件夹」（addlist/等）：Git 的规则是「不干预未追踪文件」—— 因为 Git 不知道这些文件是你要保留的还是临时的，所以切换分支时不会隐藏、不会删除，会原封不动留在工作区；
结果：切换到 A 分支后，A 的工作区里既有自己的初始代码，又多了分支 B 留下的 “未追踪新文件”，看起来就像 “A 被 B 污染了”。

第三步：验证时为什么不污染？

验证时你在分支 A 修改的是「已被 Git 追踪的文件」（比如 A 本身就有的初始代码文件）：

这些文件是 Git “认识” 的（从分支 A 创建时就被git add + git commit过）；
你修改后不提交，这些修改属于「已追踪文件的未提交变更」；
切换到 B 时，Git 会自动把这些 “已追踪文件的未提交变更” 暂时隐藏（因为 Git 知道这些变更属于 A 分支），所以 B 的工作区不会出现这些修改。

🚫 总结：你之前和验证时的核心差异点

对比维度	你之前的操作	验证时的操作
分支 B 的新增文件	未执行`git add`，属于「未追踪文件」	无新增文件，只修改「已追踪文件」
切换分支前的`git status`	显示`Untracked files`（有未追踪文件）	显示`modified: xxx`（只有已追踪文件的修改，无未追踪文件）
Git 切换时的处理	不干预未追踪文件，留在工作区 → 污染	隐藏已追踪文件的未提交修改 → 不污染

💡 避坑关键：切换分支前，务必处理「未追踪文件」

只要记住：未追踪文件是 “全局工作区的孤儿”，不属于任何分支，切换分支时会一直留在原地，导致 “污染”。

所以切换分支前，一定要执行git status检查，遇到Untracked files，必须二选一处理：

要保留的文件：执行git add + git commit，把它归到当前分支（让 Git 认识它，切换时会被隐藏）；
不要的文件：直接删除，或加入.gitignore（让 Git 永远忽略，不会再显示）。

这样处理后，再切换分支，就和验证时一样，完全不会出现 “污染” 了！

所以原因是因为之前修改的代码没有add,而不是因为没有commit和push 对吗?

不完全对，核心原因是 “没有git add（未追踪文件）”，但 “没有commit” 在某些情况下也可能间接导致问题 —— 关键要分清 “未追踪文件” 和 “已追踪文件的未提交修改” 的区别：

用一句话总结核心结论：

✅ 你之前遇到的 “污染”（切换后看到新增文件夹）：直接原因是 “没有git add”（新增文件没被 Git 追踪，属于 “孤儿文件”，切换时不被处理）；
❌ 不是 “没有push”：push只是把本地提交同步到远端，和 “本地分支切换是否污染” 完全无关；
⚠️ “没有commit” 的影响：如果是 “已追踪文件的修改”（比如改了旧文件没commit），不会导致污染（Git 会隐藏）；但如果是 “新增文件没add”（未追踪），哪怕你想commit也做不到（commit只处理已暂存的文件），所以本质还是 “没add” 导致的。

用通俗的逻辑拆解：

Git 处理文件的流程是：未追踪文件 →（git add）→ 已暂存文件 →（git commit）→ 已提交文件

只有 “已追踪文件”（执行过git add），Git 才会管它的分支归属：
- 哪怕你没commit（比如改了已追踪的旧文件，git add后没commit，或没add但文件本身是已追踪的），切换分支时 Git 都会 “暂时隐藏” 这些修改，不会污染其他分支；
- 但如果文件 “没git add”（未追踪），Git 根本不认为它属于任何分支，切换时就会留在工作区，造成 “污染”。
commit的作用是 “固化分支修改”，不是 “避免污染”：
- commit是把 “已暂存的修改” 变成分支的永久记录，防止本地修改丢失；
- 就算你没commit，只要文件是 “已追踪” 的（之前执行过git add），切换分支也不会污染 —— 这和你验证时的情况一致。
push的作用是 “远端备份”，和本地分支污染无关：
- push只是把本地分支的提交同步到远端服务器，不管你推不推，本地分支切换的逻辑都不会变；
- 就算你没push，只要本地处理好add和commit，切换分支也不会污染。

最终简化结论（记牢这 2 句）：

本地切换分支是否 “污染”，只看「有没有未追踪文件（没git add的新增文件）」—— 有就可能污染，没有就不会；
commit是为了 “保存修改”，push是为了 “远端备份”，两者都不是 “避免污染” 的必要条件，但git add（让文件被追踪）是关键。

以后只要切换分支前，用git status检查：

没有Untracked files（未追踪文件），不管有没有commit，切换都不会污染；
有Untracked files，先add（归到当前分支）或删除，再切换就没问题了！

总结：分支独立开发完整操作步骤（确保两分支互不影响）

我下次想要在某分支基础上创建新分支，增加新功能，但是不想两个分支受影响，应该怎么操作，步骤是什么

核心原则：让每个分支的修改 “被 Git 追踪并归属该分支”，切换前清理未追踪文件，按以下步骤操作，可彻底避免分支互相影响：

一、前置准备：基于原分支创建新分支（以 “分支 A 为基础，创建分支 B 开发新功能” 为例）

切换到基础分支 A（确保 A 是纯净状态）：
- 命令行：git checkout 分支A名称（如git checkout master）
- TortoiseGit：右键项目 → TortoiseGit → 切换(S)... → 选择分支 A → 确定
拉取分支 A 的最新远端代码（避免本地 A 分支不是最新）：
- 命令行：git pull origin 分支A名称
- TortoiseGit：右键 → TortoiseGit → 拉取(L)... → 直接确定
基于分支 A 创建并切换到新分支 B：
- 命令行：git checkout -b 分支B名称（如git checkout -b feature_B）
- TortoiseGit：右键 → TortoiseGit → 创建分支(B)... → 分支名称填 “分支 B 名称” → 勾选 “切换到新分支 (S)” → 确定
（可选）将新分支 B 推送到远端（方便团队协作或备份）：
- 命令行：git push -u origin 分支B名称（-u绑定本地 B 和远端 B 的跟踪关系，后续可直接git push）
- TortoiseGit：右键 → TortoiseGit → 推送(P)... → 远端分支名称填和本地一致的 “分支 B 名称” → 确定

二、分支 B 开发新功能（关键：确保修改归属 B 分支）

开发过程中，及时提交修改（避免修改成为 “未追踪文件” 或 “游离修改”）：
- 步骤 1：查看修改状态（确认要提交的文件）
  - 命令行：git status
  - TortoiseGit：右键 → TortoiseGit → 提交(C)...（自动显示修改文件）
- 步骤 2：将所有修改 / 新增文件加入暂存区（让 Git 追踪）
  - 命令行：git add .（.表示所有文件，也可指定单个文件，如git add 文件名）
  - TortoiseGit：在提交窗口勾选所有要提交的文件（包括新增的文件夹 / 文件）
- 步骤 3：提交到本地分支 B（备注清晰，方便后续回溯）
  - 命令行：git commit -m "分支B：新增xxx功能（或修改xxx文件）"
  - TortoiseGit：填写提交备注 → 点击 “提交”
- 步骤 4：推送到远端分支 B（可选，建议每天开发完推送备份）
  - 命令行：git push（因之前绑定了跟踪关系，无需再写分支名）
  - TortoiseGit：右键 → TortoiseGit → 推送(P)... → 直接确定
开发间隙需切换到分支 A 时，务必先检查工作区状态：
- 执行git status，确保输出显示：nothing to commit, working tree clean（无未追踪文件、无未提交修改）
- 若有Untracked files（未追踪文件）：要么git add + git commit归到 B 分支，要么直接删除 / 加入.gitignore
- 若有modified: xxx（已追踪文件未提交）：要么git commit保存，要么git stash暂存（后续可恢复）

三、切换到分支 A 修改（确保 A 不受 B 影响）

切换分支 A（此时 A 是纯净初始状态）：
- 命令行：git checkout 分支A名称
- TortoiseGit：右键 → TortoiseGit → 切换(S)... → 选择分支 A → 确定
在分支 A 修改代码（独立开发，不影响 B）：
- 修改后按 “git add . → git commit -m "分支A：修改xxx" → git push” 的流程提交推送（和分支 B 的提交逻辑一致）
切换回分支 B 继续开发：
- 直接切换即可（Git 会自动恢复分支 B 的最新提交状态，看不到 A 的修改）
- 若之前用git stash暂存过 B 的修改，切换回 B 后执行git stash pop恢复修改

四、核心避坑要点（必看）

永远不要让 “未追踪文件”（没执行git add的新增文件）留在工作区切换分支 —— 这是之前污染的根源；
commit的作用是 “固化当前分支的修改”，push只是 “远端备份”，两者都不是 “避免污染” 的必要条件，但git add（让文件被追踪）是关键；
切换分支前，必做git status检查：无未追踪文件、无未提交修改（或已暂存），再切换；
分支命名建议规范（如feature_功能名、fix_ bug名），方便区分和协作。

按以上步骤操作，分支 A 和 B 会完全独立：A 的修改只属于 A，B 的新功能只属于 B，切换时互不干扰！

三个 `.gitignore` 存放位置的区别

它们的核心差异在于作用范围和是否被提交到远端

.gitignore 放在版本库的根目录

作用范围：对整个项目仓库生效，所有子目录都会遵循这个文件里的忽略规则。
是否提交到远端：会被 git add 和 git commit 提交到远端，团队成员拉取代码后会自动共享这些忽略规则。
适用场景：项目全局通用的忽略规则，比如编译输出目录（dist/）、依赖文件夹（node_modules/）、编辑器配置文件（.vscode/）等。

.gitignore 放在文件 / 文件夹所在的目录

作用范围：仅对当前目录及其子目录生效，其他目录不受影响。
是否提交到远端：会被提交到远端，团队成员拉取后也会在对应目录生效。
适用场景：某个子目录特有的忽略规则，比如前端项目里 pages/ 目录下的临时生成文件。

.git/info/exclude

作用范围：仅对当前本地仓库生效，不会被提交到远端，其他团队成员看不到。
是否提交到远端：完全不会提交，只保存在本地的 .git 目录里。
适用场景：个人本地的临时忽略需求，比如自己电脑上的测试文件、本地日志，不想影响团队其他人。

选择建议

团队协作项目：优先选「根目录的 .gitignore」，确保所有人共享统一的忽略规则。
子目录特有规则：选「放在对应目录的 .gitignore」，让规则更精准。
个人本地临时忽略：用 .git/info/exclude，避免把个人规则提交到远端。

个人本地临时忽略的文件在每个分支中都存在吗

个人本地临时忽略的文件（通过 .git/info/exclude 配置），是否在每个分支中存在，取决于文件本身的状态，而非忽略规则—— 核心结论先明确：

忽略规则（.git/info/exclude）：对本地所有分支都生效，但不会提交到远端；

被忽略的文件：如果是「未追踪的本地临时文件」，会在所有分支的工作区中存在（因为 Git 不处理未追踪文件）；如果是「已被分支提交过的文件」，忽略规则仅阻止其后续修改被追踪，文件本身仍属于对应分支。

分两种情况详细说明

假设你在本地通过 .git/info/exclude 忽略了 test-local.txt（个人测试文件）：

情况 1：`test-local.txt` 是「未追踪的本地临时文件」（从未 `git add + commit` 过）

规则生效：所有分支中，Git 都会忽略这个文件（git status 不会显示它，git add 也无法追踪它）；
文件存在性：这个文件会一直留在本地工作区—— 无论你切换到分支 A、B 还是其他分支，它都会存在（因为它是未追踪文件，Git 切换分支时不会删除 / 隐藏）；
实际效果：看起来 “每个分支都有这个文件”，但它不属于任何分支，只是本地工作区的 “全局临时文件”，不会影响任何分支的提交记录。

情况 2：`test-local.txt` 是「某分支已提交过的文件」（比如之前在分支 B 中 `git add + commit` 过）

规则生效：忽略规则仅阻止 “后续修改被追踪”—— 比如你在分支 B 中修改了 test-local.txt，Git 不会显示它为 “modified”，也不会让你提交修改；
文件存在性：
- 切换到分支 B：文件会存在（因为它是 B 分支的提交记录之一），但修改不会被追踪；
- 切换到分支 A：如果 A 分支从未提交过 test-local.txt，则工作区中不会有这个文件（除非你手动在 A 分支的工作区创建了它）；
实际效果：文件仅在 “提交过它的分支” 中存在，忽略规则不影响文件的分支归属，只阻止后续修改被追踪。

常见误区：以为 “忽略规则会让文件在分支间消失”

很多人会误以为：配置了 .git/info/exclude 忽略文件后，切换分支文件就会不见 —— 但实际上：

忽略规则的作用是「让 Git 不追踪文件的修改 / 提交」，而不是「删除文件或控制文件在分支间的显示」；
未追踪的临时文件，本质是 “工作区的独立文件”，和分支无关，所以切换分支依然存在；
若想让临时文件只在某个分支存在，需要手动在其他分支删除它（或仅在目标分支创建它）。

实用建议：个人本地临时文件的最佳处理方式

如果想让临时文件 “只在当前开发分支存在，切换到其他分支后不显示”，推荐这样做：

仅在需要临时文件的分支（比如分支 B）中创建它，并用 .git/info/exclude 忽略；
切换到其他分支（比如分支 A）前，手动删除这个临时文件（或移动到项目外的文件夹）；
切换回分支 B 后，若需要再重新创建临时文件（或从外部移回）。

这样既能满足个人临时使用需求，又不会让临时文件在其他分支中 “捣乱”，不影响分支的纯净性。

回到之前版本的两种常用方法

根据是否需要保留当前修改，分两种场景来操作

场景 1：彻底放弃当前修改，直接回退到历史版本

如果当前代码的问题无法修复，且不需要保留现有修改，可以用这种方式直接 “穿越” 到历史版本。

步骤（命令行方式）

查看历史提交记录

先找到你想要回退到的那个版本的 Commit ID：

git log --oneline

输出会像这样：

a1b2c3d (HEAD -> work01_code) 新增地图功能
d4e5f6g 修复购物车Bug
7h8i9j0 初始代码提交  # 这是你想回到的版本

记住目标版本的 Commit ID（比如 7h8i9j0）。

硬重置到目标版本

这个命令会把当前分支的 HEAD 指针直接指向目标版本，并且清空工作区的所有修改：

git reset --hard 7h8i9j0

执行后，你的代码就会完全回到 7h8i9j0 这个版本的状态。

（可选）推送到远端覆盖历史

如果需要让远端仓库也同步回退到这个版本，需要强制推送（仅在个人分支或明确团队共识时使用）：

git push -f origin 分支名

强制推送的风险与注意事项

仅限个人分支使用：如果这个分支只有你一个人在开发，强制推送是安全的。但如果是多人协作的分支（如 master、dev），强制推送会覆盖其他人的提交，导致他们的代码丢失，绝对禁止这么做。
提前沟通：如果必须在协作分支上回退，一定要先和团队成员沟通，让他们先提交自己的修改，再统一执行回退和强制推送。
替代方案：在协作分支上，更稳妥的做法是用 git revert 生成一个 “反向提交” 来撤销错误代码，而不是直接回退历史。这样不会改变已有的提交记录，对其他开发者更友好。

场景 2：保留当前修改，先切换到历史版本查看 / 测试

如果你不确定要不要彻底放弃当前修改，只是想临时回到旧版本看看，推荐用 “创建新分支” 的方式，避免破坏当前分支。

步骤（命令行方式）

基于历史版本创建新分支

git checkout 7h8i9j0 -b old_version_7h8i9j0

这样会创建一个名为 old_version_7h8i9j0 的新分支，并且代码直接是目标版本的状态。

在新分支中测试 / 修改

你可以在这个新分支里随意测试旧版本代码，不会影响原来的 work01_code 分支。

切换回原分支

测试完成后，切回原来的分支继续开发：

git checkout work01_code

📌 TortoiseGit 图形化操作（适合不喜欢命令行的同学）

查看历史版本

右键项目 → TortoiseGit → 显示日志，在日志列表里找到目标版本。

硬重置到目标版本

选中目标版本 → 右键 → 重置 "当前分支名" 到此版本... → 选择硬重置 (Hard) → 确定。

强制推送到远端

右键项目 → TortoiseGit → 推送... → 在推送窗口勾选强制推送 (Force) → 确定。

重要提醒

硬重置是高危操作：git reset --hard 会永久删除当前工作区和暂存区的所有修改，执行前务必确认这些修改不需要保留。
强制推送要谨慎：git push -f 会覆盖远端分支的历史，仅在你是该分支的唯一开发者，或已和团队沟通确认后再使用。
保留修改的稳妥方式：如果只是想临时查看旧版本，优先用 “创建新分支” 的方法，避免破坏现有代码。

避免 “白回退” 的正确顺序

如果你已经在本地回退了版本，并且希望让远端也同步到这个旧版本，正确的操作顺序是：

本地执行 git reset --hard 目标版本ID
执行 git push -f origin 你的分支名 强制推送，让远端也回退到旧版本
之后再执行 git pull，就不会出现代码被覆盖的问题

如果在执行 git push -f 之前就执行了 git pull，本地回退的旧版本就会被远端的新版本覆盖，等于白做了回退操作。

把分支 B 合并到 master 的正确步骤

为了保证合并过程安全、不冲突，推荐按下面的标准流程操作：

第一步：确保分支 B 和 master 都是最新状态

切换到分支 B

git checkout work01_code

（TortoiseGit：右键 → TortoiseGit → 切换(S)... → 选 work01_code）

拉取远端分支 B 的最新代码

git pull origin work01_code

（TortoiseGit：右键 → TortoiseGit → 拉取(L)...）

切换到 master 分支

git checkout master

（TortoiseGit：同上，切换到 master）

拉取远端 master 的最新代码

git pull origin master

这一步很关键！确保你本地的 master 是团队最新的状态，避免合并时出现不必要的冲突。

第二步：执行合并操作

在 master 分支上合并分支 B

git merge work01_code

（TortoiseGit：右键 → TortoiseGit → 合并(M)... → 选择要合并的分支 work01_code → 确定）

处理可能的冲突

如果 Git 提示有冲突，打开冲突文件，找到带 <<<<<<<、=======、>>>>>>> 的部分，手动修改并保留正确代码。

解决完所有冲突后，执行：

git add .
git commit -m "解决合并冲突"

如果没有冲突，Git 会自动生成合并提交。

第三步：推送合并后的 master 到远端

推送本地 master 到远端

git push origin master

（TortoiseGit：右键 → TortoiseGit → 推送(P)...）

（可选）删除已完成任务的分支 B

如果你不再需要分支 B 了，可以删除它：

# 删除本地分支
git branch -d work01_code
# 删除远端分支（需团队确认）
git push origin --delete work01_code

关键注意事项

合并前拉取最新代码：这是避免冲突的核心前提，一定要确保两边都是最新的。
优先在本地解决冲突：冲突只会出现在你的本地合并过程中，解决完再推送到远端，不会影响团队其他成员。
保护 master 分支：很多团队会设置 master 分支为 “受保护分支”，需要通过 Pull Request（PR）来合并，而不是直接本地合并推送。如果你的团队有这个规范，就需要先在 Git 平台（如 GitHub/Gitee）上发起 PR，经审核后再合并。

标签：网站建设企业官网项目流程 UI设计前端开发