Git命令从入门到精通：环境配置、核心概念与实战指南

1. 项目概述：从“入土”到“重生”的Git命令之旅

看到这个标题，我仿佛看到了无数个曾经在版本控制门前徘徊、挣扎，最终又豁然开朗的开发者身影。“从安装到入土”，这个说法既戏谑又真实，它精准地捕捉了新手面对Git时那种从满怀希望到怀疑人生的心路历程。Git，这个由Linus Torvalds为管理Linux内核开发而创造的分布式版本控制系统，早已成为现代软件开发的基石。但它的学习曲线，尤其是其强大的命令行界面，确实让不少初学者望而生畏，感觉一不小心就会“入土为安”。然而，一旦你真正理解了它的设计哲学和核心命令，Git就会从一个令人头疼的“怪物”，变成你最得心应手的开发利器。这篇笔记的目的，就是陪你走完这段旅程，用最直白的命令讲解，帮你把Git从“安装”到真正“用起来”，而不是让它躺在你的电脑里“入土”。

Git的核心价值在于它对代码历史的完整追踪和高效的协同工作流支持。与传统的集中式版本控制系统（如SVN）不同，Git的每个工作目录都是一个完整的代码仓库，拥有完整的历史记录和版本跟踪能力，不依赖网络也能进行大部分操作。这种分布式特性带来了极大的灵活性和可靠性。我们常说的“提交（commit）”、“分支（branch）”、“合并（merge）”等概念，在Git中都有其独特而强大的实现。本教程将完全聚焦于命令行操作，因为这是理解Git精髓最直接、最根本的方式。图形化工具（GUI）固然方便，但命令行能让你清楚地知道每一步操作背后发生了什么，这是成为高级Git用户的必经之路。无论你是刚入门编程的学生，还是希望夯实基础的职业开发者，这篇基于命令的详细指南都将为你提供一个清晰、可靠的学习路径。

2. 环境准备与Git安装全攻略

在开始任何魔法之前，我们得先准备好魔杖。对于Git来说，就是在你的操作系统上正确地安装和配置它。这个过程虽然基础，但一步错可能导致后续步步错，所以值得我们仔细对待。

2.1 跨平台安装指南：Windows、macOS与Linux

Git的安装程序针对不同操作系统做了优化，但核心功能保持一致。选择适合你系统的安装方式至关重要。

Windows平台安装：对于Windows用户，最官方和推荐的方式是直接从Git官网下载安装程序。访问https://git-scm.com/download/win，你会看到几个选项。通常选择最新的64位Standalone Installer即可。运行安装程序时，你会遇到几个关键配置页面，这里有一些经验之谈：

  1. 选择组件：建议勾选“Windows Explorer integration”下的所有选项，特别是“Git Bash Here”和“Git GUI Here”，这会在你的右键菜单中添加快捷方式，非常方便。对于“Associate .git* configuration files with the default text editor”和“Associate .sh files to be run with Bash”，也建议勾选。
  2. 选择默认编辑器：这是一个重要的选择。安装程序会询问你希望Git使用什么作为默认文本编辑器。对于新手，我强烈推荐选择“Use the Nano editor by default”。Nano是一个简单、直观的终端文本编辑器，比Vim或Emacs更容易上手。如果你已经熟悉Vim，当然可以选择它。绝对不要在不了解的情况下选择Vim，否则你第一次遇到需要编辑提交信息的界面时，可能会因为不知道如何保存退出而手足无措。
  3. 调整PATH环境：选择“Git from the command line and also from 3rd-party software”。这个选项会将Git的可执行文件添加到系统的PATH环境变量中，允许你在任何命令行终端（如CMD或PowerShell）中直接使用git命令，同时也为第三方软件提供支持。这是最省心的选择。
  4. 选择HTTPS传输后端：使用默认的“Use the OpenSSL library”即可。
  5. 配置行尾符号转换：这是Windows用户需要特别注意的一点。由于Windows和Unix/Linux系统处理行尾符（CRLF和LF）的方式不同，为了协作时不产生混乱，请选择“Checkout Windows-style, commit Unix-style line endings”。这意味着当你从仓库检出代码时，Git会将LF转换为CRLF（适应Windows），而当你提交代码时，Git又会将CRLF转换回LF（保证仓库内的一致性）。这个设置能避免大量“行尾符更改”的虚假差异。
  6. 配置终端模拟器：选择“Use MinTTY (the default terminal of MSYS2)”。MinTTY比Windows自带的控制台（ConHost）功能更强大，支持复制粘贴、调整字体等。
  7. 其他选项：后续的“启用文件系统缓存”、“启用Git凭证管理器”等选项，保持默认启用状态即可。Git凭证管理器可以帮你安全地保存GitHub、GitLab等平台的账号密码，避免每次推送都输入。

