1. vscode连接上远程容器后，使用git进行开发的大致流程

1. 本地创建一个新的文件夹，方便将远程仓库拉取到本地，并与其他文件隔离

2. 进入到这个目录下

3. 克隆远程仓库: git clone <repository-url>

4. 【可跳过】环境问题，如果容器镜像有改变，需要重新使用镜像启动一个新容器，然后安装 requirement.txt 中的依赖

   docker run ...
   pip install -r requirements.txt
   

5. 基于当前分支（一般是main分支或者master分支）创建新的分支 git checkout -b <new-branch-name>

6. 进行代码修改编写

7. 提交你的更改：
   git add .
git commit -m "Add a descriptive message here"

8. 推送分支到远程仓库:【注意：如果这是你第一次推送这个分支，你需要设置一个上游分支，如果这个分支没有被合并到远程main分支，那你下次就不用设置上游分支，可以直接执行 git push/git pull ；但是如果这次PR被合并了，就要重新执行下面命令，创建一个新的PR】
   git push --set-upstream origin <new-branch-name>
   这种方式相当于同时完成了1. 推送到远程分支； 2. 关联本地分支跟远程分支【注：这里会推送到远程仓库的同名分支中，如果远程仓库中没有，会自动创建一个同名分支（by the way, 你也可以不用关联到远程同名分支，不过建议同名，这样方便一下就知道本地分支对应远程仓库的哪个分支）】

2. PR中出现文件内容上传错误，此时还没有合入，如何修改这次PR？

情况一：上次推送的本地仓库以及分支都还在

1. 切换到对应分支
   git checkout <分支名>
2. 在本地编辑器中，比如vscode，打开需要修改的文件夹，进行必要的更正【包括修改文件内容，删除文件等操作】
3. 完成修改后，你需要将这些修改提交到你的本地仓库
   git add .
4. 提交这些更改
   git commit -m "描述你的更改"
5. 将你的更改推送到远程仓库上对应的分支
   git push origin <分支名>

一旦你推送了更改到远程仓库的分支，远程仓库上对应分支的PR会自动更新，包含你新提交的更改。这意味着，你不需要关闭当前PR并创建一个新的PR。

GitHub的Pull Request（PR）功能设计得非常灵活。当你向一个已经存在的PR的分支推送新的提交时，GitHub会自动将这些新的提交包含到对应的PR中。这意味着，你可以通过向同一个分支继续推送更改来不断更新PR，而无需关闭并重新创建一个新的PR。这个特性对于PR的迭代过程非常有用，它允许你根据代码审查的反馈进行更改，并使这些更改立即反映在相同的PR中。
这种方式便于维护PR的上下文和讨论历史，使得参与者能够看到PR从开放到合并过程中的完整变更历史。此外，它也减少了管理PR的复杂性，因为你不需要跟踪多个PR来解决同一组更改或问题。
要确保你的PR被有效更新，请遵循以下最佳实践：

• 保持PR的聚焦：确保每个PR只关注一个具体的问题或特性，这使得审查者更容易理解和审查你的更改。
• 频繁同步：定期将主分支（如main或master）的最新更改同步到你的特性分支，特别是在准备合并你的PR之前。这有助于减少合并冲突的可能性。
• 清晰的提交信息：为你的每个提交编写清晰、描述性强的提交信息。这有助于审查者和未来的维护者理解每个更改的目的。
• 响应反馈：当收到代码审查反馈时，尽可能在同一个PR中进行更改并推送，而不是创建一个新的PR。

这里说明一下，这种情况也适合处理：当你本地在进行开发时，忘记首先拉取最新的仓库代码，导致远程仓库合并失败（例如：落后一个提交）
1. 拉取远程最新提交：git pull origin <目标分支>  # 例如：git pull origin main
2. 手动解决冲突：
3. 提交合并结果：
	git add .         # 添加所有已解决的文件
	git commit -m "合并远程更新"
4. 推送合并后的分支到远程：
	git push origin <你的分支>  # 推送合并后的提交

情况二：本地仓库没有，需要重新拉取远程分支进行开发

1. 克隆远程仓库 git clone http:...

2. 查看远程仓库中的所有分支，确认 bug_fix 分支是否存在：git branch -r

3. 拉取远程 bug_fix 分支：git checkout -b bug_fix origin/bug_fix 这条命令会创建一个本地分支 bug_fix，并将其与远程的 bug_fix 分支关联起来。如果本地已经存在 bug_fix 分支，可以直接切换到该分支并拉取最新内容：

   git checkout bug_fix
   git pull origin bug_fix
   

