企业级项目开发中，版本控制系统是每个开发者不可或缺的工具。
而Git，作为目前最流行、最强大的分布式版本控制系统，更是现代团队协作的基石。它不仅能帮你管理代码历史，还能让多人协作变得前所未有的顺畅和高效。
所以，现在这个项目正好也适合大家去练习Git使用。
那这篇文章就先给大家将Git从头到尾梳理一下，基础命令以及怎么使用。
收藏起来！一定要学！！
一、Git核心概念
Git之所以强大，在于其独特的设计哲学。它并非简单地存储文件的差异，而是以“快照流”的形式记录项目状态。
1. 版本库（Repository）
版本库是Git存储项目所有历史版本的地方。
它包含了项目的所有文件和目录，以及每次修改的完整记录。
你可以把它想象成一个能够穿梭时空的“时光机”，每次你保存（提交）文件，它都会为你创建一个新的“时间点快照”，让你随时可以回到过去的任何一个版本。
2. 工作区（Working Directory）
工作区就是你电脑上能看到、能编辑的实际文件和目录。
你在这里进行代码编写、文档撰写、图片处理等一切创作活动。
工作区是你与项目文件直接交互的地方。
3. 暂存区（Staging Area/Index）
暂存区是一个独特的中间区域，它介于工作区和版本库之间。
当你对工作区的文件进行修改后，这些修改并不会立即被Git记录。
你需要通过 git add 命令将这些修改“暂存”起来，放入暂存区。
暂存区就像一个“预演舞台”，你可以在这里精心挑选和组织你想要提交的更改，准备好一个完美的“演出”（提交）。
只有进入暂存区的更改，才会被纳入到下一个版本中，形成一个完整的“快照”。
4. 提交（Commit）
提交是Git中最核心的操作。
每次提交都会记录项目在某个时间点的完整“快照”，并生成一个唯一的ID（通常是一个40位的SHA-1哈希值）。
这个ID就像是这次“创作定格”的指纹，独一无二。提交包含了作者、提交时间、以及最重要的——清晰的提交信息。
一个好的提交信息，能够简洁明了地描述这次修改的目的和内容，这对于日后追溯问题和团队协作至关重要。
5. 分支（Branch）
分支是Git最引人入胜的特性之一。
它允许你在不影响主线开发（例如，你的产品正在线上稳定运行）的情况下，独立地进行新功能开发、bug修复，甚至是那些大胆的实验性尝试。
每个分支都是项目历史的一个独立路径，你可以自由地在不同分支间切换，就像在不同的“平行宇宙”中穿梭。
当你在一个分支上完成工作并测试通过后，可以将其合并回主分支，将你的“平行宇宙”成果融入主线。
6. HEAD：你当前所在的“焦点”
HEAD是一个特殊的指针，它总是指向你当前所在分支的最新提交。
它就像你的“焦点”，告诉你现在正在哪个分支上工作，以及这个分支的最新状态是什么。
当你切换分支时，HEAD也会随之移动，指向新分支的最新提交。
Git工作区、暂存区、版本库关系图二、Git基础命令：日常操作速查
掌握以下Git基础命令，足以应对日常开发中的绝大部分场景。它们是Git操作的基石，熟练运用能让你事半功倍。
1. 初始化仓库：git init
当你有一个全新的项目，或者想将现有项目纳入Git管理时，git init 是你的第一步。它会在当前目录下创建一个隐藏的 .git 文件夹，这个文件夹就是Git版本库的核心，包含了所有版本信息、配置等。
git init
2. 克隆仓库：git clone
如果你要参与一个已有的项目，或者从远程仓库获取一份代码副本，git clone 是最便捷的方式。它会将远程仓库的所有内容（包括所有分支和提交历史）完整地复制到你的本地。
git clone
# 示例：git clone https://github.com/xxx/xxx-xx.git
3. 查看状态：git status
git status 是你最常用的命令之一，它能让你随时了解工作区和暂存区的当前状态。它会告诉你哪些文件被修改了、哪些文件已暂存、哪些是新文件还未被Git跟踪等信息，帮助你清晰地掌握项目的变化。
git status
4. 添加文件到暂存区：git add
当你对工作区的文件进行了修改，或者新增了文件后，需要使用 git add 将这些更改添加到暂存区，准备进行提交。你可以选择添加单个文件，也可以一次性添加所有更改。
git add # 添加指定文件，例如：git add index.cpp
git add . # 添加所有修改过的文件（包括新增、修改、删除），非常常用
5. 提交更改：git commit
git commit 是将暂存区的更改正式保存到版本库的操作。每次提交都会创建一个新的版本“快照”。一个好的提交信息（commit message）至关重要，它应该简洁明了地描述本次提交的目的和内容，方便日后查阅和理解。
git commit -m ""
# 示例：git commit -m "feat: 实现用户登录功能"
# 规范的提交信息通常包含类型（feat, fix, docs等）和描述
6. 查看提交历史：git log
git log 用于查看项目的提交历史。你可以看到每次提交的ID、作者、提交时间以及提交信息。通过不同的参数，可以以更简洁或更图形化的方式展示历史。
git log # 查看所有提交历史，详细信息
git log --oneline # 简洁模式，每条提交一行，只显示ID和提交信息
git log --graph --oneline # 图形化显示分支合并历史，清晰展示分支走向
7. 撤销更改：git reset & git restore
在Git中，撤销操作非常灵活但也需要谨慎。理解 git reset 和 git restore 的区别至关重要。
撤销暂存区文件：git restore --staged
如果你不小心 git add 了一个文件到暂存区，但又不想提交它，可以使用此命令将其从暂存区移除，但工作区的文件内容不会改变。
git restore --staged
撤销工作区文件修改：git restore
如果你对工作区的文件进行了修改，但想放弃这些修改，恢复到最近一次提交或暂存区的状态，可以使用此命令。
注意：这会丢弃你在工作区未提交的更改。
git restore
回退提交：git reset
git reset 用于回退提交，它会移动HEAD指针和当前分支的指向。它有三种常用模式，理解它们非常重要：
git reset --hard HEAD^ # 回退到上一个版本
git reset --hard HEAD~2 # 回退到上上个版本
git reset --hard # 回退到指定提交ID的版本
--soft：回退提交，但保留工作区和暂存区的更改。你可以重新提交这些更改。--mixed（默认）：回退提交，清空暂存区，但保留工作区更改。你需要重新 git add 并 git commit。--hard：回退提交，清空暂存区和工作区，「彻底丢弃更改」。
「这是最危险的模式，一旦执行，未提交的更改将无法恢复，请务必慎用！」
8. 远程操作：git push & git pull
Git作为分布式版本控制系统，与远程仓库的交互是其核心功能之一。git push 和 git pull 是你与远程仓库同步的常用命令。
推送更改：git push
将本地分支的提交推送到远程仓库，使远程仓库与你的本地仓库保持同步。当你完成本地开发并提交后，需要将其分享给团队成员或部署到服务器时，就会用到它。
git push origin : # 推送本地分支到远程指定分支
git push origin # 如果本地分支名和远程分支名相同，可省略远程分支名
git push -u origin # 首次推送时，设置上游分支，方便后续直接 git push
拉取更改：git pull
从远程仓库拉取最新更改，并自动合并到当前本地分支。在开始工作前，或者需要获取团队成员最新代码时，git pull 是必不可少的。
git pull origin : # 拉取远程指定分支到本地指定分支
git pull origin # 如果本地分支已设置上游分支，可省略远程分支名
Git常用命令速查表
| | |
|---|
| | |
| | git clone https://github.com/user/repo.git |
| | |
| | |
| | |
| | git commit -m "feat: add login page" |
| | |
| | |
| | |
| | |
| | git restore --staged index.html |
| | |
| | |
| | git branch feature/new-feature |
| |
|
| | |
| | git checkout -b bugfix/fix-bug |
| | git switch -c bugfix/fix-bug |
| | git merge feature/new-feature |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
三、Git分支与合并
分支是Git最强大的特性之一，它允许开发者在不影响主线开发的情况下，独立地进行新功能开发、bug修复或实验性尝试。合并则是将不同分支上的工作成果整合到一起，实现团队协作。
1. 分支操作：代码的“平行宇宙”
想象一下，你的项目是一棵大树，main（或 master）分支是主干。
当你需要开发新功能时，可以从主干上分出一个新的枝丫（分支），在这个枝丫上进行开发，无论你如何修改，都不会影响到主干的稳定。
当功能开发完毕并测试通过后，再将这个枝丫“嫁接”回主干。
创建分支：git branch
这个命令只创建分支，不会自动切换过去。
git branch feature/user-profile # 创建一个名为 user-profile 的新功能分支
切换分支：git checkout 或 git switch
git checkout 是一个多功能命令，除了切换分支，还能用于恢复文件等。Git 2.23版本后，推荐使用更语义化的 git switch 来切换分支，它更专注于分支操作，减少误用。
git checkout feature/user-profile # 切换到用户资料功能分支
# 或者，推荐使用：
git switch feature/user-profile
创建并切换分支：git checkout -b 或 git switch -c
这是最常用的创建分支方式，一步到位，非常方便。
git checkout -b bugfix/login-issue # 发现登录问题，立即创建并切换到修复分支
# 或者：
git switch -c bugfix/login-issue
查看分支：git branch -a
查看所有本地和远程分支的列表，* 标记表示当前所在的分支。
git branch # 查看本地分支
git branch -a # 查看所有分支（包括本地和远程）
删除分支：git branch -d 或 git branch -D
当一个分支的任务完成后，通常会将其删除以保持仓库整洁。
git branch -d feature/user-profile # 删除已合并的用户资料分支
git branch -D experimental/test # 强制删除实验性分支
git branch -d：用于删除已合并到当前分支的分支。如果分支有未合并的更改，Git会拒绝删除，提供安全保障。git branch -D：强制删除分支，无论其是否已合并。「慎用！」 这会丢失未合并的更改。
2. 合并操作：git merge——整合代码成果
当你在一个分支（例如 feature/user-profile）上完成了所有开发和测试，确认功能完善且稳定后，就需要将其合并回主线分支（例如 main 或 develop）。
# 第一步：切换到你想要合并到的目标分支（通常是 main 或 develop）
git checkout main
# 第二步：执行合并操作，将 feature/user-profile 分支的更改合并到当前分支（main）
git merge feature/user-profile
Git会尝试自动合并更改。如果一切顺利，Git会为你创建一个新的合并提交（Merge Commit），记录这次整合操作。但如果两个分支修改了同一个文件的同一部分，Git就会遇到“合并冲突”（Merge Conflict）。
合并冲突
合并冲突并不可怕，它是Git在告诉你：“这里有两份不同的修改，我不知道该听谁的，请你来做个决定！”
当发生冲突时，Git会在冲突的文件中用特殊的标记（<<<<<<<，=======，>>>>>>>）把冲突的部分标注出来。你需要手动编辑这些文件，解决冲突，然后 git add 冲突文件，最后 git commit 完成合并。
<<<<<<< HEAD
// 这是你当前分支（HEAD）的代码
std::cout << "你好，世界！" << std::endl;
=======
// 这是你尝试合并进来的分支的代码
std::cout << "Hello World!" << std::endl;
>>>>>>> main
你需要手动选择保留哪部分代码，或者进行修改，然后删除这些特殊标记。
解决冲突后，执行：
git add
git commit -m "Merge branch 'feature/user-profile' and resolve conflicts"
3. 变基操作：git rebase——让历史更“整洁”
git rebase 是另一种整合更改的方式，它不像 merge 那样会创建新的合并提交，而是尝试将你的分支提交“重放”到目标分支的最新提交之上。
这会使你的提交历史看起来更“线性”，更“整洁”，仿佛所有开发都是在一条直线上进行的。
# 假设你在 feature 分支，想把它的更改“变基”到 main 分支的最新状态上
git checkout feature
git rebase main
rebase 的风险：改写提交历史！
rebase 会创建新的提交ID，这意味着它会改写历史。如果你对一个已经推送到公共仓库（例如GitHub、GitLab）的分支进行了 rebase，然后又 push 了上去，就会导致其他协作者的历史混乱。
因此，黄金法则：永远不要对已经共享给别人的分支进行rebase操作！
rebase 更适合在个人本地分支上，或者在尚未推送到远程的私有分支上使用，以保持个人提交历史的整洁。
在团队协作中，merge 仍然是更安全、更推荐的合并方式，因为它保留了完整的历史记录。
四、Git常见场景与工作流
Git的强大之处在于其灵活性，可以适应各种团队规模和开发习惯。不同的团队会根据自身需求，选择或演化出不同的Git工作流。
理解这些工作流，有助于你更好地融入团队，提升协作效率。
1. 集中式工作流：简单直接，适合小型团队
这是最简单直接的工作流，所有开发者都直接在 main（或 master）分支上进行开发，然后将代码推送到远程仓库。它类似于传统的集中式版本控制系统（如SVN）。
特点：
- 优点： 学习曲线平缓，操作简单，适合个人项目或小型、初创团队。
- 缺点： 冲突解决频繁，风险较高，一旦主分支出现问题，可能影响所有开发者。不适合大型项目和频繁迭代的场景。
适用场景：
- 团队成员较少，沟通成本低，对版本控制要求不高的项目。
2. 功能分支工作流：主流选择，隔离风险
这是目前最流行、最推荐的工作流之一。其核心思想是：「每个新功能、每个bug修复，都应该在一个独立的分支上进行开发。」
流程：
- 从
main（或 develop）分支拉取一个新的功能分支（例如 feature/new-feature）。 -
- 功能开发完成后，将功能分支合并回
main（或 develop）分支。
特点：
- 优点： 有效隔离风险，主分支保持稳定；支持并行开发，提高团队效率；方便进行代码审查（Code Review），提升代码质量。
- 缺点： 分支管理相对复杂，需要团队成员养成良好的分支使用习惯。
适用场景：
3. Gitflow工作流：严谨有序，大型项目的“定海神针”
Gitflow是一个更复杂、更严谨的工作流，它定义了多个长期存在的“主干”分支和多种短期存在的“辅助”分支，以支持结构化的发布管理。
主要分支：
main：用于存放已发布的代码，代表生产环境的稳定版本。develop：用于日常开发，所有新功能都从这里派生，最终合并回这里。
辅助分支：
feature 分支：用于新功能开发，从 develop 派生，完成后合并回 develop。release 分支：用于发布准备，从 develop 派生，用于测试、bug修复和版本号更新，完成后合并回 main 和 develop。hotfix 分支：用于紧急bug修复，从 main 派生，完成后合并回 main 和 develop。
特点：
-
优点： 流程清晰，版本管理严谨，适合有明确发布周期和严格质量控制的项目；历史记录清晰，便于追溯。
- 缺点： 学习曲线较陡峭，分支管理复杂，对团队成员的Git熟练度要求较高。
适用场景：
- 对稳定性、可追溯性要求极高的项目（如金融、医疗行业）。
4. Forking工作流：开源世界的“通行证”
这种工作流在开源社区和大型企业中非常常见。它通过“fork”（派生）机制，为每个贡献者提供一个独立的远程仓库副本，从而实现开放协作和严格的代码审查。
流程：
- 贡献者“fork”主仓库到自己的GitHub（或其他Git托管平台）账号下，创建一个独立的远程副本。
- 通过发起“Pull Request”（拉取请求，简称PR）或“Merge Request”（合并请求，简称MR）来请求主仓库的维护者将自己的更改合并进去。
特点：
- 优点： 安全性高，主仓库权限集中；鼓励开放协作，降低参与门槛；PR/MR机制提供了严格的代码审查机会，确保代码质量。
适用场景：
五、Git高级用法：提升效率的“利器”
除了日常的提交、拉取、合并这些基本操作，Git还提供了一些高级功能，它们能在特定场景下极大地提升你的工作效率，解决更复杂的版本控制问题。
1. 储藏更改：git stash
想象一下这样的场景：你正在开发一个新功能，代码写到一半，突然接到一个紧急任务，需要你立即切换到另一个分支去修复一个线上Bug。但你手头的代码还没完成，又不想提交一个半成品。这时，git stash 就派上用场了。
git stash 可以将你当前工作区和暂存区中未提交的修改暂时保存起来，让你的工作区恢复到干净的状态。这样你就可以安心地切换到其他分支处理紧急任务，完成后再回来恢复之前的工作。
保存更改：
git stash save "正在开发用户注册功能，临时保存"
# 或者直接 git stash，Git会生成默认信息
恢复更改：
git stash apply # 恢复最近一次储藏，但保留在储藏列表中
git stash apply stash@{1} # 恢复指定储藏（例如列表中的第二个）
git stash pop # 恢复最近一次储藏，并从储藏列表中删除
删除储藏：
git stash drop stash@{0} # 删除指定储藏
git stash clear # 删除所有储藏
2. 挑选提交：git cherry-pick——精准复制提交
git cherry-pick 允许你选择一个或多个已存在的提交，并将它们应用到当前分支上。
这在以下场景非常有用：
- 将某个分支上的特定功能或修复，应用到另一个不相关的分支上。
- 从一个长期分支中挑选出几个重要的bug修复，快速应用到主分支。
git cherry-pick # 挑选单个提交
git cherry-pick # 挑选多个提交
git cherry-pick .. # 挑选一个范围内的提交
3. 交互式变基：git rebase -i——整理提交历史
git rebase -i（interactive rebase）是一个非常强大的工具，它允许你在合并分支之前，对提交历史进行修改，例如：
- 合并多个提交（squash）： 将多个零碎的提交合并成一个有意义的提交。
- 修改提交信息（reword）： 修正错误的提交信息。
- 重新排序提交（reorder）： 改变提交的顺序。
当你执行 git rebase -i 或 git rebase -i HEAD~ 后，Git会打开一个交互式编辑器，列出你选择的提交。你可以根据提示修改每个提交前的命令（如 pick, squash, reword, drop 等）。
「注意：git rebase -i 同样会改写提交历史，因此，」 永远不要对已经推送到远程仓库的公共分支使用 git rebase -i！** 它只适用于你本地的、尚未共享的提交历史。
4. 标签：git tag——重要的里程碑
git tag 用于给历史中的某个提交打上标签，通常用于标记重要的版本发布（如 v1.0.0）。标签是不可变的，一旦创建，就不能再修改或移动。
创建附注标签（推荐）： 附注标签会存储在Git数据库中，包含打标签者的信息、日期和标签信息，更完整。
git tag -a v1.0.0 -m "Release version 1.0.0"
查看标签：
git tag
git tag -l "v1.*" # 查看所有以 v1 开头的标签
推送标签到远程： 标签默认不会随 git push 推送到远程，需要单独推送。
git push origin v1.0.0 # 推送单个标签
git push origin --tags # 推送所有本地标签
Git作为分布式版本控制系统的翘楚，已经成为现代软件开发中不可或缺的工具。
它以其独特的快照机制、强大的分支管理能力以及灵活的工作流支持，极大地提升了个人开发效率和团队协作质量。
从基础的 git add、git commit 到复杂的 git rebase -i、git cherry-pick，Git提供了丰富的命令集，能够应对各种复杂的版本控制场景。
掌握Git，不仅仅是学会几个命令，更重要的是理解其背后的设计哲学和工作原理。
通过本文的介绍，希望你能够对Git的核心概念、常用命令、分支与合并的技巧、以及各种团队协作工作流有一个全面而深入的理解。
熟练运用Git，将让你在代码的世界里更加游刃有余，告别代码混乱，拥抱高效协作，成为一名真正的版本控制高手！
