Github详解: 从入门到精通

哎呀也是叫我用上“从入门到精通”这个经典标题了，鉴于很多人搞不懂Git和Github的关系，而且也不怎么会使用Git工具，故而写了这篇博客文章，相比于其他介绍Git的文章，我加入了一些类比，希望能达到更好的理解效果。如果还有什么疑问，欢迎在评论区提出！

本篇为入门篇，相对全面地介绍了Git的基本指令用法，后续会有实践篇，我会给出一个Github代码仓库，可供Fork下来进行自己的练习。

Git 是一个本地版本控制工具，可以在本地记录文件的修改历史。GitHub 则是一个基于云端的代码托管平台，提供 Git 仓库的存储和协作功能。

两者的关系可以这样理解：

Git 是写作工具

• 想象一下 Git 就像是你手头上的笔记软件。当你在写一篇文章（相当于在进行软件开发过程中的代码编写）时，你可以用这个笔记软件随时对文章进行保存（对应 Git 中的提交操作）。每一次保存，你都可以记录下文章在这一刻的具体内容和状态，包括文字的增删改等细节，就像是 Git 能够记录代码的每一次修改细节，知道是谁修改的、什么时候修改的以及修改了哪些地方。

• 这个笔记软件还允许你创建不同的章节或者子文档（类似于 Git 的分支功能）。比如，你可以在主文档基础上开辟一个专门用于尝试新写作思路的章节，不用担心会影响主文章内容。在软件开发中，开发人员就可以利用 Git 的分支在不影响主代码库的情况下进行新功能的开发或者对现有功能进行优化。

• 而且，你可以随时回到之前保存的任何版本（这体现了 Git 的版本回溯功能）。如果在写作过程中发现某个修改方向出现了错误，你可以轻松地回到你觉得正确或者满意的那个版本，重新进行编辑。对于代码来说，这就像是在开发过程中遇到 bug 或者不可行的方案时，能够回到之前的稳定版本继续工作。

GitHub 是在线图书馆

• GitHub 就像是一个大型的在线图书馆。当你完成了自己的文章（代码项目）后，你可以将它 “出版” 到这个图书馆（相当于将代码仓库推送到 GitHub）。这样，世界各地的其他作者（开发者）都可以看到你的文章。他们可以阅读你的文章内容（浏览代码），了解你的写作思路（理解代码功能和架构）。
• 这个图书馆还提供了一个很好的交流环境。其他作者可以对你文章中的一些观点提出自己的看法（相当于在 GitHub 上进行代码评论和讨论）。他们指出文章的优点或者可能存在的错误，你可以根据这些反馈来改进你的文章（优化代码）。同时，你也可以参考图书馆中其他优秀作者的作品，借鉴他们的写作风格或者结构（学习其他项目的代码架构和算法思想）。
• 你还可以和他人在图书馆中合作开展一个大型的写作项目（开源项目或者团队开发）。你们可以在图书馆专门开辟一个区域（GitHub 仓库）来共同编辑和整理一本书（进行代码协作），每个人都通过自己的写作工具（Git）对书的内容进行修改和补充，并且将这些修改同步到图书馆（GitHub 仓库）中，让其他合作者也能看到最新的内容变化。

（一）安装 Git

• Windows 系统 ：访问Git 官网，下载适合 Windows 的安装包。运行安装程序，按照安装向导进行操作。在安装过程中，可以选择默认的设置，它会将 Git 添加到系统环境变量中，方便在命令提示符（CMD）或 PowerShell 中使用 Git 命令。
• macOS 系统 ：可以通过 Homebrew 包管理工具安装。如果尚未安装 Homebrew，可以在终端中运行 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 进行安装。安装完成后，在终端中输入 brew install git 命令即可安装 Git。
• Linux 系统（以 Ubuntu 为例） ：打开终端，输入 sudo apt update 命令更新软件包列表。然后输入 sudo apt -y install git 命令来安装 Git。

（二）配置 Git 个人信息

安装完成后，需要配置 Git 的用户名和邮箱，这些信息将用于标识你在 Git 提交中的身份。在终端中运行以下命令：

git config --global user.name "你的用户名"
git config --global user.email "你的邮箱地址"

例如：

git config --global user.name "AstreoX"
git config --global user.email "Gskyer@outlook.it"

可以通过以下命令查看配置是否成功：

git config --list

（一）初始化仓库

