Git 常用命令、工作流程以及原理剖析

1. 创建Java项目: spring-ai

2. 用命令行进入项目: cd spring-ai

3. git 初始化: git init

3. git add .

4. git commit -m "初始化项目提交"

5. git push -u origin master

6. 提示输入用户名和密码

7. 上传成功

二、常用命令

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

2. 查看已有本地及远程分支：git branch -a（先git pull拉下全部数据）

3. 查看远程分支：git branch -r

4. 查看所有分支：git branch -a

5. 查看本地分支：git branch

6. 删除远程dev分支：git push origin --delete dev

7. 删除本地dev分支：git branch -d dev

8. 从远程的origin仓库的master分支下载到本地，并新建一个test分支：git fetch origin master:test

9. 本地从当前所在分支上创建一个新分支：git checkout -b 新分支名

10. 查看test分支与本地原有分支的不同：git diff test

11. 将test分支和当前分支合并：git merge test

12. 将远程git仓库里的指定分支拉取到本地（本地不存在的分支）：

git checkout -b 本地分支 origin/远程分支，或者 git pull origin dev(remote):dev(local)

13. 将本地master分支提交到远程dev分支：git push origin master:dev

三、常见报错处理

1. 拉取代码错误 error: You have not concluded your merge (MERGE_HEAD exists)

可能以前pull下来的代码自动合并失败

解决方案一：保留本地的更改，中止合并->重新合并->重新拉取

$:git merge --abort

$:git reset --merge

$:git pull （重新解决冲突后再push）

解决方案二：舍弃本地代码，远端版本覆盖本地版本

$:git fetch --all

$:git reset --hard origin/master

$:git fetch

Git fetch和git pull的区别：

1. 都可以从远程获取最新版本到本地

2. git fetch：只是从远程获取最新版本到本地，不会merge(合并)

3. git pull：从远程获取最新版本并merge(合并)到本地

2. 克隆代码错误 permission denied

1. SSH 密钥问题

生成新的 SSH 密钥‌: ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
‌检查 SSH 密钥是否正确设置‌: ssh -T git@github.com # 替换成你的 Git 服务对应的地址

2. 使用了错误的用户或凭证

检查您的 git 配置

git config user.name
git config user.email

3. Git 凭证缓存问题

如果你之前成功登录过一次，但是后来忘记了，Git 可能还在使用旧的缓存的凭证。

解决办法：清除 git 凭证缓存

git credential-manager uninstall # 对于 Windows 的 Git Credential Manager Core
git config --global --unset credential.helper # 全局取消凭证缓存

Git 工作流程

📊 从协作规范到数据内核

Git不仅是代码的时光机，更是团队协作的精密协议。从日常的git add/commit到复杂的多分支管理，其背后是一套严谨的数据结构和精妙的协作哲学。

📦 Git的三层架构：工作区、暂存区与仓库

理解Git的第一步是掌握其核心的三区模型，这构成了所有操作的基础框架。

🔍 核心区域详解

1. 工作区 (Working Directory)

就是你电脑上看到的项目目录，在这里直接编辑文件。所有修改最初都发生在这里。

2. 暂存区 (Staging Area/Index)

一个临时的缓存区域，通过git add将工作区的改动“暂存”于此，准备形成一次完整的提交。

3.本地仓库 (Local Repository)

存储所有提交历史的地方，位于项目根目录的.git/隐藏文件夹中。执行git commit后，暂存区的内容会永久保存于此。

💡 日常命令流转

→git add：将工作区的修改放入暂存区

→git commit：将暂存区的内容永久保存到本地仓库

→git push：将本地仓库的提交推送到远程仓库

→git pull/fetch：从远程仓库获取更新到本地

🔄 主流Git工作流对比

不同的团队和项目规模需要不同的协作规范。以下是三种最广泛采用的工作流模式。

📊 工作流选择矩阵

工作流核心特点分支策略适用场景

Git Flow 双长期分支（master/develop）+ 三种短期分支功能分支 → develop → release → master 传统版本发布项目，需要严格的分支管理

GitHub Flow 单一主分支，简化流程功能分支 → Pull Request → master 持续部署的Web应用，简单高效

GitLab Flow “上游优先”原则，环境分支 master → pre-production → production 需要多环境部署的企业级应用

工作流	核心特点	分支策略	适用场景
Git Flow	双长期分支（master/develop）+ 三种短期分支	功能分支 → develop → release → master	传统版本发布项目，需要严格的分支管理
GitHub Flow	单一主分支，简化流程	功能分支 → Pull Request → master	持续部署的Web应用，简单高效
GitLab Flow	“上游优先”原则，环境分支	master → pre-production → production	需要多环境部署的企业级应用

🎯 Git Flow：经典但复杂

Git Flow是最早被广泛采用的工作流，它定义了清晰但相对复杂的分支模型：

长期分支：master（稳定版）和 develop（开发版）

短期分支：feature（新功能）、hotfix（紧急修复）、release（预发布）

流程：功能在feature分支开发，完成后合并到develop，经过release分支测试后最终合并到master

适合需要严格控制发布周期的传统软件项目，但维护成本较高。

⚡ GitHub Flow：持续发布的极简主义

GitHub Flow是Git Flow的简化版，专为持续发布设计：

单一主分支：只有master分支，代表当前生产环境

功能开发：从master创建新分支，开发完成后发起Pull Request

代码评审：通过PR进行讨论和代码审查

合并部署：PR通过后合并到master并立即部署

假设master分支的代码随时可发布，适合现代Web应用的快速迭代。

