Git完全掌握：从入门、核心命令到GitHub、Gitee、GitLab实战教程

type

status

date

slug

summary

一、Git简介：版本控制的基石

Git 是一款开源的分布式版本控制软件，广泛用于管理项目版本和促进团队协作。Git 最初由 Linux 内核的创建者 Linus Torvalds 设计并开发，旨在高效管理 Linux 内核的开发工作。

1.1 为什么需要版本控制？

版本控制系统在软件开发中扮演着至关重要的角色，主要体现在以下两个方面：

项目备份与历史追溯：记录项目的每一次变更，方便回溯到任意历史版本，防止数据丢失。

团队协同开发：支持多人并行工作，有效管理代码合并，解决冲突，提高团队开发效率。

1.2 Git的传奇历史

许多开发者都知道，Linus Torvalds 在1991年创建了开源的Linux操作系统。随着Linux系统的不断发展，它已成为全球最大的服务器操作系统软件。

Linus 虽然是Linux的创始人，但其后续的蓬勃发展离不开全球热心志愿者的共同努力。想象一下，这么多来自世界各地的开发者为Linux编写代码，那么这些庞大的代码是如何被有效管理的呢？

事实是，在2002年以前，这些志愿者们主要通过 diff 的方式将源代码文件发送给 Linus，然后由 Linus 本人手动合并代码！

你可能会疑惑，为什么 Linus 不使用当时已有的版本控制系统呢？例如免费的CVS或SVN。原因在于 Linus 坚定地反对这些集中式版本控制系统，他认为它们不仅速度缓慢，而且必须联网才能工作。虽然市面上也有一些商业版本控制系统体验更佳，但它们是收费的，这与Linux的开源精神相悖。

然而，到了2002年，Linux系统已经发展了十年之久，代码库的规模使得 Linus 难以继续通过手工方式进行管理。社区的开发者们也对此表达了强烈的不满。于是，Linus 选择了一款商业版本控制系统——BitKeeper。BitKeeper的母公司BitMover出于人道主义精神，授权Linux社区免费使用这款工具。

这段看似和谐的局面在2005年被打破。Linux社区人才辈出，其中不乏一些具有“梁山好汉”般江湖习气的牛人。Samba的开发者 Andrew Tridgell 试图破解BitKeeper的协议（当然，这么做的不止他一人），不幸被BitMover公司发现（其监控工作相当到位！）。BitMover公司对此感到愤怒，决定收回对Linux社区的免费使用授权。

面对这一困境，Linus Torvalds 展现了他非凡的才能：他仅用了两周时间，亲自用C语言编写了一个全新的分布式版本控制系统——这就是Git！一个月之内，整个Linux系统的源码就迁移到了Git进行管理。何为“牛人”？大家可以细细体会。

Git 迅速成为最受欢迎的分布式版本控制系统。尤其是在2008年，GitHub网站正式上线，它为开源项目免费提供Git存储服务。无数知名的开源项目，如jQuery、PHP、Ruby等，纷纷迁移至GitHub。

历史往往充满了偶然。如果当年BitMover公司没有对Linux社区施压，或许我们今天就无法享受到免费且功能强大的Git了。

1.3 Git官方网站

二、Git的安装与配置

2.1 下载Git

您可以从Git官方网站的下载页面获取适合您操作系统的安装包：

2.2 安装Git

安装Git的过程非常简单，在大多数情况下，直接使用默认选项一路“下一步”即可完成安装。

2.3 验证安装与基本帮助

安装完成后，可以在命令行或终端中使用以下命令来验证Git是否安装成功，并查看版本信息或获取帮助：

三、Git文件的四种核心状态

Git 的工作流程通常如下：

在工作目录 (Working Directory) 中添加、修改文件。

将需要进行版本管理的文件（的快照）放入暂存区域 (Staging Area / Index)。

将暂存区域的文件提交到本地Git仓库 (Repository)。

因此，Git管理的文件主要有以下几种状态的演变，通常可以归纳为四种核心状态：

3.1 文件状态详解

版本控制的核心是对文件的版本进行管理。要对文件进行修改、提交等操作，首先需要了解文件当前所处的状态，以免误提交或漏提交。

Git 并不直接关心文件两个版本之间的具体差异内容，而是更关心文件的整体是否发生了改变。如果文件被修改，当执行添加和提交操作时，Git会为文件的新版本生成一个快照。判断文件整体是否改变的方法是使用SHA-1算法计算文件的校验和。

Untracked (未跟踪): 此文件存在于你的工作目录中，但尚未被Git纳入版本控制系统。它不参与版本控制。通过 git add 命令，其状态可以变为 Staged。