4. 进行代码修改
   在本地的 bug_fix 分支上进行你需要的修改。修改完成后，添加并提交更改：

   git add <modified_files>
   git commit -m "描述你的修改内容"
   git push origin bug_fix  # 把本地 bug_fix 分支的最新修改推送到远程仓库的 bug_fix 分支
   

2-1 提交的PR落后了几个提交, 如何做能将该PR修复好然后提交?

本地分支开发后提交PR, 远程仓库点了合入, 但是发现由于开发时是直接基于之前的代码进行开发,并没有先拉取远程分支的最新提交记录(没有git pull), 导致当前提交的PR落后了一个提交
当PR因「落后目标分支提交」无法合入时，核心解决方案是让你的开发分支同步目标分支（如main/master）的最新代码，解决冲突后更新PR，具体步骤如下（通用Git流程，适配GitHub/GitLab等平台）：

详细步骤（推荐用 Rebase 保持提交历史干净）

1. 拉取远程最新代码（确保本地知道目标分支的新提交）

先更新本地的远程分支缓存，避免拉取到旧代码：

git fetch origin  # 拉取所有远程分支的最新状态（包括origin/main的新提交）

2. 切换到你的本地开发分支

如果当前不在开发分支，切换过去：

git checkout 你的开发分支名  # 例：git checkout feature/dev

3. 同步目标分支的最新代码到你的分支（用 Rebase 方式）

用 rebase 把目标分支（origin/main）的新提交“插入”到你的提交之前，避免产生无用的合并提交：

git rebase origin/main  # 核心命令：将origin/main的最新代码同步到你的分支

4. 解决冲突（关键步骤）

• 如果执行 rebase 时出现 冲突提示（如 Auto-merging xxx.py + CONFLICT (content)），说明你的代码和目标分支的新提交有重叠，需要手动解决：
  1. 打开冲突文件，找到标记冲突的部分（格式如下）：

     <<<<<<< HEAD  # 目标分支（origin/main）的代码
     目标分支的新代码内容
     =======
     你的开发分支的代码内容
     >>>>>>> 你的提交信息
     

  2. 编辑文件：保留正确的代码（删除冲突标记<<<<<<</=======/>>>>>>>），确保逻辑无误。
  3. 标记冲突已解决，并继续完成 Rebase：

     git add 冲突的文件名  # 例：git add src/utils.py（多个文件可空格分隔）
     git rebase --continue  # 继续Rebase流程  (执行完该步后, 可以git log看看, 发现提交历史已经改了, 是在之前最新提交之上进行的提交)
     

• 如果想放弃 Rebase（比如冲突太复杂），执行：git rebase --abort，回到操作前的状态。

5. 强制推送更新后的分支到远程（关键！）

因为 rebase 会修改你的本地分支提交历史（重新编排提交顺序），导致本地分支和远程分支（origin/feature/dev）不一致，普通推送会失败，需要强制推送（仅对自己的个人分支使用，切勿对公共分支如main使用！）：

git push -f origin 你的开发分支名  # 例：git push -f origin feature/dev

• 安全提示：如果是多人协作的分支，避免用 -f，可改用 git push --force-with-lease（仅当远程分支未被他人修改时才强制推送，更安全）。

6. 回到远程仓库，完成合入

• 强制推送后，远程的 PR 会自动刷新（无需重新提PR），此时 PR 的状态会变成「已同步目标分支最新代码」「无冲突」。
• 再次在远程仓库（GitHub/GitLab）点击「合入」（Merge），即可成功合入。

备选方案（用 Merge 方式，适合不熟悉 Rebase 的情况）

如果不想用 Rebase，也可以用 Merge 同步目标分支代码，步骤类似：

1. 切换到本地开发分支 + fetch 远程最新代码（同步骤1、2）。
2. 合并目标分支到你的分支：

   git merge origin/main
   

3. 若有冲突，解决后执行：git add 冲突文件 + git commit（会自动生成合并提交）。
4. 推送更新（无需强制推送，因为 Merge 不会修改历史，仅新增一个合并提交）：

   git push origin 你的开发分支名
   

5. 远程 PR 刷新后，合入即可。

关键注意事项

1. 提PR前养成好习惯：每次提PR前，先执行 git fetch origin + git rebase origin/main，提前同步目标分支代码，避免后续冲突。
2. 强制推送的风险：仅对自己独立开发的分支使用 -f，如果分支有他人协作，需先沟通，避免覆盖他人代码。
3. 冲突解决原则：解决冲突时，优先参考目标分支的业务逻辑（比如他人修复的bug、新增的配置），确保你的代码兼容最新的基准分支。
4. PR状态检查：合入前确保远程PR的「CI/CD检查」（如编译、测试）通过，避免合入后引入问题。

总结

