什么是 Git？为什么要用版本控制？

什么是 Git？为什么要用版本控制？

        Git 是一款免费、开源的分布式版本控制系统，用于高效地管理项目的版本历史。简单来说，Git 可以记录代码的每次修改，允许我们随时查看过去的版本，并在需要时回退更改。使用 Git 的版本控制有诸多好处：首先，它可以防止代码丢失 —— 即使不小心删改了文件，也能通过历史记录恢复 。其次，Git 便于多人协作，团队成员可以各自提交代码，Git 会合并不同开发者的修改，从而降低冲突的风险。最后，版本控制让开发流程更有条理，我们可以为每个功能创建独立的历史记录，清晰地追踪谁在什么时间做了哪些更改。

为什么要使用版本控制？ 如果没有版本控制，开发者往往通过手工复制文件来备份不同阶段的代码（例如创建project_v1, project_v2文件夹）。这种做法既麻烦又容易出错。而使用 Git，我们只需在同一个仓库里持续提交（commit）代码即可，它会为每次修改创建快照，以后可以方便地比较不同版本或恢复到以前的版本。总之，Git 等版本控制工具能够提升开发效率、确保代码安全，并促进团队协作，是现代软件开发中必不可少的一环。

1、安装 Git

Git 跨平台支持 Windows、macOS 和 Linux。以下是各平台安装 Git 的简要指南：Git官网

• Windows： 可以从 Git 官方网站下载 Windows 安装程序（Git for Windows）。安装完成后，会附带一个 “Git Bash” 终端，方便在命令行使用 Git。

• macOS： macOS 系统可以通过 Homebrew 安装（如执行 brew install git），或者安装 Xcode 命令行工具来获取 Git。也可从 Git 官网下载独立的安装包。

• Linux： 大多数发行版的包管理器都提供 Git。例如在 Debian/Ubuntu 上执行 sudo apt-get install git，在 CentOS/Fedora 上执行 sudo yum install git 即可通过包管理器安装。

• 验证安装： 安装完成后，可以打开终端/命令提示符，运行 git --version 来查看 Git 是否安装成功，以及当前版本号。

2、Git 基本配置

        第一次安装 Git 后，建议进行一些基本的配置，至少包括设置用户名和邮箱。这两个信息会记录在每次提交中，标识代码的提交者。配置命令如下：

git config --global user.name "你的姓名"
git config --global user.email "[email protected]"

        上述命令使用 --global 参数表示在全局范围内配置，即对这台电脑上的所有 Git 仓库生效（配置会存储在用户主目录下的.gitconfig文件中）。请将引号内的内容替换为你自己的姓名和邮箱。例如：

git config --global user.name "Zhang San"
git config --global user.email "[email protected]"

        配置完成后，可以通过 git config --list 查看当前 Git 的配置列表，确认用户名和邮箱是否设置成功。合理设置这些信息非常重要，因为每次提交记录都会包含作者信息，方便协作者识别每个修改来自谁。

        除了用户名和邮箱，Git 还有许多可调整的配置项，比如默认文本编辑器、换行符处理等。对于初学者而言，暂时只需要完成用户名和邮箱的配置即可，其他配置可以在需要时再行设置。

3、基本命令讲解

        安装和配置完 Git 后，就可以开始使用 Git 来跟踪项目中的文件改动了。下面介绍一些 Git 中最基础且常用的命令，通过示例来说明它们的作用。

3.1、git init —— 初始化仓库

git init 命令用于将当前目录初始化为一个本地 Git 仓库。执行该命令后，Git 会在当前目录下创建一个名为 .git 的隐藏文件夹，这个文件夹就是 Git 用来跟踪版本历史的版本库（repository）。例如，我们新建一个目录作为项目文件夹，进入该目录后运行：

$ git init
Initialized empty Git repository in /Users/zhangsan/myproject/.git/

上述命令输出表明，一个空的 Git 仓库已经在此目录创建成功。此时，我们的项目目录正式受到 Git 的管理，后续可以在其中使用其他 Git 命令。需要注意的是，在执行 git init 前，应该先确保自己位于项目的根目录。如果不小心在错误的目录运行了 git init，可以删除产生的 .git 文件夹或者在正确目录重新初始化。