Unmodified (未修改): 文件已经成功存入Git仓库，并且工作目录中的文件版本与仓库中最新的快照完全一致。

如果对此类文件进行修改，它将变为 Modified (已修改) 状态。
如果使用 git rm 命令将其从版本控制中移除（并从工作目录删除），它可能会变回 Untracked（如果只是从暂存区移除但保留在工作区，则行为不同）。

Modified (已修改): 文件已被修改，但这些修改尚未被暂存。

通过 git add 命令，可以将这些修改暂存起来，文件状态变为 Staged (已暂存)。
使用 git checkout -- <file> 或 git restore <file> 命令，可以丢弃工作目录中的修改，使其恢复到 Unmodified 状态（即从仓库中取出最新版本覆盖当前修改）。

Staged (已暂存): 文件的当前修改已经被标记，准备包含在下一次提交中。

执行 git commit 命令，会将暂存区的修改同步到本地仓库中。此时，仓库中的文件与本地工作目录中的文件再次一致，文件状态恢复为 Unmodified。
执行 git reset HEAD <file> 或 git restore --staged <file> 命令，可以取消暂存，文件状态回退到 Modified。

状态转换示意（简要流程）：

新建文件 (工作目录中) → Untracked

执行 git add <file> → 文件从 Untracked 变为 Staged

执行 git commit → 文件从 Staged 变为 Unmodified (并记录到仓库)

修改 Unmodified 状态的文件 → 文件变为 Modified

执行 git add <file> (针对已修改的文件) → 文件从 Modified 变为 Staged (修改内容被暂存)

对 Unmodified 状态的文件执行 git rm <file> (并提交) → 文件从版本控制中移除。

(原文中提及的图示有助于理解，此处为纯文本描述)

四、Git常用命令概览

五、Git配置用户签名

5.1 签名的作用

当你想将本地项目的提交推送到远程仓库时，必须设置用户签名。签名的主要作用是标识用户身份，以便区分不同开发人员的贡献。每次提交都会记录签名信息。

5.2 设置方式

设置Git用户签名主要有两种方式：

单个仓库配置：为特定的Git仓库单独设置签名。这种配置只对当前仓库有效。

全局配置：为当前操作系统用户设置全局签名。采用这种方式配置后，该用户下的所有Git仓库都会默认使用此签名。

如果同时进行了单个仓库配置和全局配置，Git会优先使用单个仓库的配置信息。

5.3 配置格式与命令

方式一：单个仓库有效 (在仓库目录下执行)

说明：
用户名和邮箱地址请自行替换。
邮箱地址可以是有效的邮箱，也可以是符合邮箱格式的假邮箱。
此方式的配置信息会保存在当前仓库目录下的 .git/config 文件中，格式如下：

方式二：全局有效 (在任意位置执行)

说明：
此方式的配置信息会保存在系统用户主目录下的 .gitconfig 文件中 (例如，Windows下通常是 C:\\Users\\<YourUser>\\.gitconfig，Linux/macOS下是 ~/.gitconfig)。保存格式与单个仓库配置相同。

5.4 配置建议

一般情况下，建议配置全局有效的签名即可，这样更简单方便，无需为每个新仓库都单独设置。当特定项目需要使用不同的签名信息时，再进入该项目仓库，按照方式一单独配置即可覆盖全局设置。

六、Git初始化本地仓库

6.1 初始化命令

要在当前目录下创建一个新的Git仓库（即初始化一个本地库），使用以下命令：

执行此命令后，Git会在当前目录下创建一个名为 .git 的子目录，这个目录包含了初始仓库所必需的所有文件和元信息。

6.2 `.git` 目录结构详解

.git 目录是Git为你的项目存储所有历史记录和元信息的地方，它包含了所有的Git对象 (commits, trees, blobs, tags) 以及指向不同分支的引用。每个Git项目通常只有一个 .git 目录，默认位于项目的根目录下。

以下是 .git 目录中一些重要文件和子目录的说明：

HEAD: 一个特殊的文件，通常指向当前活动分支的引用 (例如 ref: refs/heads/master)。它告诉你当前工作在哪个分支上。

config: 存放当前仓库的特定配置信息。执行 git config (不带 -global 参数) 命令会修改此文件。

description: 仓库的描述信息，主要供GitWeb等程序使用。

hooks/: 存放客户端或服务器端钩子脚本的目录。这些脚本可以在Git执行特定操作（如提交前、推送后等）时自动运行。默认包含一些示例脚本。

index: 这是Git的暂存区 (Staging Area)，有时也称为索引文件。它是一个二进制文件，记录了你下次要提交的内容的快照信息。