核心逻辑是「让你的PR分支追上目标分支的进度」：通过 rebase 或 merge 同步目标分支最新代码 → 解决冲突 → 更新远程PR分支 → 合入。推荐用 rebase 保持提交历史整洁，适合个人开发分支；多人协作分支可考虑 merge。

3. 如何在本地开发代码进行版本管理（本地开发）

在本地使用 Git 维护代码版本而不提交到远程仓库是一个常见的开发实践，特别是在个人项目或实验性开发中。以 下是一些基本的步骤和命令，帮助你在本地管理代码版本：

1. 初始化本地仓库
   如果你还没有初始化一个 Git 仓库，可以在项目目录中运行以下命令：git init

2. 创建一个main分支（用来维护最新的代码），和一个dev分支（用来开发新代码）：git checkout -b dev

3. 切换到dev分支：git checkout dev

4. 编写你的代码

5. 添加文件到暂存区：git add <文件名>

6. 提交更改：git commit -m "提交信息" 【尽量在完成一个小功能后就提交一次，记录好提交信息，做好备份】

查看提交历史：git log
这将显示所有提交的详细信息，包括提交哈希、作者、日期和提交信息。
更多git log用法：
git log --oneline：以简洁的单行格式显示每个提交
git log --graph：显示提交历史的图形化表示，有助于理解分支和合并的关系
git log --since="2023-06-01" --until="2023-06-30"：过滤指定日期范围内的提交
git log --author="Your Name"：只显示指定作者的提交
git log --grep="修复错误"：根据提交信息中的内容过滤提交

在dev分支上进行开发过程中肯定会多次来回修改代码，比如当前修改代码有bug，不想要这次的修改了，那就需要回到上次提交的状态，这时候有两种策略：

• 方式一：执行 git reset 或 git revert 。
  git reset 可以将当前分支的指针移动到指定的提交，同时重置暂存区和工作区；

  git reset --hard <提交哈希>
  

  警告：–hard 选项会丢弃当前分支中自该提交以来的所有更改，请谨慎使用。

  git revert 创建一个新的提交，用于撤销指定提交的更改。这是更安全的选择，因为它不会改变历史记录。

  git revert <提交哈希>
  

• 方式二：创建新的分支进行开发
  可以创建多个分支进行管理，比如当前开发的功能正常，后面需要进行新功能开发，此时可以在这个正常分支dev基础上创建一个新开发分支dev2进行开发
  当前在dev分支，执行 git checkout -b dev2 ，然后进行开发

7. 当在dev分支开发完成后，切换回main分支，将dev的内容合并到main分支：git checkout main
8. 将dev分支合并到main分支：git merge dev
9. 解决冲突，如果存在合并冲突，需要手动解决冲突，然后重新提交
10. 删除dev分支，合并完成后，如果不需要这个分支，可以将其删除：git branch -d dev（推荐删除，因为此时main分支已经有这次开发的内容了）

如果后续继续开发，可以在main分支上创建一个新的dev分支，即首先切换到main分支，然后执行git checkout -b dev

示例工作流程

1. 初始化仓库：

   git init
   

2. 添加并提交初始文件：

   git add .
   git commit -m "初始提交"
   

3. 创建并切换到新分支：

   git branch feature_branch
   git checkout feature_branch
   

4. 在新分支上开发功能：

   # 编写代码后
   git add .
   git commit -m "添加新功能"
   

5. 切换回主分支并合并：

   git checkout master
   git merge feature_branch
   

6. 删除分支：

   git branch -d feature_branch
   

通过以上步骤，你可以在本地有效地管理代码的版本，而无需使用远程仓库。

4. 如果有两个同事, 分别基于dev分支进行了开发, 各自提交了pr, 分别是dev1 和 dev2, 现在我想使用这两个分支的合并代码, 我该如何做?

这是一个非常常见的 Git 协作场景。你有两个同事分别基于 dev 分支开发，提交了 PR（即 dev1 和 dev2 分支），而你现在想提前使用这两个分支合并后的代码（比如用于测试、集成验证等），即使它们的 PR 还未被正式合并。

下面是几种推荐做法：

✅ 推荐方案：在本地创建一个临时集成分支
步骤如下：

1. 确保本地 dev 是最新的
	git checkout dev
	git pull origin dev
2. 创建一个新的临时分支（例如叫 integration-dev1-dev2）
	git checkout -b integration-dev1-dev2
3. 合并 dev1 分支
	git merge origin/dev1
4. 再合并 dev2 分支
	git merge origin/dev2

💡 如果 dev1 和 dev2 修改的是不同文件或非冲突区域，Git 会自动完成合并。
⚠️ 如果有冲突，你需要手动解决冲突，然后 git add + git commit。
结果：
你现在有了一个包含 dev1 和 dev2 所有变更的本地分支。
可以在这个分支上运行测试、构建、验证功能是否兼容。

