Git 命令行学习笔记：从入门到精通

求助

● 官方文档：https://git-scm.com/docs
● git help：利用 Git 帮助系统提升开发效率
● 掌握 Git 配置：个性化和优化你的 Git 环境

---

Git 主要是解决什么问题的？

● 版本控制：
以前遗留问题：手动保存多个版本易混乱，无法快速定位变更。
git解决方案：自动记录每次代码变更（commit），精确到修改内容、作者、时间。支持查看任意时间点的代码快照，轻松回滚到历史版本。

● 分支管理：
以前遗留问题：开发新功能或尝试实验性改动时，可能污染主分支代码。
git解决方案：允许开发者在不影响主分支的情况下进行实验性开发。

● 协作开发：
以前遗留问题：依赖网络的版本控制系统（如 SVN）在离线时无法提交或查看历史。
git解决方案：Git的分布式特性允许每个开发者在本地进行开发，然后将更改推送到共享的仓库中。这避免了集中式版本控制系统中常见的等待合并和冲突问题。

● 冲突解决：
当多个开发者同时修改同一部分代码时，Git能够检测到冲突并提供工具帮助解决这些冲突，确保代码的完整性和一致性。

● 代码审查：
以前遗留问题：直接向主分支提交代码可能导致质量不稳定。
git解决方案：开发者可以先在自己的分支上进行开发，然后通过 Pull Request的方式提交代码，由其他团队成员进行审查和测试，确保代码质量。

● 数据完整性：
Git使用SHA-1哈希算法来确保数据的完整性和一致性，每次提交都会生成一个唯一的哈希值，这有助于防止数据的意外损坏或篡改。

多人多版本开发是现代软件开发中常见的协作模式，尤其在分布式团队和大型项目中。
● 针对多版本，Git有版本控制。
● 针对多人开发，Git有分支管理，然后还可以本地开发，代码合并时还支持代码审查。
● 功能增强上，Git自身还可以支持冲突解决和数据完整性。

版本控制

● Git 版本控制的核心：快照、提交与引用

● git commit：提交的最佳实践与技巧
● git lfs：高效处理大文件和二进制数据

● git reset：灵活回滚与撤销更改
● git revert：Git 撤销提交

● 代码回溯：Git log/reflog/blame/show 使用技巧

● git status：Git 文件状态检查
● git diff：比较和审查代码变更

● 快速构造1个文件的10个commit
● 快速构造10个文件

● git rev-parse HEAD 返回当前分支最新提交的完整 SHA-1 哈希值
● git rev-parse main 返回 main 分支对应的提交哈希。
● git rev-parse --short HEAD 获取简短的提交哈希（默认为7个字符）
● git rev-parse --symbolic-full-name HEAD 获取所在分支名称

分支管理

●创建分支

●删除分支
●git prune：清理过期引用

●重命名远程分支

●查看分支
●查看分支拉取来源
●切换分支

● git tag：标记和管理代码版本

● git archive：创建和导出项目压缩包

协作开发

● Git 仓库管理基础：初始化与克隆（SSH vs HTTPS）
● git stash：保存、应用与管理临时更改

代码整合

Merge（合并）

作用：Merge将一个分支的所有更改合并到另一个分支。
特点：Merge保留了分支的历史：A->B合并后B分支将具有多头历史（最近共同祖先到合并节点A的所有提交的历史+最近共同祖先到合并节点B的所有提交的历史）

（heads/dev） git merge release 的详细工作原理
1、保存当前工作状态：在开始merge之前，Git会检查你是否有未提交的更改。
2、快进检查（Fast-Forward Check）
3、Git首先确定dev和release分支的最近共同祖先提交。比较dev分支最新提交和release分支最新提交相对于基点的更改，来检测哪些文件和行存在冲突。Git会尝试自动解决这些冲突，但当冲突无法自动解决时，Git会停止合并过程，并标记出冲突的文件。即三路合并（Three-Way Merge）。
4、Git 会创建一个新的合并提交，并更新dev的指针（HEAD），使其指向新的提交。

●（heads/release） git merge 3fa326a 3fa326a → heads/release
●（heads/release） git merge dev heads/dev → heads/release
●（heads/release） git merge origin/dev origin/dev→ heads/release
●（heads/release） git merge origin/release → heads/release
●（heads/dev） git merge origin release origin/main → heads/dev & heads/release → heads/dev 避坑
●（heads/dev） git merge origin 错误用法 避坑

merge发生冲突时☞撤销merge
●git merge --abort
●git reset --hard HEAD
●git reset --hard ORIG_HEAD
merge发生冲突时 ☞ 解决冲突
●git merge --continue
●git add . 然后 git commit -m "merge conflict and fix"