• 创建新仓库 ：首先在本地创建一个项目文件夹，例如 my_project。进入该文件夹，使用 git init 命令将它初始化为一个 Git 仓库。这会在文件夹中创建一个隐藏的 .git 子目录，用于存储版本控制相关的元数据，如提交历史、分支信息等。这就像在空地上打好地基，准备建造一座城堡， initialize 是打地基的过程， .git 目录是地基的一部分，为后续的城堡建设（项目开发）奠定基础。
• 克隆现有仓库 ：如果需要从远程仓库（如 GitHub 上的仓库）获取代码，可以使用 git clone [repository URL] 命令。例如 git clone https://github.com/user/example-repo.git，这会将远程仓库的全部内容和历史记录复制到本地指定的目录（默认为仓库名称）。这就好比你看到了别人建好的一座漂亮城堡（远程仓库），你想在自己的地盘（本地）也建一座一模一样的，于是你用克隆命令把别人的城堡蓝图和建筑材料（项目代码和历史记录）都搬过来，准备开始建造。

（二）文件状态管理

• 查看文件状态 ：使用 git status 命令可以查看工作目录中文件的状态，包括哪些文件已修改、已暂存或未跟踪等。例如，当你修改了文件 index.html 后，git status 会显示它为已修改状态。这就像是在建筑工地上，你先大致看一下哪些材料已经被切割（文件被修改）、哪些材料已经被搬运到指定位置准备使用（文件被暂存）、哪些材料是新进来的还没决定怎么用（文件未跟踪）。
• 暂存文件更改 ：如果对文件的修改感到满意，想要将这些修改纳入版本控制，可以使用 git add [file name] 命令将文件的更改暂存到暂存区（Staging Area）。例如 git add index.html。如果要暂存所有修改的文件，可以使用 git add . 命令。暂存区就像是建筑工地上的一个临时材料堆放区，你把打算用到接下来建筑过程中（下次提交）的材料（文件修改）先集中堆放到这里，等准备好一批后一起运到建筑主体（提交到仓库）。
• 查看暂存区内容 ：通过 git diff --staged 命令可以查看暂存区中文件的更改内容，即即将提交到仓库的更改。这就像是在材料堆放区仔细检查每个材料（文件修改），确认它们是否符合要求，是否就是你准备接下来要用的那些。

（三）提交更改

• 提交暂存区内容 ：使用 git commit -m "[commit message]" 命令将暂存区的内容提交到本地仓库的历史记录中。例如 git commit -m "Add index.html file"。提交信息（commit message）应该简洁明了地描述本次提交的内容和目的。这就像在建筑工地上，当你完成了一部分建筑工作（对文件进行了一系列修改并暂存），你拍照记录下当前的建筑状态（提交暂存区内容），并在照片背面写上简短的说明（commit message），比如 “建好了城堡的第一层墙面”，以便以后查看这张照片时能快速了解当时的工作内容。
• 跳过暂存区直接提交（不推荐常规使用） ：如果不想将文件添加到暂存区再提交，可以使用 git commit -a -m "[commit message]" 命令。这会自动将所有已跟踪文件的修改（即之前已经被 Git 管理的文件的更改）提交，但不会添加新的未跟踪文件。这就像是在建筑工地上，不先集中堆放材料（暂存），而是直接把现场所有的旧材料（已跟踪文件）的改动情况都记录下来，这种方式容易遗漏新材料（未跟踪文件），所以不建议经常使用。
• 查看提交历史 ：运行 git log 命令可以查看本地仓库的提交历史记录，包括提交的哈希值（commit hash）、作者、日期和提交信息等。可以使用 git log --oneline 命令以简洁的单行格式查看提交历史。这就像是翻看建筑工地上的那本记录着每次建筑进度的照片相册（提交历史），每张照片都有唯一的编号（commit hash）、拍摄者（作者）、拍摄日期和简短说明（提交信息），你可以详细查看，也可以用简洁的方式快速浏览每张照片的主要内容（提交的大致情况）。

（一）添加远程仓库

• 添加远程仓库地址 ：如果已经有一个本地仓库，并且想要将其与远程仓库关联，可以使用 git remote add [remote name] [repository URL] 命令。通常，remote name 使用默认的 origin。例如 git remote add origin https://github.com/user/my-project.git。这就像是你的城堡（本地仓库）建好后，你告诉快递员（Git）如何把你的城堡介绍资料（项目代码）送到远方的展示中心（远程仓库），你给了快递员展示中心的详细地址（repository URL），并给这个快递路线起了个名字（remote name），方便以后让快递员按这个路线送货。
• 查看远程仓库信息 ：通过 git remote -v 命令可以查看当前本地仓库关联的所有远程仓库及其 URL 地址。这就像是查看所有设定好的快递路线（关联的远程仓库信息），确认每个路线对应的目的地（仓库 URL）是否正确。