🔁 可选：如果 dev1 和 dev2 有依赖顺序

如果你知道 dev2 是基于 dev1 开发的（或反之），可以只合并“最新的那个”，因为它可能已经包含了另一个的变更。

但通常 PR 是各自独立基于原始 dev 分支创建的，所以建议显式合并两个。

🌐 如果你想推送到远程（供团队共享）

将集成分支推到远程（比如 GitHub/GitLab）
git push origin integration-dev1-dev2

这样其他同事也可以拉取这个集成分支进行测试。
📝 命名建议：integ/dev1+dev2、test/combined-prs 等，避免与正式分支混淆。

❌ 不推荐的做法

做法	问题
直接在 dev 上合并	会污染主开发分支，违反流程
在 dev1 上直接 merge dev2	会影响原 PR 的干净历史，可能干扰 Code Review
手动复制代码	容易出错，无法追踪变更

---

🛠 高级技巧：使用 git merge --no-ff 保留合并结构

git merge --no-ff origin/dev1 -m "Merge dev1 for integration"
git merge --no-ff origin/dev2 -m "Merge dev2 for integration"

这样即使能快进（fast-forward），也会生成一个合并提交，清晰显示集成了哪些分支。

🧪 验证建议
运行单元测试 / 集成测试
检查是否有功能冲突（比如两个 PR 都修改了同一个配置项）
确认构建是否成功

✅ 总结：最佳实践流程

1. 从最新 dev 拉出新分支
2. 依次合并 dev1 和 dev2
3. 解决冲突（如有）
4. 测试集成结果
5. （可选）推送到远程供协作

这个临时集成分支不需要被正式合并回 dev —— 等 dev1 和 dev2 的 PR 被正常合入 dev 后，dev 自然就包含了这些变更。

---

如果你使用的是 GitHub / GitLab，也可以利用它们的 “Draft PR” 或 “Merge Queue” 功能来预览合并效果，但本地集成仍然是最灵活可靠的方式。

---

5. linux服务器上,如何将本地仓库复制到另一个文件夹里?

为什么我复制过来后, 执行 git status 发现仓库中的所有文件都显示为 modified?

复制仓库后执行 git status 发现所有文件都显示为 modified，这是一个比较常见的问题，通常是由 文件系统或操作系统层面的元数据差异 导致的，而不是文件内容真的被修改了。以下是可能的原因和解决方法：

🔍 常见原因分析

1. 换行符（line endings）自动转换
   Git 在 Windows 和 macOS/Linux 上对换行符（\r\n vs \n）的处理不同。
   如果你在不同操作系统之间复制（比如从 Windows 复制到 WSL，或跨平台移动），Git 可能认为文件被“修改”了，因为换行符变了。
   即使内容没变，Git 也会标记为 modified。

✅ 检查方法：

git diff --ignore-cr-at-eol

如果这个命令显示“没有差异”，说明只是换行符问题。
2. 文件权限变化（尤其是可执行位）
在 Linux/macOS 上，Git 会跟踪文件的可执行权限（如 chmod +x）。
如果你复制到一个不保留权限的文件系统（比如从 ext4 复制到 FAT32/NTFS，或通过某些压缩工具解压），权限可能丢失。
Git 会认为文件被修改了（因为 mode 改变了）。

✅ 检查方法：

git config core.filemode

如果返回 true（默认在 Linux/macOS 是 true），Git 会检查文件权限。
如果你不需要跟踪权限变化，可以关闭它。
3. 行尾空白或编码问题
某些编辑器或复制过程可能无意中添加了空格、BOM 或改变了文件编码（如 UTF-8 vs UTF-8-BOM）。
虽然肉眼看不出，但 Git 能检测到字节级差异。

✅ 检查方法：

git diff filename

看是否真的有内容变化（比如末尾多了空格）。
4. .git 目录损坏或不完整
如果复制过程中 .git 文件夹没完整复制（比如某些隐藏文件被忽略），可能导致 Git 状态异常。

✅ 检查方法：
确认新位置的 .git 文件夹大小和原仓库基本一致。

✅ 解决方案
✅ 方案一：如果是换行符问题（最常见）
在新仓库中设置统一的换行符策略：

先备份未提交的更改（如有重要修改）
git stash
重置换行符配置（推荐跨平台项目使用）
git config core.autocrlf false # Linux/macOS
或
git config core.autocrlf true # Windows（checkout时转CRLF，commit时转LF）
清除 Git 的索引缓存并重新添加
rm .git/index
git reset
git status # 应该恢复正常

💡 更安全的做法是：在原仓库先统一设置 core.autocrlf，再复制。
✅ 方案二：如果是文件权限问题（Linux/macOS）
如果你不关心文件权限（比如只是普通代码文件，不需要 +x）：