Git 底层原理

⚙️ Git底层原理：对象模型与存储机制

Git的强大源于其精巧的底层设计。理解四种核心对象和存储机制，才能真正掌握Git的精髓。

🧩 四种核心对象

📄 Blob对象

存储单个文件的内容，但不包含文件名、权限等元数据。每个文件对应一个Blob，相同内容的文件共享同一个Blob对象以节省空间。

📁 Tree对象

对应文件系统的目录结构，记录目录中包含的文件和子目录。Tree对象引用Blob对象（文件）和其他Tree对象（子目录），形成层次结构。

💾 Commit对象

一次提交的快照，包含作者、提交者、时间戳、提交信息，以及指向一个Tree对象（代表项目根目录）和父Commit的指针。形成版本历史链。

🏷️ Tag对象

指向特定Commit的不可变引用，用于标记重要版本（如v1.0.0）。分为轻量标签（直接指向Commit）和附注标签（独立的Tag对象）。

🔍 对象关系示例

Commit: abc123

├── Tree: def456 (项目根目录)

├── Blob: ghi789 (README.md内容)

├── Tree: jkl012 (src目录)

└── Blob: mno345 (main.py内容)

└── Parent: xyz789 (上一个Commit)

每个对象都由SHA-1哈希值唯一标识，内容相同的对象哈希值也相同，实现了高效存储。

💾 Git的存储引擎：从松散对象到包文件

Git的存储设计是其高效性的核心。对象最初以松散形式存储，最终会被打包压缩以优化空间和传输效率。

📦 Pack文件机制

当执行git gc（垃圾回收）或推送到远程仓库时，Git会将多个松散对象打包成.pack文件：

增量存储：相似的对象只存储差异(delta)，大幅减少空间占用

索引文件：.idx文件提供快速的对象查找，通过SHA-1哈希直接定位

Zlib压缩：所有对象数据都经过压缩存储

校验和：文件尾部包含校验和，确保数据完整性

# 查看pack文件内容

$ git verify-pack -v .git/objects/pack/pack-*.pack

显示每个对象的类型、大小、在pack文件中的偏移量等信息

🚀 高级工作流：Monorepo下的选择

在大型单体代码库(Monorepo)中，传统的Git工作流可能面临挑战。Feature Branch和Trunk-Based是两种主要的开发模式。

维度	Feature Branch Development	Trunk-Based Development
分支策略	长期功能分支，完成后合并	短期分支，小步快跑，频繁合并
合并频率	较低，功能完整后一次性合并	极高，每天多次合并到主干
冲突处理	合并时可能面临大量冲突	小改动减少冲突概率
集成测试	功能完成后进行	持续集成，每次提交都测试
适用场景	小型项目，功能相对独立	大型Monorepo，需要高频集成

🎯 Trunk-Based的核心实践

Trunk-Based开发强调小批量、高频率的代码提交，这需要配套的工程实践：

🔀 功能开关

未完成的功能通过配置开关隐藏，允许代码提前合并而不影响用户

⚡持续集成

每次提交都触发完整的构建和测试流程，快速反馈问题

📋 代码审查

小型变更更易于审查，提高代码质量和知识共享

🚦 自动化部署

主干始终保持可部署状态，支持持续交付

💡 实践建议与最佳实践

无论选择哪种工作流，以下实践都能显著提升Git使用效率。

🛡️ 保护主分支

主分支（master/main）应该受到保护，不是每个开发者都能直接推送。使用Pull Request/Merge Request机制，要求至少一人审查通过后才能合并。

GitHub/GitLab分支保护设置
# GitHub示例：要求PR通过检查后才能合并
- Require pull request reviews before merging
- Require status checks to pass before merging
- Include administrators (可选)

# GitLab示例：保护分支设置
- Allowed to merge: Maintainers
- Allowed to push: No one (保护时)
- Require approval from: 1+ approvers

📝 提交规范与Issue联动

良好的提交习惯能让历史清晰可读。建议每个功能分支对应一个Issue，提交信息中引用Issue编号。

分支命名：feature/15-add-user-auth或fix/42-login-error

提交信息：使用约定式提交，如feat: add user authentication

关闭Issue：提交信息中包含fixes #15或closes #42可自动关闭Issue

合并选项：使用--no-ff保留合并节点，便于跟踪历史

🧹 保持历史整洁

在发起Pull Request前，可以考虑整理提交历史：

交互式变基整理提交
# 合并最近3次提交
git rebase -i HEAD~3

# 在编辑器中：
# pick 保留提交
# squash 合并到前一个提交
# fixup 合并并丢弃提交信息
# drop 删除提交

# 最终推送到远程（需要强制推送）
git push --force-with-lease
注意：只对尚未与他人共享的分支进行变基操作，避免破坏他人的工作基础。

写在最后的话

Git不是关于版本控制，而是关于改变跟踪。不是关于存储代码，而是关于讲述代码如何演变的故事。"

选择合适的工作流，理解底层的对象模型，再结合团队的实际需求，Git就能从工具进化为协作的艺术。

🌟 感谢您耐心阅读到这里！

🚀 技术成长没有捷径，但每一次的阅读、思考和实践，都在默默缩短您与成功的距离。

💡 如果本文对您有所启发，欢迎点赞👍、收藏📌、分享📤给更多需要的伙伴！

🗣️ 期待在评论区看到您的想法、疑问或建议，我会认真回复，让我们共同探讨、一起进步～

🔔 关注我，持续获取更多干货内容！

🤗 我们下篇文章见！