macOS平台安装：macOS用户有多种选择。最简单的方法是打开终端（Terminal），如果你安装了Homebrew这个包管理器，只需一行命令：brew install git。Homebrew会自动处理依赖和更新。如果没有Homebrew，也可以从Git官网下载macOS安装包，其安装过程比Windows更简单，基本上一直点击“继续”即可。

Linux平台安装：对于Linux用户，通过系统自带的包管理器安装是最佳实践。例如，在Ubuntu或Debian上，使用命令sudo apt update && sudo apt install git。在Fedora或CentOS上，使用sudo dnf install git或sudo yum install git。安装后，可以通过git --version验证。

注意：无论哪种系统，安装完成后，请务必打开一个新的终端窗口（Windows上可以是Git Bash、CMD或PowerShell），输入git --version。如果正确显示版本号（如git version 2.39.2），恭喜你，安装成功！如果提示“不是内部或外部命令”，说明PATH环境变量可能未正确配置，需要检查安装步骤或手动添加路径。

2.2 初次运行Git的全局配置

安装成功只是第一步，接下来需要对Git进行个性化配置，这就像为新手机设置用户名和头像一样重要。这些配置信息会写入你用户主目录下的.gitconfig文件中。

打开你的终端，依次执行以下命令：

# 设置你的用户名，这个信息会记录在每一次提交中 git config --global user.name "你的姓名" # 设置你的邮箱，同样用于标识提交者 git config --global user.email "你的邮箱@example.com"

这里的“你的姓名”建议使用你的真实姓名或常用ID，“你的邮箱”强烈建议使用你在代码托管平台（如GitHub、Gitee）注册时使用的邮箱，这样平台才能正确地将提交与你的账户关联起来，展示你的贡献图表。

接下来，还有一些能极大提升体验的推荐配置：

# 设置默认分支名为 main，顺应社区新规范（传统是 master） git config --global init.defaultBranch main # 让命令行输出带上颜色，区分度更高，更易读 git config --global color.ui auto # 设置一个好用的差异对比工具，例如在Windows上使用 vscode # git config --global diff.tool vscode # git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE"

如果你想检查或修改所有配置，可以使用git config --global --list查看所有全局配置，或者直接编辑配置文件git config --global -e。

实操心得：--global标志表示这是全局配置，对当前用户的所有仓库生效。如果你需要为某个特定仓库设置不同的作者信息（比如为公司项目使用公司邮箱），可以在该仓库目录下，使用不带--global标志的相同命令进行设置，它的优先级更高。

3. Git核心概念与仓库生命周期

在动手敲命令之前，我们需要先建立对Git工作模型的心理地图。理解这些核心概念，后续的命令学习才会事半功倍，而不是死记硬背。

3.1 工作区、暂存区与仓库：Git的三大空间