git config core.filemode false
git status # 可能立刻恢复正常

如果关心权限，确保复制时保留权限（用 cp -a 而不是普通复制）：

cp -a /old/path/repo /new/path/repo

✅ 方案三：强制刷新 Git 索引
有时 Git 缓存了旧的状态，可以强制重置：

git rm -rf --cached .
git reset --hard HEAD
git status

⚠️ 注意：这会丢弃未暂存的修改！如果你有未提交的重要更改，请先备份（如 git stash 或手动复制文件）。

🛡️ 预防建议
使用 rsync 或 cp -a（Linux/macOS）来保留权限、时间戳等元数据。
跨平台移动时，在 .gitattributes 中明确指定换行符行为：
gitattributes
text=auto
避免通过 ZIP 压缩/解压方式移动 Git 仓库（可能丢失权限或换行符）。

总结
你的文件很可能内容没变，只是 Git 因换行符或权限认为“被修改”。
👉 先运行 git diff 看是否有真实内容变化。
👉 如果没有，按上述方法调整 core.autocrlf 或 core.filemode 即可恢复。

---

6. 如果我本地clone了一次远程仓库分支, 以后在开发时, 先git fetch origin获取远程所有最新分支信息, 就可以进行同步开发了?

是的！你的理解基本正确，而且这是一个非常好的 Git 工作习惯 👍。下面我来详细说明，并补充一些最佳实践：

✅ 你的理解是对的

当你 已经 clone 了远程仓库（无论当初是 clone 整个仓库还是某个分支），后续开发中：

git fetch origin

这一步会：
从远程仓库 origin 拉取所有最新的分支引用（包括新创建的分支）
更新 origin/xxx 这些远程跟踪分支
但不会修改你当前的工作区或本地分支（安全！）

之后你就可以：
切换到新的远程分支（如 git checkout new-feature）
将本地分支与远程同步（如 git merge origin/main 或 git rebase origin/main）
查看团队其他人的最新进展（如 git log --oneline --graph --all）

🔄 日常开发推荐流程
场景：你在本地 feature-a 分支开发，想同步主干最新代码

1. 获取远程最新状态
git fetch origin
2. 切换到主干（比如 main）
git checkout main
3. 更新本地 main 分支（可选：如果你本地有 main 分支）
git merge origin/main # 或 git reset --hard origin/main
4. 切回你的 feature 分支
git checkout feature-a
5. 把主干更新合并进来（保持你的分支不过时）
git merge main # 或 git rebase main

场景：你想基于同事刚推的新分支开始工作

git fetch origin # 获取新分支信息
git checkout their-new-branch # 自动创建本地跟踪分支

⚠️ 注意：git fetch ≠ git pull

命令	行为	安全性
git fetch origin	只下载元数据和对象，不影响工作区	✅ 安全，随时可执行
git pull	= fetch + 自动 merge/rebase，可能产生冲突或意外合并	⚠️ 在不清楚远程变更时慎用

🔔 建议：日常先用 git fetch 了解远程状态，再决定如何整合。

💡 额外技巧

1. 定期清理已删除的远程分支引用
   如果同事删除了远程分支，但你本地还有 origin/old-branch 引用：

git fetch --prune origin
或设置自动 prune：
git config --global fetch.prune true

2. 查看远程有哪些分支（包括新创建的）

git fetch origin
git branch -r # 只看远程分支
git branch -a # 看所有分支（本地+远程）

3. 查看远程分支的最新提交

git fetch origin
git log --oneline -10 origin/new-feature

✅ 总结
只要定期执行 git fetch origin，你就能始终掌握远程仓库的最新状态（包括新分支、新提交），从而安全地进行同步开发。

这是专业 Git 工作流中的标准做法，比盲目使用 git pull 更可控、更安全。

继续坚持这个好习惯！👏

n. 代码仓库迁移

待补充…

常用指令

如何基于某个分支创建一个新分支

执行步骤：

1. git checkout dev： 切换到 dev 分支

2. git checkout -b test-branch：创建并切换到新分支
   疑问·：执行完这两步，就能保证test-branch分支就是从dev创建的吗？
   解答：
   第一步git checkout dev 会将当前工作目录切换到 dev 分支。这确保了接下来创建的新分支会以 dev 分支为起点。
   第二步git checkout -b test-branch 会基于当前分支（即 dev 分支）创建一个新分支 test-branch，并自动切换到这个新分支

git 配置如何设置