3.2、git status —— 查看仓库状态

git status 命令用于查看当前仓库的状态信息。它可以告诉我们哪些文件有改动、哪些改动已暂存（staged）准备提交、哪些文件未被 Git 跟踪等。当我们在仓库目录中新增、修改或删除文件后，执行 git status 会看到类似下面的输出：

$ git status
On branch main
Untracked files:
  (use "git add ..." to include in what will be committed)
	newfile.txt

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
	modified:   readme.md

上述结果表明：当前分支为 main，有一个未被跟踪的新文件newfile.txt，以及一个已跟踪但尚未暂存修改的文件readme.md。通过 git status，初学者可以清楚了解自己仓库中哪些更改尚未被提交。提示：git status 是非常常用的命令，建议在每次提交之前运行它来检查当前状态，确保没有遗漏需要提交的改动。

3.3、git add —— 添加文件到暂存区

git add 命令用于将工作目录中发生变化的文件添加到暂存区（Staging Area）。暂存区可以看作是一个等待提交的暂时区域，我们需要先用 git add 把修改“放入”暂存区，然后再提交。常用的用法包括：

• git add <文件名>：添加指定的文件到暂存区。

• git add .：添加当前目录下所有改变的文件到暂存区（包含新文件和修改过的文件）。

例如，如果我们修改了一个名为 readme.md 的文件，可以运行：

git add readme.md

执行后，git status 会显示该文件的状态从“modified”（已修改但未暂存）变为“Changes to be committed”（已暂存等待提交）。这表示修改已成功加入暂存区，等待下一步的提交。

暂存区的引入使我们可以灵活选择哪些修改进入下一次提交。例如，我们同时修改了多个文件，但只想先提交其中一部分，就可以只 git add 想提交的文件，其他文件留在工作区不添加，提交时就只会记录已暂存的部分。需要注意，git add 命令本身并不真正保存修改到版本历史，它只是将修改暂时记录下来，下一步还需要使用 git commit 才能将暂存的变更正式提交到仓库。

3.4、git commit —— 提交更改

git commit 命令会把暂存区的文件快照记录到仓库的历史中，形成一个新的提交（commit）。每次提交都类似于给当前项目状态拍了一张照片，以后可以查看或恢复。提交时通常需要添加描述此次修改的提交消息，以帮助自己和他人理解这次更改的目的。

最常用的提交命令格式是：

git commit -m "提交说明"

其中-m用于指定提交消息（message）。例如：

git commit -m "添加用户登录功能"

执行上述命令后，Git 会将暂存区的所有改动保存为一次新的提交，并输出提交的简要信息（包括提交的 SHA-1 哈希值、修改的文件数等）。此时，这些改动已经被安全地记录在 Git 仓库的历史中了。提交完成后，对应的暂存区会被清空（因为改动已记录在仓库），而工作区如果没有新的改动将显示为干净（clean）。

**注意：**如果在运行 git commit 时不使用 -m 参数，Git 将打开默认文本编辑器要求输入提交说明。在 Windows 下默认可能是 Vim 编辑器，这对初学者可能不太友好。如果不小心进入了 Vim，输入提交说明后按下 ESC，输入:wq再回车即可保存并退出。为避免这种情况，可以直接使用 -m "message" 来简洁地指定提交说明。

Git 采用了工作区、暂存区、版本库三层结构来管理文件的更改。简单理解，工作区是平时我们编辑文件的地方，暂存区用于暂时存放将被提交的改动快照，而版本库则保存了提交的历史记录和所有数据。当运行 git add 时，修改从工作区被添加到暂存区；执行 git commit 时，暂存区的内容会永久记录到版本库中。下面这张图展示了工作区（左）、暂存区（Index）和版本库（右）三者之间的关系：
工作区、暂存区和版本库的关系示意图。左侧绿色区域表示工作区；右侧蓝色区域表示版本库，其中灰色框“index”代表暂存区，“master”则表示版本库中当前分支（例如主分支）的最新提交。蓝色箭头表示文件变化流转方向：git add 将修改从工作区添加到暂存区，git commit 将暂存区的改动提交到版本库。通过这种机制，Git 让我们可以在提交前自由挑选和组合更改，从而更加灵活地管理版本历史。