这是Git最核心、也最需要理解的一个模型。你可以想象Git管理你的代码时，划分了三个区域：

  1. 工作区：就是你电脑上直接看到、编辑的那些文件和目录。这是你的“沙盘”，在这里进行所有代码的增删改。
  2. 暂存区：也叫索引。这是一个非常巧妙的设计，像一个“购物车”或者“准备台”。工作区的改动，并不会直接进入版本历史。你需要用git add命令，将满意的改动“放入”暂存区。这允许你对提交进行精细化控制，例如只提交某个功能相关的文件，而不是所有修改过的文件。
  3. 仓库：最终保存版本历史的地方，具体来说就是项目根目录下的.git隐藏文件夹。当你执行git commit时，暂存区的内容就会被打包成一个永久的“快照”，存入仓库，形成一个提交记录。这个记录包含了作者、时间、唯一的哈希值以及提交说明。

整个流程就是：工作区编辑 ->git add到暂存区 ->git commit到仓库。理解了这个流程，你就理解了Git最基本的工作流。

3.2 仓库的创建与克隆：一切的开始

拥有一个Git仓库有两种主要方式：从头创建一个新的，或者从远程服务器复制一个已有的。

初始化新仓库：如果你要开始一个新项目，进入项目目录，执行：

git init

这个命令会在当前目录下创建一个名为.git的子目录，里面包含了所有Git管理和跟踪这个仓库所需的骨架文件。此时，你的项目目录就变成了一个Git工作区。你可以开始添加文件并提交了。

克隆现有仓库：这是更常见的场景，比如你要参与一个开源项目，或者从公司服务器获取代码。使用git clone命令：

git clone <仓库URL> [本地目录名]

例如，克隆一个GitHub项目：git clone https://github.com/username/repo.git。这个命令会做几件事：1) 在本地创建一个以仓库名命名的目录（除非你指定了其他名字）；2) 初始化一个Git仓库；3) 将远程仓库（origin）的所有数据（所有分支、所有提交历史）完整地拉取到本地；4) 自动检出默认分支（通常是main或master）的最新代码到你的工作区。克隆完成后，你就拥有了一个与远程仓库完全同步的本地副本，并且自动建立了远程跟踪关系。

注意事项：git clone默认克隆的是HTTPS协议的URL。如果你配置了SSH密钥并添加到代码托管平台，使用SSH URL（如git@github.com:username/repo.git）会更方便，因为它避免了每次推送都要输入密码。对于公司内网环境，通常也会有内部的GitLab或类似服务，克隆方式类似。

4. 日常开发核心命令详解

掌握了基本概念后，我们就可以进入日常使用频率最高的命令环节了。这部分命令将伴随你开发的每一天。

4.1 文件状态跟踪与提交：git status,git add,git commit

这是Git的“铁三角”，构成了最基本的提交循环。

git status- 查看战场态势在任何时候，当你不确定当前仓库状态时，首先应该运行git status。它会清晰地告诉你：

  • 位于哪个分支（如On branch main）。
  • 暂存区有什么：哪些文件已被git add准备提交（Changes to be committed）。
  • 工作区有什么：哪些文件被修改但还未暂存（Changes not staged for commit）。
  • 未跟踪的文件：哪些是新创建的、Git还未开始管理的文件（Untracked files）。

它的输出是你的最佳导航仪。一个常用的快捷参数是-s或--short，它会以更紧凑的两栏格式输出状态，适合快速浏览。

git add- 将改动送入“准备区”这个命令用于将工作区的修改添加到暂存区。它的用法非常灵活：

  • git add <file1> <file2>：添加指定文件。
  • git add .或git add --all：添加所有修改的和未跟踪的文件（注意，git add .只添加当前目录及子目录下的改动，而git add --all会添加整个工作树的所有改动）。
  • git add -p：这是一个超级好用的高级功能。它会交互式地让你选择每一个代码块（hunk）是否要暂存。当你一次修改了多个不相关的功能，但又想分开提交时，这个命令是神器。它会展示每一处改动，并询问Stage this hunk [y,n,q,a,d,s,e,?]?，你可以选择y(暂存)、n(不暂存)、s(分割当前块)等。