配置安全目录主要是为了增强 Git 的安全性，以下是具体原因：
防止恶意操作
在某些情况下，如克隆了一个不熟悉的仓库或在不受信任的目录中进行操作，可能存在恶意脚本或配置文件。如果 Git 不加限制地在这些目录中执行操作，可能会执行恶意代码，对系统造成损害。通过将目录设置为安全目录，Git 会确保只在受信任的目录中执行操作，降低安全风险。
避免权限问题导致的意外
当工作目录不属于当前用户，或者在多人共享的系统、自动化环境等场景下，Git 可能会因权限问题而拒绝操作。配置安全目录可以让 Git 明确哪些目录是受信任的，从而避免因权限问题导致的意外操作失败，确保 Git 在这些环境下能够正常工作。
适应团队协作和自动化环境
在团队协作中，多个开发者可能共享同一个工作目录，或者在 CI/CD（持续集成 / 持续交付）等自动化环境中，工作目录可能由不同的用户或进程创建和管理。配置安全目录可以确保 Git 在这些复杂的协作和自动化场景中，只在预期的、安全的目录中进行操作，保证项目的顺利进行。
符合安全最佳实践
从安全角度来看，显式地指定安全目录是一种良好的实践。它有助于限制 Git 的操作范围，减少潜在的安全漏洞，使 Git 的使用更加符合安全标准和规范，特别是在企业级开发和生产环境中，对于保障代码的安全性和系统的稳定性具有重要意义。
【如果想详细了解可以参考：…】

git config --list ：列出所有 Git 配置项，包括用户信息（如用户名和邮箱）、远程仓库信息等。这些配置项可能来自不同的配置文件，包括系统配置文件、全局配置文件和当前仓库的本地配置文件
git config user.name：只显示当前配置的用户名
git config user.email：用于查看当前配置的邮箱地址
git config --global user.name :

• 配置用户名和邮箱，用于标识提交者 (--global: 全局配置，会应用到当前用户的所有 Git 仓库（除非在特定仓库中设置了局部配置覆盖它))：

  git config --global user.name "Your Name"
  git config --global user.email "your.email@example.com"
  

执行局部配置命令:

# 设置当前仓库的用户名
git config user.name "你的局部用户名"

# 设置当前仓库的邮箱（通常与代码提交关联）
git config user.email "你的局部邮箱地址"

# 查看当前仓库的所有配置（包括局部配置）
git config --local --list

• 添加单个安全目录 ：可以使用命令 git config --global --add safe.directory /path/to/your/repository 将指定目录添加到全局的安全目录列表中

理解 git clone

当你运行 git clone 命令克隆远程仓库时，它会默认克隆远程仓库的 所有分支，但只会从远程仓库的默认分支（通常是 main 或 master）检出（checkout）内容到本地的工作目录。这意味着：
本地仓库中会包含远程仓库的所有分支，但这些分支会被存储为 远程分支（remote branches），名称格式为 origin/<branch_name>。
本地只会创建一个与远程默认分支对应的 本地分支，通常是 main 或 master，并且这个本地分支会自动与远程分支（如 origin/main）关联起来。
例如，如果你克隆了一个远程仓库，远程仓库有 main 和 bug_fix 两个分支，执行 git clone 后：
本地会有一个 main 分支，这是从 origin/main 检出的内容。
本地还会有一个 origin/bug_fix 的远程分支引用，但它不会自动创建一个本地的 bug_fix 分支。

理解 git fetch

git fetch 命令会从远程仓库获取所有分支的更新，但它不会自动合并这些更新到本地分支。它只是将远程仓库的分支更新拉取到本地仓库的远程分支引用中（如 origin/main、origin/bug_fix 等）
例如，如果你运行以下命令：git fetch origin
这会拉取远程仓库 origin 的所有分支的最新内容，并更新本地仓库中的远程分支引用（如 origin/main、origin/bug_fix 等）。但本地的分支（如 main 或 bug_fix）不会自动更新，除非你手动合并或拉取。

要将远程分支的内容更新到本地分支，可以使用以下命令：

git fetch origin
git merge origin/main  # 合并远程 main 分支到当前分支

或者，使用 git pull 命令，它相当于 git fetch 加上 git merge：

git pull origin main  # 拉取远程 main 分支并合并到当前分支

在与同事合作在同一个分支进行开发时, 通常使用该指令

1. git fetch origin # 获取远程仓库所有分支的更新
2. git branch -r # 列出所有远程跟踪分支，带 origin/ 前缀
3. 切换到该分支（首次操作）
   如果本地还没有该分支，需要基于远程跟踪分支创建并切换到本地分支（名称通常与远程保持一致）：
   git checkout -b feature/colleague-work origin/feature/colleague-work
   这一步会在本地创建 feature/colleague-work 分支，并同步同事 push 的最新内容
