Git 本地仓库初始化、提交与分支管理实战

引言

之前对 Git 的理解，往往停留在概念层面。真正使用时，常遇到以下问题：

• .git 目录的作用是什么？
• git add 的具体含义？
• 为什么本地已有代码，远程仓库却为空？
• 分支管理是否过于复杂？

在实际项目中，为了实现代码可追溯、可交付、可回滚，必须掌握从新建仓库到提交推送的完整流程。本教程将记录这一过程。

使用的工具：命令行环境、通用 Git 客户端。

---

本地仓库初始化

当前目录状态说明

实际场景如下：

• 本地已存在代码文件（.py、.txt 等）
• 此前仅为普通文件夹
• 目标：将整个项目纳入 Git 管理

执行 git init 的作用

在命令行执行：

git init

该命令的关键作用：

• 在当前目录下生成一个 .git 文件夹
• .git 是 Git 的'数据库 + 管理中心'
• 你的代码文件本身没有任何变化

此时，该目录即变为一个本地 Git 仓库。

---

配置 .gitignore 文件

不应上传的文件类型

并非所有文件都适合提交到仓库，例如：

• 编译产物
• 临时文件
• 日志文件
• 编辑器配置目录（.vscode、.idea）

这些文件特点：

• 对他人无用
• 依赖特定机器环境
• 变动频繁，会污染提交记录

.gitignore 的真实作用

.gitignore 不是禁止使用这些文件，而是不让 Git 追踪、记录这些文件。

示例内容：

# 日志
*.log
*.tmp
# 编辑器配置
.vscode/
.idea/
# 构建产物
.env/

配置好后，执行 git add 时 Git 会自动忽略这些内容。

---

第一次提交：git add / git commit

查看状态 git status

初始化完成后，先执行：

git status

常见输出：

Untracked files: paiqi.py test.py

Untracked files 意味着：这些文件存在于目录中，但 Git 尚未'记住'它们。

git add . 的含义

执行：

git add .

这一步的真实含义：

• 把当前目录下的文件
• 放进 Git 的「暂存区（staging area）」
• 并不是提交

可以理解为：告诉 Git，这些文件稍后一起提交。

git commit -m 的意义

执行提交：

git commit -m "初始化项目结构"

这是真正的'存档'：

• Git 记录当前所有暂存区文件的状态
• 形成一个不可变的 commit
• -m 后的内容是给未来的自己看的

好的 commit 信息应回答：这一次改了什么？为什么改？

---

本地与远程仓库的区别

核心概念

git init + git commit：只发生在你自己的电脑上。

远程仓库（如 GitHub、Gitee 等）完全不知道你本地做了什么。

本地 commit ≠ 已上传

git push 操作

当你执行：

git push

Git 才会做这件事：把本地仓库里的 commit（历史 + 文件变化）同步到远程仓库。

这一步完成后，刷新远程页面才能看到代码。

---

分支管理与开发流程

为什么要使用 Git 分支？

如果所有修改直接提交到 master（或 main）分支，会遇到两个问题：

1. 不安全：代码只改了一半、实验性修改、临时测试逻辑都会直接污染主分支。
2. 不可控：一旦代码被改乱，很难快速回到干净、稳定、可交付的状态。

分支的核心作用

分支 = 在不影响主线代码的情况下，安全地进行开发、试验和修改

• master 分支：对外可交付、稳定版本
• 开发分支（branch）：正在改、正在试、还没准备好给别人看的版本

实际操作流程

假设仓库中存在一个稳定可用的文件 XXX.py，已在 master 分支提交。

今天打算删除冗余函数、重构逻辑，但不确定是否影响整体结果。直接在 master 上改是有风险的。

正确做法：基于 master 新建分支

git checkout -b refactor-clean-functions

这一步做了两件事：

• 新建一个分支
• 自动切换到该分支

此时文件名不变，但所有修改只存在于该分支。即使改崩了，master 依然是干净的，可随时切回。

推荐的实际开发步骤

1. 确认当前分支

   git branch
   # 输出示例：* master
   

2. 新建开发分支

   git checkout -b refactor-clean-functions
   

3. 在分支中修改代码 例如删除无用函数、简化逻辑。Git 检测到当前文件内容与上一次提交不一致。

4. 查看修改状态

   git status
   # 可能看到：modified: XXX.py
   

5. 添加并提交修改

   git add XXXX.py
   git commit -m "refactor: 删除冗余函数，简化逻辑"
   

   注意：Git 并不是保存整个文件副本，而是记录'改了什么'。它会自动记录删除、新增、修改的行。

6. 推送分支到远程仓库

   git push origin refactor-clean-functions
   

---

Diff 原理与记录机制

很多新手疑问：只执行了 git add 和 git commit，Git 怎么知道删了哪几行、改了哪几行？

Git 记录的是'变化（diff）'

关键认知：

Git 不是保存一整个文件的副本，而是保存：相对于上一次提交，发生了什么变化

Git 内部关注的是相对于上一次提交的变化，而非全量扫描。

极简例子理解 diff

假设第一次提交代码：

def add(a, b): return a + b
def sub(a, b): return a - b

后来修改为：

def add(a, b): return a + b + 1

执行提交后，Git 实际记录的是类似这样的差异信息：

- def sub(a, b): 
- return a - b 
+ return a + b + 1

全部由 Git 自动完成，无需额外操作。

性能表现

结论一句话：不会慢，正常规模的代码几乎感觉不到延迟。

即使是几千行、上万行的 Python 文件，通常也是毫秒级到秒级。这也是 Git 能成为工业级工具的原因。

---

分支合并策略

何时合并到 master？

当分支满足以下条件时，可以合并：

• 功能已完成
• 不会破坏已有逻辑
• 当前版本是'可以交付'的
• 修复完成 bug 或重构验证通过

操作方式：提交合并请求（MR / PR），或本地合并后再 push 到 master。

何时保留分支？

以下情况完全可以不合并，分支留着就好：

• 实验性分支
• 临时分析 / 调试
• 尝试但最终放弃的方案

用于备份、后续查看，甚至以后直接删除。这对 master 没有任何影响。

Git 使用的是行级比较算法，比较的是「上一次提交」vs「当前文件」。