git commit- 创造历史节点当暂存区的内容准备好后，使用git commit来创建一个永久的提交记录。这会打开你配置的默认编辑器（如Nano或Vim），让你填写提交信息。

  • 提交信息的第一行是简短的摘要（建议不超过50字符），空一行后，可以写详细的说明。
  • 如果你觉得提交信息很简单，可以直接用-m参数在命令行中指定：git commit -m “修复了登录按钮点击无效的bug”。
  • 一个更完整的提交是git commit -a -m “...”，这里的-a参数相当于自动执行了git add -u（添加所有已跟踪文件的修改，但不包括新文件），然后提交。这可以跳过显式的git add步骤，但不推荐新手依赖这个，因为它会让你失去对提交内容进行精细控制的机会。

实操心得：如何写好提交信息？糟糕的提交信息如“更新”或“修复”，在几个月后回看时毫无价值。好的提交信息应该像一条清晰的日志。第一行用祈使句简述改动目的，例如“添加用户注册表单验证”。正文部分解释为什么要这么改，而不是改了什么（代码本身已经展示了改了什么）。可以参考这样的格式：

优化数据库查询性能 - 在用户查询接口中添加了索引，字段为 `username` 和 `email`。 - 重构了 `getUserProfile` 函数，避免 N+1 查询问题。 - 本次优化使列表页加载时间从 ~2s 降低至 ~200ms。

4.2 查看历史与差异：git log,git diff

了解过去发生了什么，是理解项目现状和排查问题的基础。

git log- 翻阅项目日记git log会按时间倒序列出所有提交历史。但默认输出可能信息冗长。以下是一些极其有用的参数组合：

  • git log --oneline：每个提交只显示一行，包含缩短的提交哈希和提交信息摘要，非常清晰。
  • git log --graph --oneline --decorate --all：这是一个“王牌”组合。--graph会以ASCII字符画出分支合并图；--decorate显示分支和标签指向；--all显示所有分支的历史。这个命令能让你一眼看清整个项目的分支拓扑结构。
  • git log -p <file>：查看某个文件的历史修改详情，-p会显示每次提交的具体差异。
  • git log --since=”2 weeks ago”：查看最近两周的提交。
  • git log --author=”名字”：查看特定作者的提交。

git diff- 比较差异的显微镜这个命令用于查看不同版本之间的代码差异，是代码审查和自查的利器。

  • git diff：最常用。比较工作区和暂存区的差异。即，你修改了但还没git add的内容。
  • git diff --staged或git diff --cached：比较暂存区和最后一次提交（HEAD）的差异。即，你已经git add了，准备提交的内容。
  • git diff HEAD：比较工作区和最后一次提交的差异。这是你所有未提交改动的总和。
  • git diff <commit1> <commit2>：比较两个特定提交之间的差异。
  • git diff <branch1>..<branch2>：比较两个分支最新提交的差异。
  • git diff <commit1> <file>：查看某个文件在特定提交时的状态与当前状态的差异。

git diff的输出是标准的Unix差异格式，-开头的行表示删除，+开头的行表示新增。合理使用git diff能在提交前确保你的改动符合预期。

5. 分支管理：Git的超级力量

如果说提交是Git的基石，那么分支就是Git的翅膀。它让你能低成本地创建独立的开发线，这是实现并行开发、功能试验和版本管理的核心。

5.1 分支的创建、切换与合并

创建与切换分支：

  • git branch <branch-name>：创建一个名为<branch-name>的新分支。注意，这个命令只创建分支，不会自动切换过去。
  • git checkout <branch-name>：切换到已存在的分支<branch-name>。
  • git checkout -b <new-branch-name>：这是一个更常用的组合命令。它等于git branch <new-branch-name>+git checkout <new-branch-name>，即创建并立即切换到新分支。例如，开始开发一个新功能：git checkout -b feature/user-authentication。

查看分支：

  • git branch：列出所有本地分支，当前分支前会有一个*号。
  • git branch -v：列出分支并显示每个分支最新的提交信息。
  • git branch --all或git branch -a：列出所有分支，包括远程跟踪分支（如remotes/origin/main）。

合并分支： 当你在一个功能分支（如feature/x）上开发完成，并希望将其成果整合回主分支（如main）时，就需要合并。

  1. 首先，切换回主分支：git checkout main。
  2. 然后，执行合并：git merge feature/x。