4. 如果本地已有该分支，同步最新内容
   若之前已经创建过该分支，后续同事又提交了新内容，只需切换到该分支后执行 git pull 即可同步：
   git checkout feature/colleague-work # 切换到本地分支
   git pull origin feature/colleague-work # 拉取远程最新内容

理解 rebase

要理解 git rebase，最直观的方式是通过分支提交历史的图示对比，结合「同步分支」和「整理提交」两个核心场景，清晰展示 rebase 如何改变提交历史。以下用简化的图示（用「圆圈+哈希缩写」表示提交，箭头表示提交依赖关系）逐步讲解：

一、先明确基础概念：分支与提交历史

假设初始状态有两个分支：

• main 分支：主分支，有 3 个提交 C1（初始）→ C2（功能A）→ C3（修复B）；
• feature 分支：你基于 main 的 C3 创建的开发分支，有 2 个独立提交 D1（开发功能C）→ D2（优化功能C）。

此时的提交历史图示如下（箭头指向“父提交”，即依赖的前一个提交）：

main:    C1 → C2 → C3
                   ↓
feature:           D1 → D2  （feature 基于 main 的 C3 创建）

二、场景1：用 rebase 同步主分支更新（核心场景）

1. 前提：main 分支有新提交

在你开发 feature 时，团队其他人向 main 提交了新代码 C4（新增功能D），此时 main 领先于 feature，历史变成：

main:    C1 → C2 → C3 → C4  （main 新增了 C4）
                   ↓
feature:           D1 → D2  （feature 仍基于 C3，未包含 C4）

此时若直接 merge main 到 feature，会产生「合并节点」（如 M1），历史变成“菱形”，不够整洁：

# 若用 merge，历史会变成：
main:    C1 → C2 → C3 → C4
                   ↘     ↗
feature:           D1 → D2 → M1  （M1 是 merge 产生的合并节点）

2. 用 rebase 同步：让 feature 基于 main 最新提交重新应用

执行命令：

git checkout feature  # 切换到开发分支
git rebase main       # 将 feature 基于 main 的最新提交（C4）重新应用

rebase 执行过程图示拆解：

1. 第一步：暂存 feature 的提交
   Git 先把 feature 分支的所有独立提交（D1、D2）从当前基础（C3）上“摘下来”，暂存为临时补丁：

   main:    C1 → C2 → C3 → C4  （main 不变）
                   ↓
   暂存区： [D1补丁, D2补丁]    （D1、D2 被暂时移除）
   feature:           （此时 feature 分支“回退”到与 main 一致的 C4）
   

2. 第二步：将 feature 重置到 main 最新提交
   把 feature 分支的“基础”从 C3 切换到 main 的最新提交 C4，此时 feature 与 main 完全一致：

   main:    C1 → C2 → C3 → C4
                          ↓
   feature:                （feature 现在指向 C4，与 main 重合）
   暂存区： [D1补丁, D2补丁]
   

3. 第三步：逐个重新应用暂存的提交
   把暂存的 D1、D2 补丁按原顺序，逐个重新应用到 C4 之后，生成新的提交（注意：新提交的哈希会变，因为基础变了）：

   main:    C1 → C2 → C3 → C4
                          ↓
   feature:                D1' → D2'  （D1'、D2' 是重新应用后的新提交）
   

   最终提交历史是完全线性的，没有 merge 产生的菱形节点！

3. 冲突处理的图示补充

若 rebase 时 D1 与 C4 有代码冲突（比如都修改了同一个文件的同一行）：

• Git 会暂停 rebase，在图示中标记“冲突点”：

  main:    C1 → C2 → C3 → C4
                          ↓
  feature:                （暂停在 C4 之后，准备应用 D1 时冲突）
  待处理： D1（冲突）、D2（未应用）
  

• 你解决冲突后，执行 git add <冲突文件> 标记解决，再用 git rebase --continue 继续：

  # 解决冲突后继续，完成 D1' 和 D2' 的应用：
  main:    C1 → C2 → C3 → C4
                          ↓
  feature:                D1' → D2'
  

• 若想放弃 rebase，执行 git rebase --abort，feature 会回到 rebase 前的状态（C3 → D1 → D2）。

三、场景2：用 rebase -i 整理本地提交（交互式变基）

假设 feature 分支有 3 个杂乱的本地提交（还未推送到远程）：

feature:  C4 → D1（初稿）→ D2（修复拼写错误）→ D3（补充注释）

你想把这 3 个提交（D1、D2、D3）合并为 1 个“整洁的功能提交”，执行：

git rebase -i HEAD~3  # 对最近 3 个提交（D1、D2、D3）进行交互式整理

1. 编辑“操作指令”

Git 会打开编辑器，显示 3 个提交的默认指令（pick 表示“保留”）：

