一、准备工作

注册并登录 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 add

git 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 commitgit push
操作对象本地 Git 仓库（将暂存区内容保存为版本记录）远程 Git 仓库（如 Gitee、GitHub 等）
作用范围仅影响本地版本控制，记录本地代码的修改历史同步本地提交到远程，实现多人协作或代码备份
网络依赖无需网络，本地即可执行需要网络连接远程仓库
使用时机本地功能开发完成、修改确认后，频繁执行（如完成一个小功能就 commit）本地提交稳定后，推送到远程共享（如每天下班前 push）
历史可修改性本地 commit 历史可通过 git rebasegit 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” 则是未被跟踪的文件。

示例

假设项目中有以下文件：

  1. main.c：已提交过（被跟踪）；
  2. log.txt：通过 git add log.txt 加入暂存区（被跟踪，未提交）；
  3. temp.json：新建后未执行 git add（未被跟踪）。

执行 git status 会显示：

plaintext

Changes to be committed:
  (use "git restore --staged ..." to unstage)
        new file:   log.txt  # 被跟踪（暂存状态）
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   main.c  # 被跟踪（已修改未暂存）
Untracked files:
  (use "git add ..." 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 ..." to unstage)
        deleted:    1.txt  # 暂存区中记录的1.txt被标记为“删除”（因为工作区已不存在1.txt）
Untracked files:
  (use "git add ..." 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 ..." 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 识别为 “重命名”，以保留文件的历史记录，避免误删或丢失文件。