Git会尝试自动合并。如果两个分支对同一文件的同一部分进行了不同的修改，就会产生冲突，这是分支合并中最常见的情况。

5.2 解决合并冲突实战

冲突并不可怕，它只是Git无法自动决定该保留哪一方修改时的提示。当冲突发生时，Git会暂停合并过程，并在有冲突的文件中标记出冲突内容。文件内容会变成类似这样：

<<<<<<< HEAD 这是主分支上的内容。 ======= 这是 feature/x 分支上的内容。 >>>>>>> feature/x
  • <<<<<<< HEAD和=======之间是当前分支（你执行git merge时所在的分支，如main）的内容。
  • =======和>>>>>>> feature/x之间是要合并进来的分支（feature/x）的内容。

解决冲突的步骤：

  1. 不要慌张。运行git status，你会看到“Unmerged paths”下列出了所有冲突文件。
  2. 用编辑器打开冲突文件，根据实际情况决定保留哪一部分代码，或者进行修改融合。你需要手动删除<<<<<<<，=======，>>>>>>>这些标记，并留下你最终想要的代码。
  3. 标记冲突已解决：对每个处理完冲突的文件，执行git add <file>。这告诉Git这个文件的冲突已经解决了。
  4. 完成合并：当所有冲突文件都git add后，执行git commit。Git会为你打开一个编辑器，里面已经预填了合并提交的信息，通常你可以直接保存退出。至此，合并完成。

避坑技巧：在合并前，尤其是预计可能有冲突时，确保你的工作区是干净的（没有未提交的修改）。可以使用git stash临时保存工作现场。另外，在团队协作中，养成在功能分支上频繁拉取主分支最新变更并合并（git merge main）的习惯，可以减少最终合并回主分支时的冲突规模和复杂度。

5.3 变基：另一种整合历史的方式

除了merge，rebase（变基）是另一种整合分支更改的方法，它的目标是创造一条更线性的项目历史。

  • 基本操作：在特性分支上，执行git rebase main。这个命令的含义是：“以main分支现在的状态为新的基础，重新播放我当前分支上的每一个提交”。
  • 效果：变基后，特性分支的提交历史看起来就像是直接从main分支的最新点开始开发的一样，历史是一条直线，没有分叉的合并节点。这使得历史更整洁，便于查看。
  • 黄金法则：只对你本地尚未推送到远程仓库的提交进行变基。绝对不要对已经推送到公共仓库的提交进行变基。因为变基会重写提交历史，改变提交的哈希值，这会给其他基于旧历史协作的同事带来灾难性的混乱。

变基更常用于整理本地提交（交互式变基git rebase -i），比如将多个琐碎的提交合并成一个清晰的提交，或者修改某次提交的信息。对于新手，建议先熟练掌握合并，再在理解其后果的前提下谨慎使用变基。

6. 远程协作：连接世界

Git的分布式威力在远程协作中完全展现。你需要一个中心服务器（如GitHub、GitLab、Gitee或公司自建Git服务）作为大家同步代码的枢纽。

6.1 远程仓库操作：remote,push,pull,fetch

管理远程连接：

  • git remote -v：查看当前仓库配置了哪些远程仓库，以及它们的URL（fetch和push）。
  • git remote add <shortname> <url>：添加一个新的远程仓库，并给它起一个简称（shortname），通常主远程仓库叫origin。例如：git remote add origin https://github.com/yourname/repo.git。
  • git remote remove <shortname>：移除一个远程连接。

推送本地提交：git push <remote> <branch>将本地指定分支的提交上传到远程仓库。例如：

  • git push origin main：将本地的main分支推送到远程origin的main分支。
  • git push origin feature-branch：推送本地特性分支到远程，通常在开源项目中用于创建Pull Request。
  • 第一次推送时，如果远程没有对应分支，可以使用-u参数建立跟踪关系：git push -u origin main。之后就可以简单地使用git push了。

