一、准备工作
注册并登录 Gitee
访问 Gitee 官网，注册账号并登录。
配置 SSH 密钥（免密码推送）
1. 本地生成 SSH 密钥（终端执行，一路回车默认即可）：
ssh-keygen -t ed25519 -C "你的Gitee邮箱地址"
生成密钥对
2. 查看公钥内容（复制全部文本）：
cat ~/.ssh/id_ed25519.pub
3. Gitee 添加公钥：
点击头像 → 「设置」→ 「安全设置」→ 「SSH 公钥」，粘贴公钥并保存。
4. 验证是否生效：
ssh -T git@gitee.com
出现 "Welcome to Gitee.com, 你的用户名!" 即成功
二、上传
创建远程仓库
填写仓库名称（如
my-project），选择是否公开（私有 / 公开），建议暂不勾选「使用 README 文件初始化这个仓库」（避免后续推送冲突，若勾选需额外处理），点击「创建」
本地项目上传
1. 进入本地项目目录
cd /path/to/你的项目文件夹
例如：cd D:\my-project
2. 初始化本地 Git 仓库
git init
会在项目目录生成.git隐藏文件夹，初始化仓库
删除方法：
rm -rf .git
注意：.git文件夹删除后，所有 Git 历史记录（提交、分支等）会永久丢失，仅保留当前工作区的文件。
3. 添加文件到暂存区
git add .
添加当前目录所有文件（.表示全部，也可指定文件名）
4. 提交到本地仓库
git commit -m "首次提交：初始化项目"
引号内为提交说明，必填
若首次提交，会显示如下：
这是 Git 在提交代码时因 ** 未配置用户身份（姓名和邮箱）** 导致的报错。
需通过git config命令配置用户信息
方法 1：全局配置（所有 Git 仓库生效）
在终端执行以下命令，替换为你的邮箱和用户名（任意即可，只作为标识）：
git config --global user.email "邮箱"
global user.name "用户名"
尽量选择你的Gitee邮箱和你的Gitee用户名
方法 2：局部配置（仅当前仓库生效）
进入项目根目录，执行：
git config user.email "邮箱"
git config user.name "用户名"
验证配置
git config --list
5. 关联远程仓库
将本地仓库与 Gitee 远程仓库关联（替换为你的仓库地址）：
git remote add origin https://gitee.com/你的用户名/仓库名.git
若提示
fatal: remote origin already exists，说明已关联，可先删除旧关联：git remote rm origin
6. 推送代码到 Gitee
推送到远程默认分支（master或main，根据Gitee仓库分支名调整）
git push -u origin master
若远程有内容，先拉取再推送
git pull --rebase origin master # 拉取远程分支（若远程为空可省略）
git push -u origin master # 推送本地分支到远程
若确认远程的修改无需保留，可强制推送覆盖远程历史（会丢失远程的新提交，多人协作时严禁使用，一般用于单人开发场景）
git push -u origin master --force
三、一些别的操作
查看当前仓库的提交历史：
git log
查看关联的远程仓库的信息
查看详细的远程仓库信息（含地址）
git remote -v
查看简洁的远程仓库别名列表
git remote
删除（撤销）git add 添加到暂存区的内容
撤销单个 / 指定文件的
git addgit reset HEAD <文件路径> // HEAD 表示当前分支的最新提交
如：git reset HEAD test.txt // 撤销 test.txt 的暂存状态
撤销所有
git add的内容git reset HEAD // 不指定文件，默认撤销所有暂存区内容
清空本地仓库
删除所有已跟踪的文件（暂存区 + 工作区）
git rm -r . # -r 表示递归删除子目录，. 表示当前目录所有文件
删除未跟踪的文件和目录（可选）
git clean -fd # -f 强制删除文件，-d 同时删除未跟踪的目录
四、git add 、git commit 和 git push 的区别
| 对比项 | git commit |
git push |
|---|---|---|
| 操作对象 | 本地 Git 仓库（将暂存区内容保存为版本记录） | 远程 Git 仓库（如 Gitee、GitHub 等） |
| 作用范围 | 仅影响本地版本控制，记录本地代码的修改历史 | 同步本地提交到远程，实现多人协作或代码备份 |
| 网络依赖 | 无需网络，本地即可执行 | 需要网络连接远程仓库 |
| 使用时机 | 本地功能开发完成、修改确认后，频繁执行（如完成一个小功能就 commit） | 本地提交稳定后，推送到远程共享（如每天下班前 push） |
| 历史可修改性 | 本地 commit 历史可通过 git rebase git reset 等命令修改 |
推送后远程历史通常不可随意修改（避免影响协作） |
| 命令 | 操作对象 | 作用 | 网络依赖 | 使用时机 | 历史可修改性 |
|---|---|---|---|---|---|
git add |
工作区 → 暂存区 | 将工作区的修改添加到暂存区，为提交做准备 | 无 | 完成部分修改后，准备提交前 | 暂存区内容可通过git reset等调整 |
git commit |
暂存区 → 本地仓库 | 将暂存区的修改提交到本地仓库，记录版本历史 | 无 | 暂存区内容稳定后，记录本地版本 | 本地提交可通过git rebase/git reset修改 |
git push |
本地仓库 → 远程仓库 | 将本地仓库的提交推送到远程仓库，实现协作共享 | 有 | 本地提交稳定后，需同步到远程时 | 远程提交后通常不可随意修改（避免协作冲突） |
git init ：当前目录初始化一个新的 Git 仓库 （即创建 .git 隐藏文件夹，用于存储版本控制相关的元数据，如提交历史、分支信息等），而当前目录本身会成为这个仓库的 "工作区"。
五、被跟踪的文件
在 Git 中，"被跟踪的文件（Tracked Files）" 是指 Git 已经知道并纳入版本控制的文件，这些文件的变更会被 Git 监控和记录。具体来说，被跟踪的文件包含以下几类：
1. 已提交到本地仓库的文件
所有通过 git commit 提交到本地仓库（.git 文件夹）的文件，都是被跟踪的核心文件。例如：
- 项目初始化时，通过
git add .+git commit提交的所有文件（如main.c、README.md）； - 后续开发中，新增并提交的文件（如
utils.h）。
2. 已添加到暂存区（但未提交）的文件
通过 git add <文件> 命令添加到暂存区（Index）的文件，即使尚未 git commit，也会被标记为 "被跟踪"（处于 "暂存状态"）。例如：新建 test.py 后执行 git add test.py，此时 test.py 虽未提交，但已被 Git 跟踪（暂存区中记录了它的状态）。
3. 被跟踪文件的特征
- Git 会监控其变更 ：被跟踪的文件若被修改、删除，执行
git status时会显示状态（如 "modified""deleted"）； - 与未跟踪文件的区别 ：未跟踪文件（Untracked Files）是 Git 从未记录过的文件（既未
git add也未提交），git status会单独标记为 "Untracked files"； - 可通过历史恢复 ：被跟踪的文件若被误删，可通过 Git 历史（如
git checkout <提交ID> <文件>）恢复，未跟踪文件删除后无法通过 Git 恢复。
如何查看被跟踪的文件？
执行 git status 命令，输出中：
- "Changes to be committed"：被跟踪且已暂存的文件（等待提交）；
- "Changes not staged for commit"：被跟踪但修改后未暂存的文件；
- 这两类都是 "被跟踪的文件"，而 "Untracked files" 则是未被跟踪的文件。
示例
假设项目中有以下文件：
main.c：已提交过（被跟踪）；log.txt：通过git add log.txt加入暂存区（被跟踪，未提交）；temp.json：新建后未执行git add（未被跟踪）。
执行 git status 会显示：
plaintext
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: log.txt # 被跟踪（暂存状态）
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: main.c # 被跟踪（已修改未暂存）
Untracked files:
(use "git add <file>..." to include in what will be committed)
temp.json # 未被跟踪简言之，被跟踪的文件是 Git 已经 "认识" 并管理的文件（无论是否提交），而未跟踪的文件是 Git 完全 "陌生" 的新文件。
当你执行 git add 1.txt 后（1.txt 已被添加到暂存区，处于 "被跟踪" 状态），若修改了 1.txt 的文件名（例如改成 2.txt），Git 会将这个操作识别为 "删除原文件 1.txt + 新增文件 2.txt"，具体表现和处理方式如下：
1. 执行 git status 会显示的状态
修改文件名后，运行 git status 会看到两种状态：
bash
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: 1.txt # 暂存区中记录的1.txt被标记为"删除"（因为工作区已不存在1.txt）
Untracked files:
(use "git add <file>..." to include in what will be committed)
2.txt # 新文件名2.txt未被跟踪（Git 还不知道这是1.txt的重命名）- 原因：Git 暂存区中仍记录着
1.txt的信息，但工作区中1.txt已被删除，同时新增了未被跟踪的2.txt。
2. 正确处理方式：告诉 Git 这是 "重命名"
若你希望保留文件的历史记录（让 Git 知道 2.txt 是 1.txt 重命名来的），需手动告诉 Git 这是一个重命名操作，有两种方式：
方式 1：手动添加新文件，Git 自动识别重命名
直接将新文件名 2.txt 添加到暂存区：
bash
git add 2.txt此时再执行 git status，Git 会自动检测到这是重命名，并显示：
bash
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
renamed: 1.txt -> 2.txt # 明确标记为"1.txt重命名为2.txt"方式 2：使用 git mv 命令（更高效）
git mv 是 Git 专门用于重命名或移动文件的命令，相当于 "手动重命名 + 自动更新暂存区" 的组合操作：
bash
git mv 1.txt 2.txt # 直接完成重命名，并同步到暂存区执行后，git status 会直接显示 renamed: 1.txt -> 2.txt，无需再手动 git add。
3. 若不处理会发生什么？
如果修改文件名后，既不 git add 2.txt 也不 git mv，直接 git commit：
- 提交后，Git 会认为
1.txt被删除（从版本历史中移除）； 2.txt因未被git add，不会被提交到仓库，仍处于工作区的 "未跟踪" 状态（若后续删除2.txt，会彻底丢失）。
总结
修改已暂存文件的名字后，Git 会默认视为 "删除旧文件 + 新增新文件"，需通过 git add 新文件名 或 git mv 旧文件名 新文件名 让 Git 识别为 "重命名"，以保留文件的历史记录，避免误删或丢失文件。