【自用】git常用操作

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 分支
   

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
   

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

常用指令

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

执行步骤：

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 分支并合并到当前分支

理解 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：查看本地分支与远程分支的关联关系

【持续更新ing…】