3.5、git log —— 查看提交历史

git log 用于查看仓库的提交历史记录。执行 git log 命令，会按照时间顺序列出所有的提交（当前分支上的），每个提交包含提交哈希值、作者姓名、日期和提交说明等信息。通过日志，我们可以了解项目的演变过程。例如，一次简单的输出可能是这样的：

$ git log
commit 3f0c1e2baf3c5d2a4c8b6e0f1a2b3c4d5e6f7g8h (HEAD -> main)
Author: Zhang San 
Date:   Tue Apr 8 09:30:00 2025 +0800

    添加用户登录功能

commit a1b2c3d4e5f6g7h8i9j0k... (origin/main, origin/HEAD)
Author: Li Si 
Date:   Mon Apr 1 14:20:00 2025 +0800

    初始化项目结构

从上述日志可以看出，最近的一次提交是由张三在2025年4月8日创建，提交消息是“添加用户登录功能”，其下方还列出了更早之前李四于4月1日的提交记录“初始化项目结构”。git log 默认会显示详细的提交哈希和信息，如果希望精简输出，可以使用 git log --oneline --graph 等参数查看简短的摘要和图形化的分支走向。总之，git log 是非常有用的工具，可以帮助我们追踪项目历史、定位某次改动，以及在需要时找到以前的版本。

4、创建本地仓库和远程仓库连接（GitHub）

在实际开发中，我们通常不仅会在本地保存代码，还会将代码托管到远程代码仓库平台（例如 GitHub、GitLab 等）以备份代码并方便协作。下面介绍如何将本地仓库与远程仓库相连接。

1. 创建本地仓库： 可以使用 git init 将一个项目文件夹初始化为本地仓库（这一过程我们已经在前文介绍）。也可以通过 git clone 直接从远程获取仓库（参见下一节）。假设我们已经在本地用 git init 初始化了仓库并且有一次或多次提交记录。

2. 在远程平台创建仓库： 登录 GitHub 后，新建一个仓库（Repository）。通常只需要提供仓库名称和描述，选择是否初始化 README 等。创建完成后，GitHub 会为你提供该仓库的 Git 远程地址，有 HTTPS 和 SSH 两种形式。例如 HTTPS 地址可能是 https://github.com/yourname/myproject.git。

3. 添加远程地址 (remote)： 在本地仓库中，使用 git remote add 命令将远程仓库关联起来。通常我们将这个远程仓库命名为 “origin”。命令格式如下：

git remote add origin <远程仓库地址>

将 <远程仓库地址> 替换为实际的 GitHub 仓库地址。例如：

git remote add origin https://github.com/yourname/myproject.git

执行后，可以用 git remote -v 查看远程列表，应该能看到 origin 对应刚添加的 URL。

4. 推送本地内容到远程： 远程添加后，使用 git push 将本地提交推送到远程仓库。第一次推送时可以使用 -u 参数指定默认上游分支，这样后续推送和拉取可以省略分支名。例如，假设本地当前在主分支名为 main：

git push -u origin main

上述命令会将本地的 main 分支内容推送到远程的 origin 仓库的 main 分支。如果远程仓库刚创建，可能还没有主分支，这条命令会在远程创建 main 分支并上传内容。同时 -u 将本地的 main 分支与远程的 origin/main 关联（设为tracking branch），以后执行不带参数的 git push 或 git pull 时，Git 会自动推送/拉取 origin 的 main 分支。

**注意：**某些平台（例如早期的 Git 或某些托管服务）默认主分支名称为 “master”。近年很多新仓库的默认分支改名为 “main”。实际操作时，请根据远程仓库的主分支名称来推送。如果本地仓库初始化后默认是master但远程是main，可以在推送时执行 git push -u origin master:main 将本地 master 推送到远程 main 并建立关联，或在本地将分支重命名为 main 后再推送。