logs/: 存放所有引用 (refs) 的历史操作信息。

logs/HEAD: 记录 HEAD 指针移动的历史。
logs/refs/heads/: 记录本地各分支顶端提交变化的历史。
logs/refs/remotes/: 记录远程跟踪分支顶端提交变化的历史。

objects/: 存放所有Git对象的目录，是Git仓库的核心。Git对象包括提交 (commits)、树对象 (trees)、数据块 (blobs) 和标签对象 (tags)。这些对象通过其SHA-1哈希值进行组织，哈希值的前2位作为子目录名，后38位作为文件名。

refs/: 存放引用的目录，引用是指向特定提交的指针。

refs/heads/: 包含所有本地分支的引用。每个文件名对应一个分支名，文件内容是该分支指向的最新提交的SHA-1哈希值。
refs/tags/: 包含所有标签的引用。每个文件名对应一个标签名。
refs/remotes/: 包含所有远程跟踪分支的引用（例如 refs/remotes/origin/master）。

七、查看Git状态

7.1 命令

要查看工作区和暂存区的当前状态，使用以下命令：

7.2 状态解读

git status 命令会告诉你哪些文件被修改了、哪些文件是新创建的（未跟踪的）、哪些文件已暂存准备提交等信息。常见的状态提示包括：

Changes to be committed:

这部分列出的是已经从工作区使用 git add 添加到暂存区的文件。这些文件将在下次执行 git commit 时被提交。

可以使用 git restore --staged <filename> (或 git reset HEAD <filename>) 命令将文件从暂存区移出（取消暂存），使其回到 Modified 或 Untracked 状态。

Changes not staged for commit:

这部分列出的是工作区中已被修改或删除，但这些更改尚未通过 git add 添加到暂存区的文件。这些文件之前是被Git跟踪的。

可以使用 git add <filename> 命令将这些变更（修改或删除）添加到暂存区。

可以使用 git restore <filename> (或 git checkout -- <filename>) 命令撤销在工作区对这些文件所做的修改（恢复到上次提交或暂存的状态）。

Untracked files:

这部分列出的是工作区中存在，但尚未被Git跟踪（即从未被 git add 过）的新文件或文件夹。

可以使用 git add <filename> 将它们添加到暂存区，开始对其进行版本控制。

八、Git将代码添加到暂存区 (`git add`)

8.1 基本用法

git add 命令用于将工作目录中的文件更改（或新文件）添加到暂存区，为下一次提交做准备。

添加一个或多个指定文件到暂存区：

添加指定目录及其子目录下的所有更改到暂存区：

添加当前目录及其子目录下所有更改到暂存区：

8.2 `git add .` vs `git add -u` vs `git add -A` 的区别

git add .

监控当前工作目录（及其子目录）的状态树。
它会将工作区中所有的新文件 (new/untracked) 和已修改文件 (modified) 的当前内容添加到暂存区。
不包括那些在工作区被删除但之前已被Git跟踪的文件（即，它不会将删除操作暂存起来）。

git add -u (或 git add --update)

仅监控那些已经被Git跟踪的文件 (tracked files)。
它会将所有已跟踪文件中被修改 (modified) 或被删除 (deleted) 的更改暂存起来。
不会添加任何新创建的未跟踪文件 (untracked files)。

git add -A (或 git add --all)

是以上两种功能的合集。
它会暂存工作区中所有已跟踪文件的修改和删除，以及所有新创建的未跟踪文件。基本上，它会同步工作区的所有变动到暂存区。

在较新版本的Git中，git add . 的行为可能更接近 git add -A 在当前目录下的效果，但理解这些选项的传统区别有助于精确控制暂存内容。

九、Git提交代码到本地仓库 (`git commit`)

9.1 作用

git commit 命令用于将暂存区中的内容（即通过 git add 暂存的更改）正式保存到本地Git仓库中，形成一个新的版本（提交记录）。

数据流向： 工作区 → (通过 git add) → 暂存区 → (通过 git commit) → 本地仓库 (→ (通过 git push) → 远程仓库)

9.2 基本命令

m [message] 参数用于直接在命令行中提供本次提交的描述信息。这是一个必需的参数，除非你配置了默认编辑器来撰写提交信息。

9.3 提交指定文件

通常不直接在 git commit 中指定文件，因为提交的是整个暂存区的内容。如果你只想提交暂存区中特定文件的更改，应确保只有这些文件的更改被 git add 到了暂存区。

然而，如果你想跳过 git add 步骤，直接提交工作区中已跟踪文件的修改（不包括新文件），可以使用 -a 选项：