●Git 合并模式 vs 合并策略：学习笔记

● 特性分支 回合 主干分支代码 超神推荐

---

Squash Merge（压缩合并）

作用：Squash Merge 不是合并策略，而是一个合并选项。它将多个提交压缩成一个单一的提交，然后再将其合并到目标分支中。
特点：这种方式有助于保持简洁的历史记录，并且可以避免引入大量的中间提交。

(heads/dev) git --squash master 详细工作原理
1、保存当前工作状态：在开始squash Merge之前，Git会检查你是否有未提交的更改。
2、Git 首先会找到dev和master的最近共同祖先提交（common ancestor）。然后从最近共同祖先提交到master最新提交的每个提交都会被转换为一个补丁，然后将这些补丁汇总成一个单一的补丁文件。这个过程称为“压缩”（squash），并将这个补丁应用到当前分支上，创建一个新的提交（注意仅为普通提交，非合并提交）。
3、Git 会更新dev的指针（HEAD），使其指向新的提交。
4、Git 会提示你输入一个新的提交信息，用于描述这个压缩后的提交。

● squash merge 组合用法

(heads/A) git checkout B
(heads/B) git merge --squash A
(heads/B) git commit -m "squash commit msg"

---

Rebase（变基）

作用：Rebase将一个分支的所有更改重新应用到另一个分支的最新状态上。
特点：Rebase会改变提交历史，使你的分支看起来像是在目标分支的最新提交之后创建的。

(heads/dev) git rebase master 详细工作原理
1、保存当前工作状态：在开始rebase之前，Git会检查你是否有未提交的更改。
2、Git 首先会找到dev和master分支的最近共同祖先提交。把共同祖先提交到dev最新提交的每个提交都换为一个补丁，并将这些补丁依次应用到master的最新提交上。如果在应用某个补丁时发生冲突，Git 会暂停 Rebase 过程，并提示你手动解决冲突。解决冲突后，你可以继续 Rebase 操作。
3、所有补丁成功应用后，Git 会更新dev的指针（HEAD），使其指向新的提交。
4、由于 Rebase 会重写提交历史，推送时需用 git push --force-with-lease，以确保不会覆盖其他开发者的更改。

●(heads/dev) git rebase origin/release
●(heads/dev) git rebase -i origin/release 交互式地rebase

git rebase发生冲突时 ☞ 撤销rebase
●git rebase --abort

git rebase发生冲突时 ☞ 解决冲突
●git add . 然后 git rebase --continue

●一次基于 rebase 的 PR 提交
●rebase导致源分支修改丢失

---

Cherry-Pick（挑选）

作用：用于将一个或多个特定的提交从一个分支应用到另一个分支。它的主要作用是选择性地合并提交，而不是合并整个分支。
特点： 与 merge 和 rebase 不同，cherry-pick 只处理单个或多个指定的提交，而不是整个分支的历史。

（heads/dev） git cherry-pick 125a1d1 的详细工作原理
1、保存当前工作状态：在开始Cherry-Pick之前，Git会检查你是否有未提交的更改。
2、Git 读取 125a1d1 的提交对象，提取其父提交的哈希值 abc1234，比较 125a1d1 和 abc1234 之间的差异，生成一个补丁文件，并将这个补丁应用到当前分支 dev 的最新提交（HEAD）之上，如果有冲突，Git 会在冲突文件中标记冲突区域，并暂停 cherry-pick。
3、Git 在 dev 分支上创建一个新的提交，并更新当前分支的指针（HEAD），使其指向新的提交。

●（heads/dev） git cherry-pick 125a1d1 heads/125a1d1 → heads/dev
●（heads/dev） git cherry-pick release heads/release → heads/dev
●（heads/dev） git cherry-pick origin/release origin/release → heads/dev

●（dev） git cherry-pick 125a1d1 125a2a1 heads/125a1d1 → heads/dev & heads/125a2a1 → heads/dev
●（dev） git cherry-pick A..B 转移连续提交（不包含A）(提交A须早于提交B,否则命令将失败,但不会报错)
●（dev） git cherry-pick A^..B 转移连续提交（包含A） (提交A须早于提交B,否则命令将失败,但不会报错)