（二）推送本地更改到远程仓库

• 首次推送 ：在确保本地仓库已经提交了所需的更改后，使用 git push -u [remote name] [branch name] 命令将本地更改推送到远程仓库。例如 git push -u origin main（假设分支名称为 main）。这里的 -u 参数会将远程仓库和本地分支关联起来，以后就可以直接使用 git push 命令来推送更改。这就像是第一次通过设定好的快递路线（关联的远程仓库），把你的城堡的新建部分资料（本地提交的更改）送到展示中心（远程仓库），同时用 -u 参数告诉快递员以后沿着这条路线送货时重点关注展示中心的哪个展厅（关联远程仓库和本地分支），以后就不用再特别指明展厅，直接让快递员按之前说好的方式送货（直接用 git push）就行。
• 后续推送 ：在关联成功后，之后只需要使用 git push 命令就可以将本地分支的更改推送到对应的远程分支。这就像是快递员已经熟悉了送货路线和展厅位置，你只需要说 “送货”，快递员就知道该怎么做了。

（三）从远程仓库拉取更改

• 拉取远程更改 ：如果远程仓库有新的更改，想要更新本地仓库，可以使用 git pull [remote name] [branch name] 命令。例如 git pull origin main。这会自动将远程仓库的更改合并到本地当前分支中。这就像是展示中心（远程仓库）的城堡资料（项目代码）更新了，你通知快递员（Git）把最新的资料（远程更改）取回来，并自动整合到你本地的城堡资料（本地分支）中，方便你查看和继续开发。
• 只获取远程信息但不合并（先进一步查看） ：使用 git fetch [remote name] 命令可以从远程仓库获取最新的分支信息等，但不会自动合并更改。然后可以通过 git log 命令查看远程分支和本地分支的差异等，再决定是否进行合并。这就像是先让快递员把展示中心的最新城堡资料目录（远程分支信息）拿回来，你自己先看看目录（用 git log 查看差异），决定是否要让快递员把具体资料（更改内容）也取回来并整合到本地资料中。

（一）创建分支

• 创建新分支 ：使用 git branch [branch name] 命令可以创建一个新的分支。例如 git branch feature-branch 创建一个名为 feature-branch 的新分支。此时，工作目录的内容仍然是当前分支（如 main 分支）的状态。这就像是在建城堡的过程中，你从主城堡区域（main 分支）开辟出一块新的空地（新分支），打算在这里尝试建设一个新功能区域（比如一个花园，对应 feature-branch 分支），但此时你还没有转到这块新空地去干活，主城堡区域还是原来的样子。
• 切换分支 ：要切换到新创建的分支，可以使用 git checkout [branch name] 命令。例如 git checkout feature-branch。切换后，工作目录中的文件会变为新分支对应的状态。这就像是你放下手头主城堡区域（原分支）的活儿，转到新开辟的花园区域（新分支）开始建设，工作环境（工作目录文件）就变成了花园区域的初始状态。
• 简化创建并切换分支的操作 ：可以使用 git checkout -b [branch name] 命令一步完成创建并切换到新分支的操作，如 git checkout -b bug-fix。这就像是你直接说 “我要在城堡边开辟个新区域专门修个消防设施（bug-fix 分支）并马上去那干活”，这个命令一次性完成了开辟新区域（创建分支）和转到那干活（切换分支）的操作。

（二）查看分支

• 查看本地分支 ：运行 git branch 命令可以查看本地所有的分支列表。当前所在的分支前会有一个星号（*）标识。这就像是查看城堡四周所有已开辟的区域（本地分支）的列表，当前你正在干活的那个区域（当前分支）前面会插着个小旗子（星号标识）。
• 查看远程分支 ：使用 git branch -r 命令可以查看远程仓库的分支列表。这就像是查看展示中心（远程仓库）里各个展厅（远程分支）的目录，看看里面都存放着哪些版本的城堡资料。
• 查看所有分支（包括本地和远程） ：通过 git branch -a 命令可以查看本地和远程的所有分支。这就像是同时查看自己城堡周边的所有区域（本地分支）和展示中心的展厅目录（远程分支），全面了解所有分支情况。

（三）合并分支