注意：在现代Git中，git commit <file> 的行为更像是 git add <file> && git commit。但更推荐的流程是先用 git add 精确控制暂存区内容，再用 git commit 提交。

9.4 跳过暂存直接提交 (针对已跟踪文件)

a (或 -all) 参数可以让 git commit 自动将工作区中所有已跟踪文件的修改（包括删除）添加到暂存区，然后再执行提交。这相当于 git add -u 之后再执行 git commit。

重要：-a 选项不会自动添加未跟踪的新文件。新文件必须先使用 git add 添加到暂存区。

十、Git修改并提交代码的完整流程示例

修改代码文件：编辑你的项目文件，例如 main.js。

查看状态：

此时 git status 会显示 main.js 被修改 (modified)。

将修改添加到暂存区：

再次查看状态 (可选)：

现在 git status 会显示 main.js 的修改已暂存 (changes to be committed)。

提交到本地仓库：

查看版本信息 (提交历史)：

十一、Git项目版本切换与回溯

11.1 查看版本信息 (提交ID)

要切换版本，首先需要获取目标版本的提交ID (commit hash)。

11.2 切换版本 (重置)

使用 git reset 命令可以回退到指定的版本。--hard 选项会彻底重置工作区、暂存区和当前分支的指针到目标提交，丢弃目标提交之后的所有本地更改和提交。

警告：git reset --hard 是一个危险的操作，因为它会永久删除未提交的本地更改和指定提交之后的所有提交记录。请谨慎使用，并确保已备份重要工作。

11.3 再次查看版本信息

执行版本切换后，可以再次使用 git log 或 git reflog 来确认当前所处的版本。

11.4 查看文件内容

切换版本后，工作区的文件内容会更新为所选版本的状态。你可以直接打开文件查看，或使用命令行工具：

11.5 查看 `.git/refs/heads/master` (或其他分支)

分支的引用文件（如 .git/refs/heads/master）会存储该分支当前指向的提交的SHA-1哈希值。版本切换会更新这个文件。

11.6 从低版本切换回高版本

git reset --hard 同样可以用于从一个较旧的版本“前进”到一个较新的版本（如果该较新版本仍在你的提交历史中，例如通过 reflog 找到）。

十二、Git分支简介

12.1 为什么使用分支？

在软件开发中，分支是一种强大的机制，它允许你从主开发线（通常是 master 或 main 分支）分离出来，在一个独立的环境中进行工作，而不会影响到主线的稳定性。

隔离新功能开发或Bug修复：如果你要为项目添加一个新特性，或者修复一个bug，这些工作很可能会暂时破坏当前可正常工作的代码。直接在主分支上操作对其他用户或团队成员来说是很糟糕的。通过在独立的分支中进行这些变更，可以确保主分支的稳定。

促进团队协作与代码审查：Git 的设计初衷之一就是为了更好地支持协作。如果所有开发者都在同一个 master 分支上工作，很容易引发混乱和冲突。不同开发者的技术水平和编码习惯各异，可能会引入有错误的代码或不符合项目规范的代码。使用分支可以让团队成员在各自的分支上独立开发，完成后通过合并请求 (Pull Request / Merge Request) 的方式提交其贡献。这为代码审查提供了一个天然的流程，项目维护者可以选择性地将经过审查的、合适的代码合并到主项目中。

12.2 使用分支的好处

并行开发：允许多个功能或修复工作同时并行推进，互不干扰，从而提高整体开发效率。

风险隔离：各个分支的开发过程是独立的。如果某个分支上的开发尝试失败或引入了严重问题，不会对其他分支或主分支产生任何影响。失败的分支可以直接删除，然后从一个稳定点重新开始。

清晰的版本历史：通过分支和合并，可以形成一个结构化的提交历史，更容易理解项目的演进过程和不同功能的开发脉络。

实验性工作：可以创建临时分支进行实验性的代码修改或尝试新的技术方案，如果成功则合并，不成功则轻易丢弃。

十三、Git分支常用命令

查看分支：

创建分支：

删除分支：

重命名分支：

切换分支：

创建并切换到新分支：

合并分支：

十四、Git合并分支操作示例

创建新分支 (例如，用于修复一个bug)：

切换到新创建的分支：

在 bug-fix 分支上进行修改：编辑相关文件，例如 index.html。

在 bug-fix 分支上提交更改：

切换回主分支 (或其他你希望合并到的目标分支，例如 master)：

合并 bug-fix 分支到当前分支 (master)：

Git会尝试自动合并。如果合并成功，master 分支现在就包含了 bug-fix 分支上的更改。如果存在冲突，你需要先解决冲突再完成合并。

十五、解决Git合并分支冲突

15.1 冲突产生的原因