完成上述步骤后，本地仓库就和远程 GitHub 仓库建立了连接。此时可以在 GitHub 网站上刷新查看，应该能够看到已上传的代码和提交历史。今后，如果有新的提交，只需使用 git push 就能把最新的更改推送到远程；而从别的机器克隆该仓库或团队成员拉取（pull）即可获取最新代码。

5、克隆项目（git clone）

git clone 是用于从现有远程仓库下载代码的命令。它可以将远程仓库完整地复制到本地，包括所有的文件和历史记录。对于刚加入项目的新人或者更换电脑的开发者来说，git clone 是获取项目代码的起点。

克隆仓库的基本用法格式为：

git clone <远程仓库地址> [本地目录名]

<远程仓库地址> 可以是 HTTPS 地址（如 https://github.com/owner/repo.git）或者 SSH 地址（如 [email protected]:owner/repo.git）。命令的第二个参数 [本地目录名] 是可选的，如果提供，Git 将会把仓库克隆到以该名称命名的文件夹；如果不提供，Git 会默认使用仓库名作为本地目录名称。

例如，我们要克隆名为 awesome-project 的 GitHub 仓库，可以执行：

git clone https://github.com/someuser/awesome-project.git

执行后，Git 会在当前目录下创建一个名为 awesome-project 的文件夹（如果该文件夹不存在），然后从远程仓库下载所有文件和提交历史到此文件夹中。完成后，你可以进入该目录开始浏览和编辑代码。克隆操作不仅复制了文件，还已经隐含地为我们做了以下两件事：

• 初始化了一个 Git 仓库（自动执行了类似 git init 的操作）。

• 添加了默认的远程仓库设置，将远程命名为 origin（无须手动 git remote add）。

换句话说，克隆下来的仓库可以直接使用 git pull 获取更新，使用 git push 推送修改，而不需要再手动设置远程地址。git clone 通常只在第一次取得项目代码时使用，一旦克隆完成，后续更新项目则通过 git pull 来获取最新改动。

6、常见问题提示

初学者在使用 Git 的过程中可能会遇到一些常见的小问题，以下列出几个并提供解决方法。

• 忘记使用 git add 就执行了 git commit： 如果你提交后发现有些文件的修改没有包含在提交中，通常是因为提交前没有 git add 它们。结果就是提交成功了，但漏掉了一些改动。解决方法：再次使用 git add <文件> 将遗漏的修改添加暂存，然后再执行一次 git commit（这次提交可写一个类似“补充上次提交遗漏的修改”的说明）。另外，养成在 git commit 前使用 git status 检查暂存区内容的习惯，可以有效避免此问题。

• 忘记使用 git commit 就尝试 git push： 有时新手会误以为 push 会自动包含所有更改，但实际上 push 只能推送已经 commit 的内容。如果你跳过了 git commit 就直接 git push，Git 会提示“Everything up-to-date”且远程仓库没有变化，因为本地并没有新的提交可以推送。解决方法：先使用 git commit -m "描述" 提交本地改动，然后再 git push 将提交上传到远程。简单来说，每次 push 之前确保本地的改动都已经 commit。

• push 时提示拒绝（rejected）或要求先 pull： 这种情况通常发生在远程仓库比你的本地仓库更新，即远程有你本地没有的提交。如果强行推送会覆盖远程的新记录，所以 Git 拒绝了此次推送。解决方法：先使用 git pull 拉取远程更新并合并，然后解决可能的冲突（如果有），再尝试 git push。养成推送前先拉取的习惯可降低这种冲突发生的概率。

• 出现 “fatal: Not a git repository” 错误： 这表示当前目录不是一个 Git 仓库。可能原因是在未初始化的文件夹中执行了 Git 命令。解决方法：确认当前所在目录是否已经执行过 git init。如果没有，则进入正确的项目目录或者在当前目录下运行 git init 来初始化仓库。简单来说，确保自己始终在一个 Git 仓库内进行 Git 操作。