• 合并分支到当前分支 ：假设当前在 main 分支，想要合并 feature-branch 分支的更改，可以使用 git merge [branch name] 命令，即 git merge feature-branch。Git 会根据两个分支的提交历史找到共同的祖先提交，然后合并更改。如果在合并过程中出现冲突，Git 会提示你解决冲突。这就像是你建好了花园区域（feature-branch 分支）的新功能，现在想把这部分建设成果整合到主城堡区域（main 分支）。Git 会查看花园建设和主城堡建设的历史记录，找到它们最初分叉（共同祖先提交）的地方，然后把花园的新建设内容整合到主城堡区域。如果在这个过程中，比如花园和主城堡都对同一块地的用途有不同规划（合并冲突），Git 就会提醒你过来协调，决定到底这块地该怎么用。
• 解决冲突 ：当合并出现冲突时，Git 会在冲突的文件中标记冲突的内容。你需要手动编辑这些文件，解决冲突的部分（例如，保留正确的代码逻辑）。解决完冲突后，使用 git add [conflicted file] 命令将修改后的文件标记为已解决冲突，然后再使用 git commit 命令完成合并提交。这就像是你亲自来到那块有争议的地，把花园和主城堡对该地的不同规划进行协调，确定最终的用途，修改好规划图（解决冲突文件内容），然后告诉施工人员（git add）这块地的规划已经确定了，最后记录下这次规划整合的操作（git commit）。

（四）删除分支

• 删除本地分支 ：使用 git branch -d [branch name] 命令可以删除本地分支。例如 git branch -d feature-branch。如果分支尚未合并，Git 默认不允许删除，除非你使用 -D 参数强制删除（不推荐轻易使用，因为可能会丢失更改）。这就像是你要拆除城堡周边的一个区域（本地分支），如果这个区域有些建设内容还没整合到主城堡（未合并分支），Git 默认会阻止你，因为这样可能会丢失那些有价值的建设成果。除非你用 -D 参数强制拆除（不推荐，容易造成损失），不然还是先整合好再拆除更稳妥。
• 删除远程分支 ：要删除远程分支，可以使用 git push [remote name] --delete [branch name] 命令。例如 git push origin --delete bug-fix。这就像是通知快递员把展示中心里的某个展厅（远程分支）拆除，以后这个展厅里的资料就不存在了，团队成员再也看不到这个分支的内容了。

（一）创建标签

• 轻量级标签 ：使用 git tag [tag name] 命令可以创建一个轻量级标签。例如 git tag v1.0。轻量级标签就像一个指向特定提交的指针，不包含额外的信息。这就像是你在城堡的一张重要照片（某个关键提交）背面简单地写了个编号（tag name），方便以后快速找到这张照片，但没有写其他说明内容。
• 附注标签（推荐） ：使用 git tag -a [tag name] -m "[tag message]" 命令可以创建附注标签。例如 git tag -a v1.0.1 -m "Release version 1.0.1"。附注标签会包含标签信息，如标签名、日期、消息等，更适合用于标记重要的版本发布。这就像是你在那张重要照片（特定提交）后面不仅写了编号（tag name），还详细记录了拍摄日期（日期）、照片里的建筑内容说明（tag message）等丰富信息，这样以后查看时能更全面地了解这个版本的背景和重要性。

（二）查看标签

• 查看所有标签 ：运行 git tag 命令可以查看本地仓库中的所有标签。这就像是查看一个相册（本地仓库标签），里面存放着所有带编号和说明的照片（标签），你可以快速浏览有哪些版本被标记过。
• 查看标签详细信息 ：对于附注标签，可以使用 git show [tag name] 命令查看标签的详细信息，包括提交信息、标签消息等内容。这就像是打开某张详细标记过的照片，不仅能看到照片本身（提交基本信息），还能看到背后写的日期、说明等所有详细内容（标签详细信息）。

（三）推送和拉取标签

• 推送标签到远程仓库 ：使用 git push [remote name] [tag name] 命令可以将单个标签推送到远程仓库。例如 git push origin v1.0。如果要推送所有标签，可以使用 git push origin --tags 命令。这就像是把本地相册里的某一张照片（单个标签）或者全部照片（所有标签）都拿去展示中心（远程仓库）进行展示，方便团队成员或者其他人查看这些重要版本的标记。
• 从远程仓库拉取标签 ：可以使用 git fetch --tags 命令从远程仓库获取所有的标签。如果只获取特定标签，可以使用 git fetch [remote name] [tag name] 命令。这就像是从展示中心（远程仓库）把所有的或者特定的标签照片（标签）都取回本地相册（本地仓库），方便自己查看这些版本标记。

