在Git中,文件状态是版本控制的核心概念,主要分为六大类,每种状态对应不同的操作阶段和版本控制逻辑。以下是详细解析:
六种文件状态
未跟踪(Untracked)
- 定义:新创建或未被Git管理的文件,未加入版本控制。
- 触发条件:新文件首次出现在工作目录,或文件被
.gitignore排除后未被强制添加。 - 示例:新创建的
new_file.txt或被忽略的temp.log。 - 转换操作:
- 通过
git add <file>或git add .将文件加入暂存区,状态转为Staged。 - 若文件被
.gitignore排除,需先修改忽略规则或用git add -f <file>强制跟踪。
已跟踪(Tracked)的子状态
已跟踪文件是Git已管理的文件,根据修改和暂存情况分为以下子状态:
- 未修改(Unmodified):
- 文件内容与最近一次提交完全一致,无变更。
- 示例:提交后未修改的
README.md。 - 转换操作:修改文件后转为
Modified。 - 已修改(Modified):
- 文件被修改但未通过
git add暂存。 - 示例:编辑
CONTRIBUTING.md后未暂存。 - 转换操作:
git add <file>→ 转为Staged。git checkout -- <file>→ 丢弃修改,恢复为Unmodified。- 已暂存(Staged):
- 文件修改已通过
git add加入暂存区,等待提交。 - 示例:
git add CONTRIBUTING.md后的文件。 - 转换操作:
git commit→ 转为Committed。git reset HEAD <file>→ 取消暂存,转回Modified。- 已提交(Committed):
- 文件修改已通过
git commit保存到本地仓库,成为历史记录的一部分。 - 示例:提交后的
README.md。 - 转换操作:再次修改文件后转为
Modified。
忽略(Ignored)
- 定义:被
.gitignore文件明确排除的文件,Git不跟踪其变更。 - 示例:
*.log、dist/等。 - 特性:无法通过
git add加入版本控制(除非强制-f),不参与任何状态转换。
合并冲突(Unmerged)
- 定义:在合并分支或解决冲突时,文件存在无法自动合并的变更。
- 触发条件:执行
git merge或git rebase时出现冲突。 - 示例:冲突标记
<<<<<<< HEAD的文件。 - 解决操作:
- 手动编辑文件解决冲突,标记为已解决(
git add <file>)。 - 使用
git merge --abort或git rebase --abort中止操作。
已删除(Deleted)
- 定义:已跟踪文件被删除,且变更已暂存或提交。
- 示例:
git rm <file>后的文件。 - 转换操作:
git rm <file>→ 状态转为Staged(删除操作已暂存)。git commit→ 转为Committed,文件从仓库中移除。git restore <file>→ 恢复已删除文件(需在提交前操作)。
重命名(Renamed)
- 定义:文件被重命名,且变更已通过
git mv或git add暂存。 - 示例:
git mv old.txt new.txt后的文件。 - 特性:Git通过内容哈希识别重命名,而非仅文件名变更。
状态转换流程
- 标准流程:
Untracked→Modified→Staged→Committed。 - 特殊操作:
git checkout -- <file>:丢弃工作区修改,恢复为Unmodified。git reset HEAD <file>:取消暂存,恢复为Modified。git restore --staged <file>:从暂存区撤销,保留工作区修改。
查看状态命令
git status:详细显示所有状态(如Changes not staged for commit、Untracked files)。git status -s:简洁模式,用符号标记状态(如M修改、A新增、??未跟踪)。
取消暂存
git restore --staged filename
该命令是 git add 的撤销动作,但会保留工作区中的更改,还可以重新使用git add再次暂存,不影响文件
撤销更改
# 撤销所有未暂存的更改,不包含已经git add过的new文件,也不包含未跟踪的文件
git restore .
注意:慎用此命令
恢复文件到历史版本
git restore --source=V1.0 filename
暂存已忽略的文件
git add -f <file> # 强制将文件加入暂存区(即使被忽略)