当合并两个分支时，如果它们在同一个文件的同一个位置都进行了修改，Git 无法自动判断应该保留哪个版本的修改，或者如何将两个版本的修改结合起来。这时就会发生合并冲突。

15.2 解决冲突实例步骤

假设我们有两个分支 master 和 hot-fix，它们都修改了同一个文件 config.txt 的同一行。

在 master 分支修改文件并提交：

切换到 hot-fix 分支，修改同一个文件并提交：

切换回 master 分支，尝试合并 hot-fix 分支：

此时，Git很可能会报告一个合并冲突，并在 config.txt 文件中用特殊标记（如 <<<<<<<, =======, >>>>>>>）标出冲突区域。

手动解决冲突：打开包含冲突的文件 (本例中是 config.txt)。你会看到类似下面的内容：

你需要根据实际需求，编辑这部分内容，决定最终保留哪个版本的修改，或者将两者结合起来。删除Git插入的冲突标记 (<<<<<<<, =======, >>>>>>> 以及分支名)。

将解决冲突后的文件添加到暂存区：

完成合并提交：执行 git commit。Git通常会自动生成一个合并提交的描述信息（你可以修改它）。此时不需要再加 m "message" 和文件名。

这样，合并冲突就成功解决了，并且 hot-fix 分支的更改（经过冲突解决后）已经合并到了 master 分支。

十六、GitHub：全球最大的代码托管平台

16.1 GitHub 官方网站

16.2 登录与注册GitHub

登录页面：

如果还没有账户，你需要先注册。

16.3 在GitHub上创建远程仓库

创建新仓库的页面：

按照页面提示填写仓库名称、描述、公开/私有等选项即可创建。

16.4 为本地仓库关联远程GitHub仓库 (创建别名)

将本地Git仓库与GitHub上创建的远程仓库关联起来，通常会为远程仓库指定一个别名（最常用的是 origin）。

查看当前已配置的远程仓库别名：

添加一个新的远程仓库别名 (例如 test-github)：

再次查看，确认添加成功：

十七、GitHub：推送本地库到远程

17.1 推送命令 (`git push`)

基本命令格式： git push <remote_alias> <local_branch_name>:<remote_branch_name> 如果本地分支名和要推送到的远程分支名相同，可以简化为：git push <remote_alias> <branch_name>

17.2 推送示例

假设你要将本地的 master 分支推送到名为 test-github 的远程仓库的 master 分支：

首次推送或当远程仓库需要身份验证时，Git会提示你输入GitHub的用户名和密码（或Personal Access Token）。

十八、GitHub：拉取远程库到本地

18.1 在线修改远程库代码 (模拟远程更新)

可以直接在GitHub网站上编辑文件并提交，以模拟远程仓库发生了变化。

18.2 拉取远程库更新到本地 (`git pull`)

git pull 命令会从指定的远程仓库获取最新的更改，并尝试将其合并到你当前的本地分支。命令格式： git pull <remote_alias> <remote_branch_name>

输出示例：

这表示本地 master 分支成功地从 test-github/master 拉取并合并了更新。

十九、GitHub：克隆远程库到本地

19.1 克隆命令 (`git clone`)

git clone 命令用于完整复制一个远程Git仓库到你的本地计算机。

19.2 克隆实例演示

新建一个本地目录，用于存放克隆下来的项目（模拟一个新用户或新环境）。

在该目录中打开Git Bash或终端。

执行克隆命令，使用远程仓库的URL (通常是HTTPS或SSH格式)：

19.3 克隆操作做了什么？

git clone 命令会自动完成以下几件事情：

完整拉取远程仓库的所有数据：包括所有文件的所有版本、所有分支和标签。

初始化本地仓库：在当前目录下创建一个与远程仓库同名的新目录（除非你指定了其他目录名），并在其中创建 .git 目录，设置好本地仓库。

自动创建远程仓库别名：默认会创建一个名为 origin 的远程别名，指向你克隆的远程仓库URL。

自动检出默认分支：通常是 master 或 main 分支，并将其设置为本地的当前工作分支，同时建立本地分支与远程跟踪分支 (origin/master 或 origin/main) 的关联。

二十、GitHub团队内协作流程

邀请团队成员：

项目所有者或管理员进入GitHub项目的 Settings。

选择 Manage access (或 Collaborators and teams)。

点击 Invite a collaborator (或 Add people)，输入团队成员的GitHub用户名或邮箱进行邀请。

被邀请者接受邀请后，即可对该仓库进行推送等操作。

团队成员修改代码：团队成员在自己的本地克隆副本中进行代码修改。

团队成员提交代码到本地仓库：