pick a1b2c3d D1（初稿）    # 第一个提交（哈希 a1b2c3d）
pick d4e5f6g D2（修复拼写错误）# 第二个提交（哈希 d4e5f6g）
pick 7h8i9j0 D3（补充注释） # 第三个提交（哈希 7h8i9j0）

你修改指令为：用 squash（缩写 s）将 D2、D3 合并到 D1：

pick a1b2c3d D1（初稿）    # 保留第一个提交，作为合并后的基础
squash d4e5f6g D2（修复拼写错误）# 将 D2 合并到上一个提交（D1）
squash 7h8i9j0 D3（补充注释） # 将 D3 合并到上一个提交（合并后的 D1）

2. 整理后的提交历史图示

保存并退出编辑器后，Git 会合并 3 个提交，让你编辑最终的提交信息（比如改为“完成功能C开发”），最终历史变成：

feature:  C4 → D（完成功能C开发）  # D 是合并 D1、D2、D3 后的新提交

原本杂乱的 3 个提交，变成了 1 个清晰的提交，历史更简洁！

四、rebase vs merge：核心区别图示对比

假设我们有以下初始状态：

• main 分支有提交 C1 → C2 → C3 → C4（C4 是最新提交）
• feature 分支基于 C3 创建，有提交 D1 → D2

main:    C1 → C2 → C3 → C4  （主分支新增 C4）
                   ↓
feature:           D1 → D2  （开发分支基于 C3，未包含 C4）

五、关键注意事项（图示提醒）

绝对不要对“已推送到远程的公共分支”执行 rebase！
比如 main 是团队共享分支，你已将 C4 推送到远程，若强行 rebase main 并推送：

# 错误操作后，远程 main 历史被改写：
远程原历史：C1→C2→C3→C4
你的本地 rebase 后：C1→C2→C3→X→Y（改写了 C4 之后的历史）
推送后远程变成：C1→C2→C3→X→Y  （原 C4 被覆盖）

其他同事拉取时会发现本地历史与远程冲突，导致协作混乱！

总结

通过图示能清晰看到：rebase 的核心是“改变提交的基础，重新应用提交”，最终实现“线性化提交历史”。关键用在两个场景：

1. 同步其他分支的更新（如 feature 同步 main），避免 merge 节点；
2. 整理本地未推送的提交（rebase -i），让历史更整洁。
   记住“公共分支不 rebase，本地分支可放心用”的原则即可。

---

git branch -r ：查看远程分支

git log --oneline --decorate --graph：如果你想要验证 test-branch 是否确实是从 dev 分支创建的，可以通过查看分支的历史记录来确认

git log：查看提交历史 q：退出查看历史【在执行完 git log 后，输入 q 可退出】

git reset --hard HEAD~1：回退到上一个版本

git reset --hard：强制重置当前分支到指定的提交，丢弃所有未提交的更改。【例如：git reset --hard origin/dev】

git branch -vv：查看本地分支与远程分支的关联关系

Gitmoji 为提交类型分配表情符号

Gitmoji 是一个开源项目，旨在标准化和解释在 GitHub 提交消息上使用 emoji 的规范。它通过为常见的提交类型分配特定的表情符号，帮助开发者快速识别提交的目的或意图，从而使提交历史更加清晰和易于理解。

主要特点

• 标准化提交信息：每个 emoji 都代表特定的提交类型，如修复错误（🐛）、新增功能（✨）、优化性能（⚡️）等。
• 提高沟通效率：团队成员可以通过表情符号快速了解提交的性质，无需阅读冗长的描述。
• 工具支持：提供了 gitmoji-cli 等工具，方便开发者在命令行中使用 emoji。此外，还有适用于 Visual Studio Code 和 IntelliJ IDEA 等开发环境的插件。

使用方法

• 安装工具：可以通过命令 npm i -g gitmoji-cli 安装 gitmoji-cli。
• 提交信息：在执行 git commit 时，使用对应的 emoji 或其代码来描述提交内容。例如，git commit -m ':bug: fix login issue'。
• 配置插件：在支持的开发环境中安装并配置 Gitmoji 插件，以便在提交时自动提示和插入 emoji。

优势

• 增强可读性：使提交历史更加直观，便于团队成员快速浏览和理解。
• 规范提交历史：有助于保持提交信息的一致性，便于项目管理和维护。
• 提升团队协作：通过标准化的提交信息，提高团队内部的沟通效率。

示例

以下是一些常见的 Gitmoji 表情符号及其含义：

Emoji	代码	描述
✨	:sparkles:	新功能
🐛	:bug:	修复错误
📝	:memo:	撰写文档
⚡️	:zap:	提升性能

通过使用 Gitmoji，开发者可以更高效地记录和理解代码变更，同时为团队协作带来便利。

【持续更新ing…】