●git cherry-pick 125a1d1 -e 打开外部编辑器编辑提交信息. 即 --edit
●git cherry-pick 125a1d1 -x 在提交信息的末尾追加一行(cherry picked from commit ...)
●git cherry-pick 125a1d1 -s 在提交信息的末尾追加一行操作者的签名. 即 --signoff
●git cherry-pick 125a1d1 -n 不提交只更新工作区和暂存区. 即 --no-commit
●git cherry-pick -m 1 125a1d1 如125a1d是合并节点,cherry-pick将失败,因不知该用哪个分支的代码变动. 1和2的表示的分支: A(2) merge into B(1)

●git cherry-pick发生冲突时 ☞ 会停下来让用户决定如何继续操作 ☞ 撤销cherry-pick
git cherry-pick --abort
●git cherry-pick发生冲突时 ☞ 会停下来让用户决定如何继续操作 ☞ 解决冲突
git add . 然后 git cherry-pick --continue

●git cherry-pick 其他代码仓库代码

---

远程同步

● Git 的引用规格（refspec）语法
● Git 远程仓库基础：理解 Remote Name 和 Remote Branch
● Git 远程仓库别名的管理和配置
● Git 远程仓库别名详解：Upstream vs Origin

● ssh -T git@gitcode.com ：用于验证 SSH 连接和密钥配置是否正确。通过禁用伪终端分配，它可以快速、简洁地确认你能否成功连接到 GitCode 服务器。
ssh: 使用 SSH 协议连接到远程服务器。
-T: 禁用伪终端分配（pseudo-tty allocation）。这通常用于防止远程服务器启动交互式 shell，从而加快连接速度并简化输出。
git@gitcode.com: 指定要连接的用户和主机。git 是 GitCode 上的标准用户名，gitcode.com 是 GitCode 的域名。

Fetch

作用：拉取远程仓库最新内容，但是仅仅拉取过来先不使用 → 详细学习笔记

git fetch 的执行过程
1、根据远程仓库名称（如 origin）找到对应的远程仓库 URL。
2、拉取所有远程分支和标签相关的新提交对象(最新提交及这些提交的历史记录)，以及这些提交所依赖的对象。存储在本地的.git/objects目录下。
3、获取远程引用（如分支、标签等）最新提交哈希值。
4、更新本地远程跟踪分支。存储在本地的.git/refs/remotes/origin/ 目录下。
5、拉取所有远程标签。 存储在本地的.git/refs/tags/ 目录下。
6、Git 会将所有拉取到的引用（包括分支和标签）的最新提交信息写入 .git/FETCH_HEAD 文件。

●git fetch origin release:dev
●git fetch origin release1 release2
●git fetch origin
●git fetch

Pull

作用：从服务端远程仓库拉取最新的更改并将其合并到客户端当前分支 → 详细学习笔记

(heads/main) git pull origin release:dev 的执行过程
●如果本地没有 dev 分支，Git 会创建一个新的 dev 分支并将其与远程 release 分支同步。
●如果本地已有 dev 分支
2.1. 如果 dev 分支上有未提交的更改 → Git 会提示你先提交或暂存这些更改，然后再进行合并。
2.2. 如果 dev 分支与远程 release 分支有冲突 → Git 会暂停合并操作并提示你需要手动解决冲突。
2.3. 如果 dev 分支与远程 release 分支无冲突 → 满足 Fast-Forward 合并则进行Fast-Forward合并，否则产生merge节点。

●(heads/main) git pull origin release:dev (heads/main) origin/release → heads/dev
●(heads/dev) git pull origin release (heads/dev) origin/release → heads/dev
●(heads/release) git pull origin (heads/release) origin/release → heads/release
●(heads/release) git pull (heads/release) origin/release → heads/release

Push

作用：将客户端本地仓库中的更改推送到服务端远程仓库的命令 → 详细学习笔记

(heads/main)git push -u origin release 执行过程
1、Git 会检查当前工作区是否有未提交的更改。如果有未提交的更改，Git 会提示你先提交或暂存这些更改。
2、Git 尝试连接到远程仓库 origin。根据配置的不同，可能会要求输入用户名和密码、SSH 密钥或其他形式的认证。
3、Git 比较本地 release 分支和远程 origin/release 分支的提交历史。如果本地有新的提交，Git 会尝试将这些提交推送到远程仓库（包括新增的提交及其相关对象）。
4、-u 或 --set-upstream 参数用于设置上游分支。这会在本地配置文件中添加一个条目，将本地 release 分支与远程 origin/release 分支关联起来。
5、反馈成功或失败提示信息。

●(heads/main) git push -u origin release:release1首次
●(heads/main) git push origin release:release1
●(heads/main) git push -u origin release 首次
●(heads/main) git push origin release
●(heads/release) git push origin
●(heads/release) git push

●git 本地分支 和 远程分支 恰巧重名时 如何push

---