团队成员推送代码到远程GitHub仓库：

其他团队成员可以通过 git pull 获取这些更新。

二十一、GitHub跨团队协作 (Fork & Pull Request)

当你想为一个不属于你或你团队的开源项目贡献代码时，通常采用 Fork 和 Pull Request 的工作流程：

登录GitHub，搜索并找到你想贡献的项目。

Fork (复刻) 该项目：点击项目页面右上角的 "Fork" 按钮。这会在你自己的GitHub账户下创建一个该项目的完整副本（你的派生库）。

克隆你的派生库到本地，修改并提交：

创建 Pull Request (PR)：回到你在GitHub上的派生库页面，你会看到一个提示，建议你为最近推送的分支创建一个Pull Request。点击它，或者手动进入 "Pull requests" 标签页，点击 "New pull request"。

选择base repository (原始项目) 的目标分支 (通常是 master 或 main)。

选择head repository (你的派生库) 的包含你修改的分支 (my-feature-branch)。

填写PR的标题和详细描述，说明你的更改内容和原因。

点击 "Create pull request"。

项目维护者审查并 Merge (合并) Pull Request：原始项目的维护者会收到你的Pull Request。他们可以审查你的代码，提出评论或要求修改。如果他们认为你的贡献是合适的，就会将你的Pull Request合并到原始项目的代码库中。

二十二、GitHub免密登录 (SSH)

使用SSH密钥可以让你在与GitHub交互时（如 push, pull, clone SSH URL）无需每次都输入用户名和密码。

检查或生成SSH密钥对：

打开Git Bash或终端。

检查 ~/.ssh (Linux/macOS) 或 C:\\Users\\<YourUser>\\.ssh (Windows) 目录下是否已存在 id_rsa (私钥) 和 id_rsa.pub (公钥) 文件。

如果不存在，或想生成新的密钥对，执行：

复制公钥内容：打开 id_rsa.pub 文件（例如用文本编辑器），复制其全部内容。

在GitHub账户中配置SSH公钥：

登录GitHub。

进入 Settings (点击右上角头像 -> Settings)。

在左侧导航栏选择 SSH and GPG keys。

点击 New SSH key (或 Add SSH key)。

给这个Key起一个标题 (例如 "My Laptop")。

将复制的公钥内容粘贴到 "Key" 文本框中。

点击 Add SSH key。

测试SSH连接：在终端执行：

如果看到类似 "Hi <YourUsername>! You've successfully authenticated..." 的消息，说明配置成功。

使用SSH URL进行Git操作：现在，当你克隆或添加远程仓库时，应使用SSH格式的URL (例如 git@github.com:<YourUsername>/<RepositoryName>.git)，而不是HTTPS格式。

f (force push) 选项应谨慎使用，因为它会覆盖远程历史。原文中的 git push -f git@github.com:guohz/test-github.git master 是强制推送。

二十三、配置Git忽略文件 (`.gitignore`)

.gitignore 文件用于告诉Git哪些文件或目录不应该被跟踪（即不应被添加到版本控制中）。这通常包括编译产生的文件、日志文件、临时文件、IDE配置文件等。

23.1 项目局部 `.gitignore` 文件

进入项目根目录： cd /path/to/your/project

创建 .gitignore 文件： touch .gitignore (Linux/macOS) 或在文件浏览器中新建。

编辑 .gitignore 文件：将需要忽略的文件或目录模式（每行一个）添加到 .gitignore 文件中。下面是一个Java项目常用的 .gitignore 示例（节选自原文，已格式化）：

提交 .gitignore 文件：将 .gitignore 文件本身添加到Git仓库并提交，这样团队其他成员也能共享这些忽略规则。

23.2 Git全局忽略文件

可以配置一个全局的 .gitignore 文件，使其对当前用户下的所有Git仓库都生效。这样就不必为每个项目都创建和维护相似的忽略规则了。

创建或准备一个全局忽略文件：可以在用户主目录下 (例如 ~/.gitignore_global 或 C:\\Users\\<YourUser>\\.gitignore_global) 创建一个文件，内容与项目局部的 .gitignore 文件格式相同。可以将常用的忽略规则（如IDE配置文件、操作系统生成的文件等）放在这里。

配置Git使用全局忽略文件：执行以下命令，告诉Git使用你创建的全局忽略文件：

之后，所有Git仓库（包括新克隆或初始化的）都会自动应用这个全局忽略文件中的规则，除非项目局部的 .gitignore 文件覆盖了某些规则。

二十四、IDEA (IntelliJ IDEA) 集成Git

IntelliJ IDEA 提供了强大的Git集成功能，可以方便地在IDE内部执行大部分Git操作。