获取远程更新： 这里有两个关键命令：fetch和pull，他们经常被混淆。

  • git fetch <remote>：这个命令非常安全。它只会从远程仓库下载最新的提交历史和分支信息到你的本地仓库（在remotes/<remote>/下），但不会自动合并到你的当前工作分支。它让你能看到其他人做了什么（git log origin/main），而不会影响你的工作。相当于“看看远程有什么新东西”。
  • git pull <remote> <branch>：这个命令是git fetch后紧接着git merge的快捷方式。它从远程下载更新并立即尝试合并到当前分支。相当于“把远程的新东西拿下来并和我现在的代码合并”。注意：如果远程有强制推送等历史变更，直接pull可能会产生复杂冲突。更稳健的工作流是：先git fetch，再git log查看变化，最后决定是git merge origin/main还是git rebase origin/main。

6.2 团队协作工作流浅析

理解了基本命令后，你需要将其组合成有效的工作流。最常见的是功能分支工作流：

  1. 基于主分支创建特性分支：git checkout -b feature/xxx
  2. 在特性分支上开发：进行多次git add和git commit。
  3. 同步主分支更新：定期git fetch origin，然后git merge origin/main到你的特性分支，以降低最终合并的冲突风险。
  4. 推送特性分支：git push -u origin feature/xxx
  5. 发起合并请求：在GitHub/GitLab等平台，对你的特性分支发起Pull Request或Merge Request，请求合并到主分支。
  6. 代码审查与合并：团队成员在PR/MR中进行代码审查、讨论。通过后，由有权限的人在平台上将特性分支合并到主分支。
  7. 更新本地主分支并删除旧特性分支：切换回主分支git checkout main，拉取最新代码git pull origin main，然后删除已合并的本地特性分支git branch -d feature/xxx，也可以删除远程分支git push origin --delete feature/xxx。

7. 高级技巧与问题排查实战

掌握了日常命令后，一些高级技巧和问题排查能力能让你在关键时刻游刃有余。

7.1 撤销与回退：拯救误操作

人人都会犯错，Git提供了多种“后悔药”，但药效和副作用不同，需谨慎选择。

git restore- 恢复文件（Git 2.23+ 推荐）这是一个较新的、意图更清晰的命令，用于撤销工作区或暂存区的更改。

  • git restore <file>：丢弃工作区中对某个文件的修改，恢复到最近一次git add或git commit时的状态。危险操作，未保存的修改会丢失！
  • git restore --staged <file>：将文件从暂存区移回工作区，即取消git add操作，但保留工作区的修改。

git reset- 重置提交历史这个命令更强大，也更具破坏性，主要用于操作提交历史本身。

  • git reset --soft <commit>：将HEAD指针移动到指定的提交，但保留暂存区和工作区的所有修改。相当于“撤销了提交，但改动还留着”。常用于重新组织提交。
  • git reset --mixed <commit>：默认模式。将HEAD指针移动，并重置暂存区到指定提交的状态，但保留工作区的修改。相当于“撤销了提交和git add操作，但代码改动还在工作区”。这是最常用的撤销到某个版本并重新提交的方式。
  • git reset --hard <commit>：危险！将HEAD指针、暂存区、工作区全部重置到指定提交的状态。指定提交之后的所有修改都将被永久丢弃！仅用于彻底放弃最近的提交和所有改动。

git revert- 安全撤销与reset直接删除历史不同，revert是通过创建一个新的提交来“抵消”某个旧提交的更改。这是撤销已推送到公共仓库的提交的安全方法，因为它不会重写历史。

  • git revert <commit-hash>：创建一个新的提交，其内容是指定提交的逆向操作。历史记录中会保留原提交和这次撤销提交，清晰可查。

7.2 储藏与清理：临时切换上下文