（一）撤销工作目录中的修改

• 撤销单个文件的修改 ：如果只是想丢弃工作目录中某个文件的修改，可以使用 git checkout -- [file name] 命令。例如 git checkout -- index.html。这会将文件恢复到上次暂存或提交时的状态。这就像是在建筑工地上，你对某块砖（文件）刚做的修改（比如涂了颜料）不满意，你想恢复它之前没涂颜料（上次暂存或提交时）的样子，于是你用这个命令把颜料擦掉，让砖回到之前的状态。
• 撤销所有文件的修改 ：使用 git checkout -- . 命令可以撤销工作目录中所有文件的修改，将工作目录恢复到与上次暂存或提交一致的状态。这就像是整个建筑工地现场（工作目录）刚有些混乱，砖啊、木板啊都被随意涂画（文件被修改），你不想保留这些修改，于是用这个命令把所有材料都恢复到上次整理好（暂存或提交时）的样子，工地又变得整洁规范了。

（二）从暂存区撤销修改

• 从暂存区移除单个文件 ：如果想要将某个已经暂存的文件从暂存区移除，但保留工作目录中的修改，可以使用 git reset [file name] 命令。例如 git reset index.html。这样文件又回到未暂存的已修改状态。这就像是你把一堆准备用于接下来建筑（暂存区的文件）的材料（文件）中的某一块砖（单个文件）从建筑用料区（暂存区）挪开，但它还在工地上（工作目录修改保留），你可能还想对这块砖进一步加工修改后再利用。
• 从暂存区移除所有文件 ：使用 git reset 命令可以将暂存区中的所有文件移除，但不会改变工作目录中的文件内容，文件仍然处于已修改状态。这就像是你把所有原本计划用于接下来建筑施工（暂存区文件）的材料（文件）都从建筑用料区（暂存区）挪开，但它们都还放在工地上（工作目录修改保留），你可以重新评估这些材料是否要用，或者怎么用。

（三）回退提交

• 回退到指定提交（并丢弃后续提交） ：使用 git reset --hard [commit hash] 命令可以将当前分支的 HEAD 指针回退到指定的提交哈希值对应的提交，并且会丢弃该提交之后的所有提交更改。这是一个非常危险的操作，因为会丢失后续的提交数据。例如 git reset --hard 6e207c9（假设 6e207c9 是要回退到的提交哈希值的前几位）。这就像是你发现城堡建到某一层（指定提交）后，后续的建设出现了严重问题，你决定直接拆除这一层以后的所有建筑（丢弃后续提交），回到那一层的状态（回退到指定提交）。但这个操作不可逆，拆除的部分就没了，所以很危险，要谨慎使用。
• 回退到指定提交（保留后续提交作为未暂存的修改） ：使用 git reset [commit hash] 命令（不加 --hard 参数）回退到指定提交时，会保留该提交之后的更改作为未暂存的修改。这就像是你沿着城堡的楼梯（提交历史）往下走，回到某一层（指定提交），但你把后续楼层（后续提交）的建筑材料（文件修改内容）都搬下来，堆放在这一层（保留为未暂存的修改），你可以根据需要决定是重新利用这些材料，还是丢弃它们。

（一）在 GitHub 上创建仓库