24.1 在IDEA中配置Git可执行文件路径

进入 File > Settings (或 IntelliJ IDEA > Preferences on macOS)。

导航到 Version Control > Git。

IDEA通常会自动检测Git的安装路径。如果未检测到或路径不正确，手动指定 git.exe (Windows) 或 git (Linux/macOS) 的可执行文件路径。

点击 Test 按钮验证配置。

24.2 为项目启用Git版本控制 (初始化本地库)

如果项目尚未进行版本控制，可以通过 VCS > Enable Version Control Integration...。

在弹出的对话框中选择 Git 作为版本控制系统，点击OK。这相当于在项目根目录执行了 git init。

24.3 取消项目Git集成

进入 File > Settings > Version Control。

在列表中选中你的项目根目录，然后点击减号 () 按钮移除其版本控制关联。这不会删除 .git 目录，只是让IDEA不再将其视为Git项目。

24.4 IDEA中切换Git版本 (Checkout Revision)

提交几次代码以产生一些版本历史。

打开Git工具窗口 (通常在IDE底部，或通过 View > Tool Windows > Git)。

切换到 Log 标签页，这里会显示项目的提交历史。

在提交列表中，右键点击你想要切换到的目标提交版本。

选择 Checkout Revision '...'。IDEA会提示你是否要创建一个分离的HEAD（detached HEAD）或者创建一个新分支指向该提交。

24.5 IDEA中创建和切换分支

创建新分支：

可以通过主菜单 Git > New Branch...。
或者在IDE右下角的状态栏找到当前分支名称，点击它，在弹出的分支列表中选择 + New Branch。
输入新分支的名称，选择是否检出 (checkout) 新分支，点击Create。

切换分支：

在IDE右下角的状态栏点击当前分支名称。
在弹出的分支列表中，选择你想要切换到的本地分支或远程跟踪分支，然后点击 Checkout。

24.6 IDEA中合并分支

确保当前已切换到你希望接收合并的分支 (例如 master)。

通过主菜单 Git > Merge Changes...。

在弹出的对话框中，选择你想要合并到当前分支的源分支 (例如 feature-branch)。

点击 Merge。IDEA会尝试合并，如果出现冲突，会提供冲突解决工具。

24.7 IDEA中合并分支并解决冲突

执行合并操作（如上所述）。

如果发生冲突，IDEA的 Merge Revisions (或类似名称的) 对话框会列出冲突文件。

双击冲突文件，或选中后点击 Merge... (或 Resolve) 按钮，会打开IDEA强大的三向合并工具。

在合并工具中，你可以查看左右两侧（你的更改和他们的更改）以及中间的结果面板。手动选择接受哪些更改，或者编辑结果面板来合并两者。

解决完所有冲突后，标记文件为已解决 (通常会自动标记)。

完成所有冲突解决后，IDEA会提示你完成合并提交 (commit the merge)。

二十五、在IDEA中配置GitHub账户

进入 File > Settings > Version Control > GitHub。

点击加号 (+) 或 Add account... 按钮。

你可以选择：

Log In via GitHub...: 会打开浏览器进行OAuth授权登录。

Log In with Token...: 使用GitHub Personal Access Token登录。

25.1 使用Token登录GitHub (推荐)

在GitHub上生成Personal Access Token (PAT)：

登录GitHub。

进入 Settings > Developer settings > Personal access tokens > Tokens (classic) (或 Fine-grained tokens)。

点击 Generate new token (or Generate new token (classic))。

给Token一个描述性的名称。

选择Token的过期时间。

勾选必要的权限范围 (scopes)。对于IDEA集成，通常需要 repo (完全控制私有仓库)、gist、workflow 等。如果使用Fine-grained tokens，则需要更细致地配置仓库权限。

点击 Generate token。

立即复制生成的Token。这个Token只会显示一次，关闭页面后将无法再次看到。请妥善保管。

在IDEA中使用Token登录：回到IDEA的GitHub账户配置界面，选择 "Log In with Token..."，粘贴你复制的Token，点击Log In。

二十六、在IDEA中推送项目到GitHub

26.1 首次共享项目到GitHub

如果你的本地项目尚未与GitHub关联：

可以通过主菜单 VCS > Import into Version Control > Share Project on GitHub (或 Git > GitHub > Share Project on GitHub)。

IDEA会引导你填写仓库名称、描述、选择私有/公开，然后创建远程仓库并将本地项目推送上去。

26.2 推送本地提交到GitHub (`git push`)

在本地进行代码修改并提交 (Commit) 到Git。

通过主菜单 Git > Push... (或快捷键 Ctrl+Shift+K / Cmd+Shift+K)。