git stash- 临时搁置工作当你正在一个分支上工作到一半，突然需要切换到另一个分支去修复一个紧急bug，而你又不想提交未完成的代码。这时git stash就是救星。

  • git stash或git stash push：将当前工作区和暂存区的修改保存到一个临时栈中，并将工作区恢复到干净状态（最近一次提交的样子）。
  • git stash list：查看所有的储藏列表。
  • git stash pop：应用最近一次的储藏内容到工作区，并从栈中删除该记录。
  • git stash apply stash@{n}：应用指定的储藏（如stash@{0}），但不从栈中删除。
  • git stash drop stash@{n}：删除指定的储藏。
  • git stash branch <new-branch>：基于储藏内容创建一个新分支并应用储藏，这在你发现储藏的内容需要较多修改时很有用。

git clean- 清理未跟踪文件这个命令用于删除工作区中所有未被Git跟踪的文件（比如编译产物、临时文件）。这是一个危险命令，因为删除的文件通常无法恢复！

  • git clean -n：干跑。显示哪些文件将会被删除，但不实际执行。
  • git clean -f：强制删除当前目录下未跟踪的文件。
  • git clean -df：强制删除未跟踪的文件和目录。
  • git clean -xdf：强制删除所有未跟踪的文件和目录，包括被.gitignore忽略的文件。使用前务必用-n确认！

7.3 常见问题排查实录

在实际操作中，你肯定会遇到各种问题。这里记录几个典型场景和解决思路。

问题1：执行git push被拒绝，提示“non-fast-forward”原因：你试图推送的分支，其历史与远程分支的历史已经分叉（通常是因为别人已经推送了新的提交到远程）。解决：

  1. 首先，使用git fetch origin获取远程最新状态。
  2. 然后，你有两种选择：
    • 合并：git merge origin/main(假设你在main分支)，解决可能出现的冲突，然后再次git push。
    • 变基（如果只有你自己在这个分支上工作）：git rebase origin/main，然后git push --force-with-lease。注意：--force-with-lease比--force更安全，它会检查远程分支是否在你拉取之后又被别人更新过，避免覆盖他人工作。

问题2：误提交了敏感信息（如密码、密钥）到仓库原因：不小心add并commit了包含敏感信息的文件。解决：

  1. 如果尚未推送：使用git reset回退到上一个提交，然后删除或修改敏感文件，再重新提交。例如git reset --soft HEAD~1。
  2. 如果已经推送：情况更复杂。首先，在本地使用git filter-branch或更推荐的git filter-repo（第三方工具，更安全高效）工具，从整个历史中彻底删除该敏感文件。然后，必须通知所有协作者，他们需要重新克隆仓库或进行复杂的变基操作，因为历史被重写了。最后，强制推送git push --force。这是一个破坏性操作，需团队协同。

问题3：git status显示大量未跟踪文件，但其中很多是编译产物或依赖原因：没有正确配置.gitignore文件。解决：在项目根目录创建或编辑.gitignore文件，指定哪些文件或目录应该被Git忽略。例如一个Node.js项目的.gitignore可能包含：

node_modules/ dist/ *.log .env .DS_Store

配置好后，这些文件就不会再出现在git status的未跟踪列表里了。GitHub上有一个非常全面的.gitignore模板集合，可以根据你的项目类型去参考。

问题4：执行命令时出现“fatal: not a git repository”错误原因：当前目录不是一个Git仓库（没有.git文件夹）。解决：确认你是在正确的项目目录下。如果需要初始化，运行git init。如果需要进入一个已有仓库，使用cd命令切换到仓库根目录。

掌握这些命令和技巧，意味着你已经从“Git小白”成长为一名能够熟练运用版本控制工具的开发者。Git的学习是一个持续的过程，它的深度远超这篇教程所涵盖的内容。但只要你理解了工作区、暂存区、仓库这三个核心区域，掌握了add、commit、push、pull、branch、merge这些基本动作，并学会了如何撤销和查看历史，你就已经具备了应对日常开发中99%版本控制需求的能力。剩下的高级功能，可以在遇到具体场景时再去探索。记住，最好的学习方式就是在实际项目中不断使用它，遇到问题就去查、去试。现在，关闭这篇笔记，打开你的终端，开始你的Git之旅吧。