1. 登录 GitHub 官网（[https://github.com/](https://github.com/)）。
    2. 点击右上角的 “+” 号，选择 “New repository” 选项。
    3. 在 “Repository name” 中输入仓库名称，可以添加可选的描述信息。
    4. 选择仓库的访问权限（公开或私有）。
    5. 可以选择是否初始化仓库（例如添加一个 README 文件），然后点击 “Create repository” 按钮。这就像是在展示中心（GitHub 平台）里申请一块新的展区（创建仓库），你给这个展区起了名字（Repository name），写了个简介（描述信息），设定好是公开让所有观众参观（公开仓库）还是只让特定的人参观（私有仓库），还可以先放个简单的说明牌（README 文件），最后确认完成展区的建立。

（二）将本地仓库与 GitHub 仓库关联

1. 在本地仓库中，使用 `git remote add origin [repository URL]` 命令添加远程仓库地址。例如 `git remote add origin https://github.com/user/my-project.git`。这就像是把本地的城堡（本地仓库）和展示中心的展区（GitHub 仓库）用一条专用道路（关联）连接起来，告诉城堡里的人（Git）展区的具体位置（repository URL），方便以后运输资料（代码）。
    2. 可以使用 `git remote -v` 命令查看远程仓库是否关联成功。这就像是检查这条专用道路（远程仓库关联）是否真的修建好，是否可以正常使用。

（三）协作工作流程

• Fork 与 Pull Request（适用于开源项目贡献）

  • Fork 仓库 ：如果想要为一个开源项目贡献代码，而你没有直接写入权限，可以点击项目仓库页面上的 “Fork” 按钮，将仓库复制到自己的 GitHub 账号下。这就像是看到展示中心有个很受欢迎的城堡模型（开源项目仓库），你特别想参与完善它，但你没有直接在原模型上修改的权限。于是你用 Fork 按钮在自己的展区（自己 GitHub 账号下）复制了一份这个城堡模型，准备在自己的地盘上进行改进。
  • 克隆 Fork 后的仓库到本地 ：使用 git clone [forked repository URL] 命令将 Fork 后的仓库克隆到本地。这就像是把复制到自己展区的城堡模型资料（Fork 后的仓库）再下载到自己的工作室（本地），方便你实际动手修改完善。
  • 在本地进行更改和提交 ：创建新分支（如 feature-branch），进行代码修改，提交更改到本地分支。这就像是在工作室里，你针对城堡模型的新功能（feature-branch 分支）进行建造和修改，定期记录下自己的工作成果（提交修改）。
  • 推送到自己的 Fork 仓库 ：使用 git push origin feature-branch 命令将本地分支推送到自己 Fork 后的仓库。这就像是把自己的改进后的城堡模型部分（本地分支更改）通过物流（git push）运送到自己展区的仓库里进行展示，方便别人查看你的成果。
  • 创建 Pull Request ：在自己 Fork 后的仓库页面，点击 “New pull request” 按钮。选择要合并的分支（通常是自己的特性分支和原项目的主分支，如 main 或 master），填写 Pull Request 的标题和描述，说明自己的更改内容和目的，然后提交 Pull Request。原项目的维护者会收到通知，对 Pull Request 进行审查、讨论和可能的合并。这就像是你向原城堡模型的作者（开源项目维护者）发去一个邀请函（Pull Request），详细说明你做的改进（标题和描述），请他们来你的展区参观这部分改进，并询问是否可以把你的改进整合到他们的原模型中（请求合并到原项目的主分支）。

• 团队协作（使用远程仓库）

  • 克隆团队仓库到本地 ：团队成员使用 git clone [team repository URL] 命令克隆团队的远程仓库到本地。这就像是团队每个成员都从团队共享的城堡设计资料库（团队远程仓库）里把资料下载到自己的工作室（本地），准备开始自己的建设任务。
  • 在本地创建分支并开发 ：每个成员在本地创建自己的分支（如 dev-member1），进行开发工作，在自己的分支上提交更改。这就像是每个团队成员在自己的工作室里，针对城堡的不同部分（自己的分支）进行建设工作，定期记录自己的工作进展（提交修改）。
  • 定期同步远程仓库更改 ：为了保持本地仓库与团队仓库的同步，成员可以使用 git pull origin main（假设主分支是 main）来拉取远程仓库的最新更改，合并到自己的分支（可能需要解决冲突）。这就像是团队成员定期去团队共享资料库（远程仓库）查看有没有其他成员更新的城堡设计内容（最新的改动），如果有，就把这些更新整合到自己正在建设的部分（合并到自己的分支），保证自己的工作和团队整体工作不脱节，如果整合过程中发现和其他成员的工作有冲突（比如都修改了同一块区域的设计），就一起协商解决。
  • 完成功能并提交到远程仓库 ：当成员完成自己负责的功能开发后，使用 git push origin [branch name] 命令将代码推送到远程仓库的对应分支。然后可以通过团队协作平台（如 GitHub 的 Pull Request 功能）来发起代码审查等流程，决定是否将该分支的代码合并到主分支。这就像是团队成员完成了自己负责的城堡部分建设工作（功能开发），把成果（分支代码）上传到团队共享资料库（远程仓库对应分支），然后通过团队协作流程（Pull Request 等）让其他成员和负责人审查自己的建设成果，决定是否把这部分成果整合到整个城堡的主体结构中（合并到主分支）。

希望这篇详细的 Git 与 GitHub 指南对你有所帮助，让你在代码管理的道路上更加得心应手！