在弹出的 Push Commits 对话框中，确认要推送的本地分支和目标远程分支。

点击 Push。

二十七、在IDEA中从GitHub拉取项目更新

模拟远程仓库更新：例如，在GitHub网站上直接编辑并提交文件，或者团队其他成员推送了更新。

拉取远程更新到本地 (git pull)：

通过主菜单 Git > Pull...。

在 Pull Changes 对话框中，确认要拉取的远程分支和合并策略。

点击 Pull。IDEA会执行 git fetch 和 git merge (或 git rebase，取决于你的配置)。

拉取完成后，查看代码变化，解决可能出现的冲突。

二十八、码云Gitee：国内领先的代码托管平台

28.1 Gitee简介

Gitee (码云) 是由开源中国 (OSChina) 开发和运营的一款基于Git的代码托管平台。它提供了代码托管、项目管理、团队协作等功能，是目前中国国内规模较大的代码托管服务之一。与GitHub类似，但Gitee对于国内用户而言，访问速度通常更快，并且免费账户也支持创建私有仓库。

28.2 注册Gitee

Gitee官方网站：

访问官网进行注册。

二十九、IDEA集成码云Gitee

安装Gitee插件：

进入 File > Settings > Plugins。

在 Marketplace 中搜索 "Gitee"，找到官方或推荐的Gitee插件并安装。

重启IDEA使插件生效。

登录Gitee账户：

插件安装后，通常会在 File > Settings > Version Control 下出现 "Gitee" 选项。

在此处配置你的Gitee账户信息，可能需要用户名/密码或Token。

推送 (Push) 项目到Gitee：

类似于GitHub，如果项目是首次共享，可以使用插件提供的 "Share Project on Gitee" 功能。

对于已关联的Gitee远程仓库，使用 Git > Push...，选择Gitee的远程进行推送。

拉取 (Pull) Gitee项目更新：

使用 Git > Pull...，选择Gitee的远程进行拉取。

三十、GitLab：企业级自托管Git仓库方案

30.1 GitLab定位

GitLab 是一个基于Git实现的、功能全面的在线代码仓库托管和DevOps平台。它不仅提供代码托管，还集成了CI/CD、项目管理、问题跟踪、Wiki、容器注册表等众多功能。GitLab 可以作为SaaS服务使用 (gitlab.com)，也可以下载其开源社区版 (CE) 或付费企业版 (EE) 进行自托管 (self-hosted)，在企业或学校的内部网络中搭建私有的Git服务。这对于软件工程质量管理和内部代码安全至关重要。

30.2 GitLab核心功能

代码仓库托管 (基于Git)

代码审查 (Merge Requests)

持续集成/持续部署 (CI/CD)

问题跟踪 (Issues)

项目Wiki

容器注册表

强大的权限管理和用户管理

支持敏捷项目管理 (Epics, Milestones, Boards)

30.3 GitLab版本

社区版 (Community Edition - CE)：开源免费，功能丰富，适合大多数团队和中小型企业。

企业版 (Enterprise Edition - EE)：在CE基础上增加了更多高级功能，如高级分析、增强的安全性、高可用性支持等，提供付费订阅。

30.4 GitLab官方网站

三十一、GitLab安装与初始化 (基于Docker)

使用 Docker 是部署 GitLab 的一种便捷方式。

31.1 下载GitLab Docker镜像

可以从 Docker Hub 搜索官方或社区维护的GitLab镜像。 Docker Hub:

搜索 gitlab/gitlab-ce (社区版) 或 gitlab/gitlab-ee (企业版)。

31.2 拉取指定版本的GitLab CE镜像 (示例)

原文中提到的 twang2218/gitlab-ce-zh:11.1.4 是一个较旧的、可能包含中文本地化的社区镜像。推荐使用官方最新稳定版。例如，拉取官方最新的社区版：

或者指定一个具体版本，如：

31.3 运行GitLab容器

一个基本的运行命令示例如下（请根据实际需求调整端口、卷挂载和配置）：

注意：
原文中的 p 3000:80 将宿主机的3000端口映射到容器的80端口。如果你的GitLab配置为HTTP访问，可以通过 http://<宿主机IP>:3000 访问。
-name gitlab 给容器命名为 gitlab。
tag 在原文中应为实际的镜像标签，如 gitlab/gitlab-ce:latest 或 twang2218/gitlab-ce-zh:11.1.4。
首次启动GitLab容器可能需要几分钟时间进行初始化。初始化完成后，访问配置的URL，会引导你设置管理员 (root) 用户的初始密码。

后续管理和配置GitLab，请参考其官方文档。