IDEA 中常用操作记载
- git
-
- [git pull/git fetch](#git pull/git fetch)
-
- [1. `git fetch` ------ 只下载，不改动](#1.
git fetch—— 只下载，不改动) - [2. `git pull` ------ 下载 + 合并](#2.
git pull—— 下载 + 合并)
- [1. `git fetch` ------ 只下载，不改动](#1.
- [git merge 和 git rebase](#git merge 和 git rebase)
-
- [核心操作：git rebase（重点）](#核心操作：git rebase（重点）)
- [其他常用 Git 操作速查](#其他常用 Git 操作速查)
- [git cherry-pick](#git cherry-pick)
- 二级目录
git
git pull/git fetch
1. git fetch ------ 只下载，不改动
bash
git fetch origin # 下载远程所有分支的更新
git fetch origin main # 只下载远程 main 分支作用 ：从远程仓库下载最新的提交、分支、标签 到本地的"远程跟踪分支"（如 origin/main），但完全不改动你当前的工作区分支、暂存区和本地分支。
特点：
- ✅ 绝对安全：随便执行，不会产生冲突，也不会丢失本地改动
- 👀 让你先"看看"远程有什么新东西，再决定是否合并
- 通常作为
git pull的前置步骤，或者用于git diff origin/main对比差异
2. git pull ------ 下载 + 合并
bash
git pull origin main # 等价于：git fetch origin main + git merge origin/main
git pull --rebase origin main # 等价于：git fetch + git rebase（推荐，历史更干净）作用 ：先 fetch 下载远程更新，然后立即将远程分支合并（或变基）到当前本地分支。
特点：
- ⚠️ 可能产生冲突：如果本地有未推送的提交，且和远程改动改了同一处，就会冲突，需要手动解决
- 🤖 一步到位，省事但风险稍高
- 建议使用
git pull --rebase替代默认的git pull，避免产生多余的合并提交
git merge 和 git rebase
git merge 会产生一个合并提交 commit, git rebase 会将你改动的 commit，放到 rebase 分支的最新的 commit之后。
核心操作：git rebase（重点）
简单说，git rebase 就是把一串提交"搬家"到另一个基点上，主要是为了让提交历史更干净、线性 ，而不是像 git merge 那样会产生分叉。
它最常见的用法有两类：
-
更新分支（同步主分支）：在功能分支上开发时，用它把主分支的新提交接过来，避免后面合并时出现杂乱的"合并提交"。
bash# 先切换到你的功能分支，然后变基到 main 分支的最新提交上 git checkout feature-branch git rebase main -
整理历史（交互式变基）：这是你笔记里提到的核心用法，用来合并、修改或删除最近的几个提交。比如想整理最近 3 个提交：
bashgit rebase -i HEAD~3在打开的编辑器里，把想合并的提交前面的
pick改成squash（或s），保存就行。
⚠️ 黄金法则 ：永远不要对已经推送到公共仓库、别人可能正在使用的分支执行变基。因为变基会重写提交历史，会给团队协作带来大麻烦。
其他常用 Git 操作速查
1. 提交与修改
git commit --amend：修改最近一次提交的 message 或内容（未推送前使用）。git reset HEAD~1：撤销最近一次提交，但保留改动在本地（谨慎使用--hard参数，它会彻底丢弃改动）。
2. 差异对比
git diff：工作区 vs 暂存区（你笔记里提过）。git diff --cached或--staged：暂存区 vs 最新提交 (HEAD)。git diff HEAD：工作区 vs 最新提交。
3. 分支与合并
git branch -d <分支名>：删除本地已合并的分支。git merge <分支名>：将指定分支合并到当前分支（会产生一个合并提交）。
4. 远程同步
git pull --rebase：拉取远程更新，并用 rebase 方式将本地提交接到最新历史后面，可避免产生合并提交。
git cherry-pick
一个非常实用的命令，它的作用是把某个分支上的一个或多个特定提交，复制到当前分支上来。相当于"精准捡漏"，只挑你需要的提交，而不合并整个分支。
常用场景
- 紧急修复 ：比如你在
develop分支修了个 Bug，但main生产分支急着要，直接合并整个develop太危险，只把那个 Bug 修复的提交挑过来就行。 - 跨分支同步：不同分支之间只想复用某几个提交的内容。
- 撤销重做 ：不小心在错误分支上提交了，可以用
cherry-pick把它移到正确分支。
基本用法
bash
# 拣选单个提交（复制到当前分支）
git cherry-pick <commit-hash>
# 拣选多个提交（按顺序应用）
git cherry-pick <hash1> <hash2> <hash3>
# 拣选一个连续范围（不包含 hash1，包含 hash2）
git cherry-pick <hash1>..<hash2>
# 拣选时只把改动加入暂存区，但不自动提交（方便手动调整）
git cherry-pick -n <commit-hash> # -n 是 --no-commit 的简写处理冲突
和 merge/rebase 一样，cherry-pick 也可能冲突。解决完冲突后：
bash
# 手动解决冲突文件，然后：
git add .
git cherry-pick --continue # 继续完成拣选如果想放弃本次拣选：
bash
git cherry-pick --abort与 rebase 的关联
你关心的 rebase 和 cherry-pick 其实有深层联系------rebase 底层机制就是反复执行 cherry-pick。
比如 git rebase main 的本质是：
- 找出当前分支相对于
main的所有独有提交 - 把这些提交按顺序逐个
cherry-pick到main的最新提交之上 - 最后把旧分支指针指向新位置
所以可以这样理解：rebase 是批量自动化 的 cherry-pick，而 cherry-pick 是手动精准的单个提交复制。