兰 亭 墨 苑
期货 · 量化 · AI · 终身学习
首页
归档
编辑文章
标题 *
URL 别名 *
内容 *
(支持 Markdown 格式)
### git的常用功能 下面依次说明你在 VS Code(或 GitLens)中看到的这些操作都是什么意思,以及它们在底层对应的大致 Git 命令。 1. Cherry-pick this (22427fe) commit into current branch • 含义:把指定提交(22427fe)里的改动“摘樱桃”式地复制到当前分支。 • 等价命令: ```bash git cherry-pick 22427fe ``` • 场景:当你在 feature 分支上,但想把某个提交的修复或功能合并到当前分支,而不是整体合并整个分支时。 2. Checkout (22427fe) commit • 含义:检出到该提交对应的快照,HEAD 直接指向这个提交。 • 等价命令: ```bash git checkout 22427fe ``` • 注意:你进入了 “detached HEAD” 状态,之后的改动不会附着到任何分支,除非你新建分支或切回已有分支。 3. Select this commit • 含义:在 UI 中将这个提交标记为 “当前选中”,方便后续做差异比较、两次提交对比等操作。 • 并不直接执行 Git 命令,只是视觉/状态上的 “选中” 标记,用于后续右键→Compare with Selected 之类的功能。 4. Revert this (22427fe) commit • 含义:生成一个新的 “反向提交”,撤销 22427fe 这个提交所做的改动。 • 等价命令: ```bash git revert 22427fe ``` • 注意:revert 会创建一个新的提交来“回滚”,不会修改历史。 5. Merge this (22427fe) commit into current branch • 含义:如果这个提交所在的分支与你当前分支有共同祖先,就把它们合并过来。 • 等价命令(假设 22427fe 在分支 feature 上): ```bash git merge feature ``` • 场景:直接将包含该提交的整个分支合并进来。 6. Rebase current branch onto this (22427fe) commit • 含义:把当前分支上比 22427fe 新的所有提交,全部“提取”出来,依次附加到 22427fe 之后。 • 等价命令: ```bash git rebase --onto 22427fe <base> <current-branch> ``` (其中 `<base>` 是当前分支和目标分支的共同祖先) • 场景:用来“挪动”历史,把你当前的提交放到另一条线上。 --- 此外在每个提交旁边你也看到 “Soft”/“Hard”/“Tag”/“Branch”/“More”: - Soft:`git reset --soft <commit>`,将 HEAD 回退到该提交,但保留暂存区和工作区改动。 - Hard:`git reset --hard <commit>`,将 HEAD、暂存区和工作区都回退到该提交,所有后续改动丢弃。 - Tag:在该提交上打一个标签 `git tag <tagname> 22427fe`。 - Branch:从该提交创建一个新分支 `git branch <new-branch> 22427fe`。 - More:展开更多操作,比如 `stash`、`cherry-pick —skip`、`interactive rebase here` 等。 理解了这些之后,你可以根据需要: • 选中某个提交来比较差异; • cherry-pick 复用单个提交; • revert 安全地回滚; • reset 切换或擦除历史; • merge/rebase 管理分支整合; • 打 tag/新建分支做里程碑管理。 ### detached状态下的修改的合并 不完全是这样。让我们仔细分情况说清楚: 1. 你在 detached HEAD 下**提交**(`git commit`) - 这些提交**不属于**任何分支,只是“悬挂”的提交。 - 如果你直接 `git checkout main`,HEAD 会指向 main 分支最新的提交,工作区也会切换到 main 的内容。 - 那些“悬挂”的提交并不会被带到 main 上——除非你显式地把它们合并或 cherry-pick 到 main。 - 并且,因为它们没有任何分支引用,如果你长时间不引用它们,Git 可能会在垃圾回收时清理掉它们。 2. 你在 detached HEAD 下**修改但未提交** - 在工作区里,这些改动是本地文件状态,切到 main 时,Git 会尝试把这些改动“保留”到新分支的工作区。 - 如果冲突,Git 会提示你先 stash 或放弃改动。 - 这时改动并没有 commit,等于是“带着”未提交的工作区切换到 main,你可以在 main 上继续提交。 —— 要想把 detached HEAD 下的**已提交**改动安全地带到 main,你有几个选项: 1. 在 detached HEAD 下创建一个新分支,保住这些提交: ```bash git checkout -b fix-from-detached # 这样 fix-from-detached 就指向那些 commit 了 git checkout main git merge fix-from-detached ``` 2. 或者在 main 上 cherry-pick 那些提交: ```bash # 假设 detached 下你做了两个提交 a1b2c3、d4e5f6 git checkout main git cherry-pick a1b2c3 d4e5f6 ``` 3. 如果只是未提交的本地修改,也可以在切分支前直接 `git checkout main`(Git 会保留未提交改动,前提是它们不与 main 的快照冲突),然后再 `git commit`。 总之: • **在 detached HEAD 下的已提交**改动,不会自动成为 main 的一部分; • **未提交**的改动会跟随工作区一起切换。 要把 detached 下的提交真正并入 main,必须通过创建分支、merge 或 cherry-pick。 ### cherrypick ### 两种merge方式 “Merge this (22427fe) commit into current branch” 和直接 cherry-pick 一个提交,表面上都是把那次改动带到当前分支,但底层机制和结果有以下区别: 1. 作用范围 • git merge feature – 会把 feature 分支从共同祖先到最新的**所有**提交,一并合并到当前分支。 – 如果 feature 上有 A→B→C→…→22427fe→…→Z 这么一条历史,merge 会把 A/B/C…/Z 全部合并进来。 • git cherry-pick 22427fe – 只“摘取”22427fe 这一次提交的 diff,并在当前分支生成一个新的、内容等价但 SHA 不同的提交。 – feature 分支上其他提交(A、B、C、…、Z 除了 22427fe)都不会被带过来。 2. 历史可读性 • merge 会在当前分支生成一个合并提交(如果非 fast-forward),清晰地保留两条分支历史,并标记出分支是何时汇合的。 • cherry-pick 则是把那次提交“复制”过来,无法反映它原先在 feature 分支的上下文——只是单纯地在当前分支打了个补丁。 3. 冲突处理 • merge:如果 feature 分支上有多次提交与你当前分支都修改了同一行,Git 会在一次合并过程中一次性让你解决所有冲突。 • cherry-pick:只对 22427fe 这次提交中产生冲突的部分做冲突提示,其它提交的不在本次操作范围内。 4. 后续同步 • merge:后面如果 feature 又有新提交,你可以再一次 merge,把剩下的提交合并进来。 • cherry-pick:你需要对每一个新的提交都重复 cherry-pick 操作,或者合并整个分支。 总结 - 如果你**只想拿**某一次“单颗樱桃”(即单独的修复/功能),而不想把整个分支历史都带过来,就用 `git cherry-pick 22427fe`。 - 如果你想把 feature 分支的**完整**历史和当前分支进行汇合,就用 `git merge feature`(它会包含22427fe以及前后所有提交)。
配图 (可多选)
选择新图片文件或拖拽到此处
标签
更新文章
删除文章