别再手动备份代码了！一文带你走进Git与GitHub的世界

编程协作第一课：走进Git与GitHub的世界

1 引言：我们为什么离不开源代码管理工具？

早些年写代码，大家留存项目的方式特别简单粗暴，基本全靠新建文件夹手动备份。日常项目目录里，总能看到各式各样的版本命名：

• project-final
• project-final2
• project-final-最终版
• project-final-真的最终版

这种方法在个人开发时可能勉强还能使用，可一旦项目体量变大、开发周期拉长，再加上多人组队协作，纯手动备份的弊端就会渐渐暴露出来：

• 不小心删掉代码根本没法找回
• 多人同时修改同一文件容易发生覆盖
• 每一处改动都查不到修改记录
• 程序出问题也没法回退到之前稳定的版本
• 项目版本杂乱无章，团队协作效率也大打折扣

放到如今的软件开发场景里，一个项目动辄数万乃至上百万行代码，全程多名开发者同步推进。单凭人工整理维护代码，根本无法稳妥支撑项目运转。也正因如此，源代码管理工具SCM，慢慢成了软件开发流程里必不可少的一环。

它不只是单纯的记录代码改动轨迹、管控项目各个版本，还支撑多人协同编写、灵活拆分开发分支、审核代码质量，也能衔接自动化上线部署等实用能力，既能提升开发速度，也能稳稳保障项目稳定运行。

当下市面主流的版本管理工具，常见有Git、GitHub、GitLab、SVN等。其中GitHub依托分布式版本控制优势，再加上规模庞大的全球开源社区，已然成为现如今使用率极高的开发平台。

接下来我来带大家详细聊聊源代码管理工具，着重拆解GitHub的运行逻辑、核心用处、实操用法，同时对比它和同类工具的区别，真切体会版本管理在软件工程里的核心价值。

---

2 源代码管理概述

2.1 什么是源代码管理（SCM）

源代码管理（Source Code Management，SCM）是指对软件项目中的源代码进行统一管理的一种技术方法。其核心目标是：

• 记录代码的历史变化
• 管理不同版本
• 支持多人协同开发
• 提高项目的可维护性
• 保证代码的安全性与稳定性

简单来说，SCM就像是代码的“时间机器”。开发人员可以通过它查看：

• 某段代码是谁修改的
• 在什么时间修改
• 修改了哪些内容
• 为什么进行修改

同时，还可以随时恢复到任意的历史版本。在现代软件开发中，源代码管理已经不再是简单的“保存代码”，而是整个软件工程流程的十分重要的一部分。

---

2.2 版本控制的核心思想

版本控制（Version Control）是源代码管理的核心思想。所谓“版本”，可以理解为：某一时间点下项目代码的完整状态。

每当开发人员完成一次功能开发或Bug修复后，都可以生成一个新的版本记录。版本控制系统通常具备以下几个核心能力：

（1）版本记录

系统能够自动保存每一次代码修改历史。例如：

版本号	修改内容	修改人	时间
v1.0	完成登录功能	张三	2026-05-21
v1.1	修复密码错误问题	李四	2026-05-23
v1.2	增加注册功能	王五	2026-05-25

这样开发人员可以很清晰地了解项目的演变过程。

（2）版本回退

如果新版本出现严重Bug，可以快速恢复到旧版本。例如：

v1.3出现了系统崩溃➡️回退到v1.2版本。这一功能极大提高了软件系统的安全性。

（3）多人协作

多个开发人员可以同时开发不同功能。例如：

• A 开发登录模块
• B 开发支付模块
• C 修复系统Bug

最后再统一合并代码。

（4）分支开发

开发人员可以创建不同“分支”进行独立开发，而不会影响主项目。例如：

main 主分支
|—— Login
|—— Payment
|—— BugFix

等功能开发完成后，再合并回主分支。

---

2.3 手工管理代码存在的问题

在没有源代码管理工具之前，许多开发人员通过复制文件夹的方式保存项目。例如：

• project_v1
• project_v2
• project_v3_final

这种方式显然存在大量问题：

（1）版本混乱

开发时间一长，很难区分：

• 哪个版本最稳定
• 哪个版本是最新版本
• 哪个版本修复过Bug

容易导致开发混乱。

（2）无法查看修改记录

传统的文件备份无法记录：

• 谁修改了代码
• 修改了什么内容
• 为什么修改

出现问题后难以排查。

（3）多人开发容易覆盖代码

如果直接复制覆盖文件，很容易导致其中一人的代码丢失。例如：

• A 修改 Login.java
• B 也修改 Login.java

（4）代码恢复困难

一旦误删了文件：

• 很难恢复
• 可能导致项目损坏

严重情况下甚至不得不重新开发。

---

2.4 源代码管理的发展历程

源代码管理工具的发展经历了多个阶段。

（1）本地版本控制阶段

最早期的版本管理方式仅在本地电脑保存历史版本。特点：

• 只能单人使用
• 无法团队协作

代表工具：RCS。

（2）集中式版本控制阶段

随后出现了集中式管理工具，所有代码统一保存在服务器中，开发人员需要连接服务器进行提交和更新。

代表工具：CVS、SVN、TFS。

优点：统一管理方便。
缺点：必须依赖服务器、离线开发能力较弱。

（3）分布式版本控制阶段

现代开发主要采用分布式管理模式。每位开发者本地都拥有完整仓库。

代表工具：Git。其优势包括：

• 支持离线开发
• 分支管理灵活
• 协作效率高
• 版本操作速度快

Git也逐渐成为当前最主流的版本控制工具。

---

2.5 集中式与分布式管理模式

目前源代码管理主要分为：

• 集中式版本控制
• 分布式版本控制

二者之间存在明显的区别。

对比内容	集中式（SVN/TFS）	分布式（Git）
数据存储	服务器集中保存	每个客户端完整保存
离线能力	较弱	强
分支管理	较复杂	非常灵活
协作效率	中等	较高
数据安全性	服务器风险较高	多副本更安全
代表工具	SVN、TFS	Git

如今，随着开源社区和云端协作的发展，分布式版本控制已经成为主流趋势，而GitHub也正是在Git基础上发展起来的重要代码托管平台。

---

3 主流源代码管理工具介绍

软件工程不断发展迭代，各类代码管理工具也都应运而生。不同工具在架构模式、协作逻辑、功能特性与适用场景上都有着明显区别。目前主流的源代码管理工具主要包括Git、GitHub、GitLab、Gitee、SVN、TFS（Azure DevOps）、Bitbucket等。

不同工具适配的开发场景与团队需求各有侧重，理清彼此间的差异，才能帮团队挑选出契合自身项目的管理平台。

3.1 Git

Git是目前全球最主流的分布式版本控制工具，由Linus Torvalds于2005年开发。Git的核心特点包括：

• 分布式版本控制
• 支持离线开发
• 分支管理灵活
• 提交速度快
• 适合大型项目协作

与传统的集中式工具不同，Git的每一个客户端都拥有完整仓库，因此即使服务器出现问题，本地依然能够正常工作。

且Git以“提交快照”的方式记录项目历史，每一次Commit都会形成一个完整版本记录。

其核心结构包括：

• 工作区（Working Directory）
  ⬇️
• 暂存区（Stage）
  ⬇️
• 本地仓库（Repository）
  ⬇️
• 远程仓库（Remote Repository）

Git已经成为现代软件开发的基础工具，许多代码托管平台也都是建立在Git之上。

---

3.2 GitHub

GitHub是全球最大的代码托管平台之一，基于Git构建。GitHub除了代码托管，还提供非常丰富的功能：

• 团队协作
• Pull Request
• Issue管理
• 自动化部署
• 开源社区
• 文档管理

GitHub最大的特点之一是：开源生态极其强大。许多著名开源项目都托管在GitHub上，例如：

• Linux
• VS Code
• TensorFlow
• React

GitHub已经不只是一个“代码仓库”，更像是全球开发者交流与协作的平台。其优势包括：

• 社区活跃度高
• 开源资源丰富
• 协作流程完善
• 与DevOps集成度高

因此GitHub在个人开发者和互联网企业中应用极为广泛。

---

3.3 GitLab

GitLab是另一款基于Git的代码托管平台。

GitLab与GitHub在功能上非常相似，但它更加偏向：

• 企业内部部署
• 私有化管理
• DevOps一体化

GitLab提供了：

• CI/CD
• 自动化测试
• 权限控制
• 项目管理

等完整DevOps功能。其最大特点是：可以私有化部署在企业内部服务器。因此很多公司会选择GitLab搭建自己的内部代码管理平台。

GitLab常见应用场景包括：

• 企业内部开发
• 商业项目管理
• 私有代码仓库

---

3.4 Gitee

Gitee是国内较为流行的代码托管平台。由于网络访问速度等原因，许多国内开发者会选择使用Gitee。主要特点包括：

• 国内访问速度快
• 支持Git管理
• 提供中文界面
• 支持企业私有仓库
• 支持国产化开发环境

目前许多高校课程设计、学生项目以及国内企业项目都会使用Gitee进行代码托管。其使用方式与GitHub基本类似。

---

3.5 SVN

Apache Subversion（简称SVN）是一种经典的集中式版本控制工具。SVN曾长期是企业开发中的主流方案。

其工作模式为：客户端➡️中央服务器。

所有开发人员必须连接服务器进行代码提交与更新。

SVN的优点包括：学习成本较低、使用方式简单、权限控制较方便。

但缺点也比较明显：离线开发能力弱、分支管理复杂、服务器压力较大、合并效率较低。

随着Git的普及，SVN的市场份额已经逐渐下降，但在部分传统企业项目中仍然存在应用。

---

3.6 TFS（Azure DevOps）

Microsoft推出的Azure DevOps（早期称为TFS，Team Foundation Server）是微软生态中的开发管理平台。TFS 不仅支持版本控制，还集成了：

• 项目管理
• 测试管理
• 持续集成
• 自动化部署
• 团队协作

等功能。

其特点包括：

• 与Visual Studio深度集成
• 企业级权限控制完善
• 适合大型团队开发
• 支持敏捷开发流程

TFS早期主要采用集中式版本控制，后来也逐渐支持Git。

现在的Azure DevOps实际上已经兼容：TFVC（集中式）、Git（分布式）两种模式。它在大型企业、微软技术栈项目以及政府信息化项目中应用较多。

---

3.7 Bitbucket

Atlassian推出的Bitbucket是另一种Git代码托管平台。Bitbucket最大的特点是：与Jira、Confluence等项目管理工具集成度高。

因此很多企业会使用Jira+Bitbucket+Confluence组成完整开发协作体系。

Bitbucket的优势包括：

• 企业协作能力较强
• 权限管理完善
• 与Atlassian生态兼容性好

适用于中大型团队开发和企业项目管理。

---

3.8 各工具特点总结

不同的源代码管理工具各有千秋。下面是对主流工具进行简单对比。

工具	类型	主要特点	适用场景
Git	分布式	灵活高效	所有开发项目
GitHub	Git托管平台	开源生态强	开源项目、个人开发
GitLab	Git托管平台	私有化部署强	企业内部开发
Gitee	Git托管平台	国内访问快	国内项目
SVN	集中式	简单稳定	传统企业项目
TFS	企业开发平台	微软生态完善	大型企业项目
Bitbucket	Git托管平台	Jira集成强	企业协作开发

总体来看，Git与GitHub已逐渐成为现代软件开发中的主流方案，而传统集中式工具则更多的应用于历史项目维护或特定企业环境中。

---

4 Git与GitHub的核心原理

实际开发里，不少开发者只会用GitHub完成代码上传操作，却并不清楚Git和GitHub背后的运行逻辑。想要真正吃透源码管理工具，单纯会敲命令远远不够，弄懂底层核心原理才是关键。

Git能稳居主流版本控制工具行列，主要得益于分布式架构设计，搭配灵活的分支管理体系。而GitHub依托Git能力搭建而成，把代码协作搬到云端，打造出成熟的团队开发平台。

接下来就从Git底层机制切入，拆解Git与GitHub的核心原理。

4.1 Git的工作机制

前文提到过，Git的核心工作流程主要包括：

• 工作区（Working Directory）
  ⬇️
• 暂存区（Stage）
  ⬇️
• 本地仓库（Local Repository）
  ⬇️
• 远程仓库（Remote Repository）

整个代码管理过程实际上就是代码在不同区域之间不断流转的过程。

（1）工作区（Working Directory）

工作区是开发人员实际编写代码的位置。例如：

MyProject/
|—— index.html
|—— login.js
|—— style.css

开发人员对文件进行修改时，本质上就是在修改工作区中的内容。工作区的特点：

• 文件可直接编辑
• 修改实时生效
• 尚未进入版本管理

所以工作区中的代码并不安全，如果误删文件，可能无法恢复。

（2）暂存区（Stage）

暂存区是Git中非常重要的一个概念。开发人员需要先使用：

git add

命令将文件加入暂存区。例如：

git add login.js

其作用类似准备提交的候选区域。开发人员可以选择：

• 哪些文件提交
• 哪些文件暂时不提交

因此暂存区能够实现更加灵活的版本控制。

（3）本地仓库（Local Repository）

若开发人员执行：

git commit

代码会正式保存到本地仓库。例如：

git commit -m "完成登录功能"

此时Git会生成一个新的Commit记录。每一个Commit都包含：

• 修改内容
• 提交时间
• 提交人
• 唯一哈希值

本地仓库实际上保存了整个项目的完整历史版本。因此即使断网，也依然能够：

• 查看历史版本
• 创建分支
• 回退代码

这也是Git区别于SVN的重要特点之一。

（4）远程仓库（Remote Repository）

远程仓库通常托管在GitHub、GitLab等平台上。开发人员通过：

git push

将本地代码上传到远程仓库。其他开发人员则可以通过：

git pull

获取最新代码。

远程仓库的作用包括：

• 团队协作
• 云端备份
• 代码共享
• 项目同步

因此，Git是版本控制工具，而GitHub是代码托管平台。两者并不完全相同，这也是初学者需要区分的地方。

---

4.2 Git的版本控制原理

传统版本管理工具通常通过“记录文件差异”实现版本控制。而Git的核心思想是：保存项目快照（Snapshot）。

也就是说，每次Commit时，Git都会记录当前项目文件的整体状态。例如：

• Commit A
• Commit B
• Commit C

每个 Commit 都像一个“时间节点”。开发人员可以随时：

• 查看历史状态
• 回退版本
• 比较差异

Git的哈希机制

Git使用SHA-1哈希算法生成唯一标识。例如：a3f5c7d9e8...

每次Commit都会生成不同哈希值。这样保证：

• 版本唯一
• 数据完整
• 历史不可随意篡改

Git的高效存储机制

Git并不会重复保存完全相同的文件。

如果某个文件没有发生变化：

Git会直接复用旧版本数据

因此Git虽然保存大量历史版本，但磁盘占用并不会无限增长。

---

4.3 Commit提交机制

Commit（提交）是Git中最核心的操作之一。

一次Commit可以理解为：对当前项目状态的一次“拍照”。例如：

git commit -m "修复登录Bug"

提交后，Git会记录：

信息	内容
提交人	用户名称
提交时间	当前时间
修改文件	本次变更内容
Commit ID	唯一哈希值
提交说明	Commit Message

因此良好的Commit习惯非常重要。

Commit Message规范

实际开发中通常要求：

• feat: 新增登录功能
• fix: 修复支付Bug
• docs: 更新文档
• style: 调整代码格式

规范化提交有助于：

• 查看历史记录
• 自动生成更新日志
• 团队协作维护

---

4.4 Branch分支机制

分支（Branch）是Git最强大的功能之一。Git允许开发人员创建多个独立开发线路。例如：

main
|—— Login
|—— Payment
|—— BugFix

每个分支互不影响，开发人员可以独立开发新功能、修复Bug、测试新方案。完成后再合并到主分支。

主分支（Main/Master）

主分支通常保存稳定可运行版本。因此不允许随意修改，且需要经过测试后才能合并

功能分支（Feature Branch）

功能开发通常使用独立分支。例如：

git checkout -b Login

这样可以避免直接影响主项目。

分支优势

Git 分支机制具有创建速度快、切换灵活、合并效率高等优点。这也是Git能够广泛应用于大型团队开发的重要原因。

---

4.5 Merge合并机制

当功能开发完成后，需要将分支代码合并回主分支。Git使用：

git merge

命令完成代码合并。例如：

git merge Login

自动合并

如果两个开发人员修改内容不同，Git通常能够自动完成合并。

合并冲突

如果多人同时修改同一代码区域，则会产生Merge Conflict（合并冲突）。例如：

<<<<<<< HEAD
当前分支代码
=======
其他分支代码
>>>>>>> feature

开发人员需要手动决定保留哪些代码、删除哪些代码。因此团队协作中，分支规范、提交规范、沟通机制都非常重要。

---

4.6 GitHub的云端协作思想

GitHub并不仅仅是代码存储平台。其真正价值在于：将Git的版本控制能力与互联网协作能力结合起来。

GitHub提供了完整团队开发生态。包括：

• Pull Request
• Code Review
• Issue 管理
• 自动化部署
• 权限管理
• 开源社区协作

Pull Request（PR）

PR是GitHub中最核心的协作机制之一。其流程通常为：

• 创建分支
  ⬇️
• 提交代码
  ⬇️
• 发起 Pull Request
  ⬇️
• 代码审查
  ⬇️
• 合并主分支

这种机制能够：

• 防止错误代码直接进入主分支
• 提高代码质量
• 加强团队沟通

Fork开源协作模式

GitHub支持Fork机制，开发人员可以复制开源项目、自由修改、提交贡献，这也是全球开源社区能够高效运转的重要原因。

GitHub的平台化特点

如今GitHub已不仅仅是“代码仓库”。它更像：

• 开发者社区
• 项目协作平台
• DevOps平台
• 开源生态中心

现代软件开发中的大量优秀项目，都是基于GitHub完成协作与维护的。

---

5 GitHub在现代软件开发中的应用

随着软件工程的发展，现代开发已经不再是“单人编写代码”的简单过程，而是逐渐演变为：

• 多人协作开发
• 云端项目管理
• 自动化部署
• 持续集成
• 开源社区协同

等一整套工程化开发模式。GitHub正是在这样的背景下，逐渐从一个简单的代码托管平台发展成为现代软件开发的重要基础设施。如今，无论是个人开发者、开源社区，还是大型互联网企业，都在广泛使用GitHub进行项目协作与代码管理。

5.1 GitHub在个人开发中的应用

对于个人开发者而言，GitHub不仅仅是一个“存放代码的网站”，更是学习、成长以及展示个人能力的重要平台。

云端备份代码

在传统开发过程中，代码通常只保存在本地电脑中。如果出现电脑损坏、系统重装、文件误删等，都可能导致项目丢失。而GitHub提供了远程仓库功能，开发人员可以将本地项目上传到云端。例如：

git push origin main

即可将项目同步到GitHub。这样即使本地设备出现问题，也能够随时重新恢复项目。因此GitHub实际上也承担了“代码云盘”的作用。

管理个人项目

许多开发人员会在GitHub上管理自己的学习项目。例如：

• 前端练习项目
• Java Web项目
• 算法练习
• Android应用
• 数据分析项目

通过GitHub，开发人员能够清晰记录项目开发过程。包括：

• 功能更新
• Bug修复
• 历史版本
• 开发日志

这比单纯保存文件夹更加规范。

展示个人技术能力

目前许多企业在招聘程序员时，都会关注求职者的GitHub页面。因为GitHub能够直观体现一名程序员的编码能力、项目经验、技术栈和开发活跃度等信息。

一个拥有多个完整项目的GitHub主页，往往比单纯的简历更具有说服力。因此很多开发者会将GitHub当作个人技术作品集平台。

学习优秀开源项目

GitHub最大的优势之一就是拥有全球最大的开源社区。开发人员可以学习大量优秀项目源码，例如：Vue.js、React、Spring Boot、TensorFlow。

通过阅读这些项目源码，开发人员能够学习项目架构、编码规范以及工程化开发方式这对于技术成长具有重要意义。

---

5.2 GitHub在团队协作中的应用

在现代软件开发中，一个完整项目往往由多个开发人员共同完成。前端开发、后端开发、数据库设计、测试人员、运维人员等人员都会参与项目开发。

因此，高效协作也成为软件工程中的关键问题。GitHub提供的协作机制能够有效解决多人开发中的代码管理问题。

多人协同开发

团队成员可以分别开发不同模块。

例如：

成员	开发任务
A	登录模块
B	支付模块
C	用户管理
D	Bug修复

不同开发人员通过独立分支进行开发，最终统一合并到主分支。这种方式能够：

• 避免代码覆盖
• 降低开发冲突
• 提高协作效率
• Code Review（代码审查）

在团队开发中，代码质量非常重要。GitHub提供的Pull Request与Code Review机制能帮助团队：

• 审查代码质量
• 发现潜在Bug
• 统一编码规范

例如开发人员提交代码后，其他成员可以进行审核：

• “这里变量命名不规范”
• “建议增加异常处理”
• “这里循环效率较低”

这种方式不仅提高了代码质量，也有助于团队成员之间的技术交流。

开发规范管理

大型项目通常需要统一开发规范。例如：

• Commit Message规范
• 分支命名规范
• 代码格式规范
• 文件结构规范

GitHub能够帮助团队建立更加标准化的开发流程。这也是现代软件工程的重要组成部分。

敏捷开发与协作流程

当下许多团队采用Scrum、Agile（敏捷开发）等开发模式。GitHub可以与项目管理流程结合，实现完整的开发闭环：

• 需求分析
  ⬇️
• 任务分配
  ⬇️
• 功能开发
  ⬇️
• 代码审查
  ⬇️
• 测试部署

---

5.3 Issue与项目管理

除了代码管理外，GitHub 还提供了较为完善的项目管理功能。其中最常用的功能之一就是：Issue（问题跟踪）。

Bug跟踪

开发过程中不可避免会出现各种问题：

• 页面无法跳转
• 数据查询异常
• 系统崩溃
• 接口返回错误

团队成员可以通过Issue记录问题。例如：

Issue标题	类型
登录失败问题	Bug
增加头像上传功能	新需求
优化数据库查询效率	性能优化

这能让项目的问题更加清晰、可追踪。

任务分配

Issue 不仅能够记录问题，还能够分配负责人。例如：

Issue #15
负责人：张三
截止时间：2026-06-01

这能让团队成员明确各自的任务。

标签分类（Labels）

GitHub支持为不同Issue添加标签。例如：

bug
enhancement
help wanted
documentation

通过标签可以快速区分：

• Bug
• 新功能
• 文档问题
• 优化需求

提高项目管理效率。

项目进度管理

GitHub还支持：

• Milestone（里程碑）
• Project（项目看板）

等功能。例如：

版本	开发目标
v1.0	完成用户系统
v2.0	完成支付模块
v3.0	上线移动端

这些功能能让团队更加清晰地管理项目开发进度。

---

5.4 GitHub Actions自动化

随着软件开发规模不断扩大，传统手工部署方式逐渐暴露出效率低、容易出错等问题。因此，自动化开发（DevOps）逐渐成为现代软件工程的重要方向。

GitHub提供的GitHub Actions功能，可以帮助开发团队实现自动化工作流。

CI/CD思想

CI/CD是现代自动化开发的重要理念。其中：

缩写	含义
CI	Continuous Integration（持续集成）
CD	Continuous Delivery/Deployment（持续交付/部署）

其核心流程通常为：代码提交➡️自动测试➡️自动构建➡️自动部署。

这样能够减少大量重复性人工操作。

自动化测试

开发人员提交代码后，GitHub Actions可以自动：

• 编译项目
• 运行测试代码
• 检查代码格式

如果测试失败，系统会自动提示错误，这样能够有效避免问题代码进入主分支。

自动化部署

对于Web项目而言，GitHub Actions还能实现：

• 自动上传服务器
• 自动部署网站
• 自动发布项目

例如，开发人员只需要Push代码：

git push

系统就能自动完成部署流程。

DevOps的发展趋势

GitHub Actions的出现说明：现代软件开发已经从“单纯写代码”逐渐发展为“开发+自动化+运维”一体化的工程体系。

因此，自动化能力已经成为现代开发平台的重要组成部分。

---

6 GitHub实际操作流程演示

前面我们已经把源代码管理的核心概念、Git与GitHub的底层原理，还有它在现代开发里的实际应用都梳理了一遍。

但对我们开发者来说，光懂理论、背概念远远不够，能流畅上手实操才是真本事。所以这一章，我会用一个最简单的小项目，带大家完整走一遍GitHub标准工作流，一步一步演示最常用、最核心的操作，包括：

• 创建远程仓库
• 本地Git初始化
• 提交代码到本地仓库
• 推送到GitHub云端
• 新建分支独立开发
• 提交Pull Request合并代码
• 查看历史版本、回溯记录

跟着实操一遍，你就能直观地感受到GitHub完整的协作流程，把前面的理论知识彻底串起来。

6.1 创建GitHub仓库

在使用GitHub之前，首先需要创建远程仓库。开发人员登录GitHub后，可以点击：New Repository。

创建新的项目仓库。

创建时通常需要填写以下内容：

配置项	说明
Repository Name	仓库名称
Description	项目描述
Public/Private	公开或私有
README	是否初始化说明文件
.gitignore	忽略文件配置
License	开源协议

例如：

创建完成后，GitHub会自动生成远程仓库地址，点击绿色的Code按钮，就能看到那串HTTPS地址。
例如：

该地址后续用于本地仓库与远程仓库之间的连接。

---

6.2 Git本地初始化

现在回到你的电脑本地，开辟一块工作区。

1 在你电脑的合适位置新建一个文件夹，命名为StudentManagementSystem。

2 打开终端，并进入这个文件夹。

3 在终端输入以下命令并回车，初始化本地仓库：（如果你用的是Git Bash，可以直接在文件夹里右键选择"Open Git Bash here"）

git init

4 为了让仓库有点内容，我们随便创建一个文件。你可以手动新建一个 index.html 文件，或者在终端输入：

echo "<h1>Hello Git</h1>" > index.html

5 查看当前状态，你会看到红色的未追踪文件：

git status

---

6.3 提交代码到本地仓库

文件现在还在“工作区”，我们需要把它放到“暂存区”，然后再存入“本地仓库”。

1 添加到暂存区（注意add后面有个点！代表添加所有更改）：

git add .

2 提交到本地仓库（一定要写清楚提交信息）：

git commit -m "feat: 完成项目初始化，新增 index.html"

---

6.4 推送到GitHub

现在，我们要把本地的仓库和第一步在GitHub上创建的远程仓库连起来。

1 关联远程仓库（把刚才复制的URL替换到下面命令中）：

git remote add origin https://github.com/你的用户名/StudentManagementSystem.git

2 强制本地分支名为main（因为GitHub现在默认主分支叫 main，而有些老版本的Git本地默认叫master，这一步是为了防错）：

git branch -M main

3 推送到GitHub：

git push -u origin main

这一步正常会报错，因为创建项目的时候勾选了“Add a README file”，意味着GitHub已经在云端帮你创建了一个文件，并且产生了一次“初始提交”。

而我们的第二步：在本地新建了一个空文件夹，使用了git init。这是一个完全从零开始的全新仓库。当你试图把本地的代码推上去时，Git发现了云端有README文件而你本地没有，发生冲突，出于代码安全考虑，Git拦截了你的操作。

所以我们在终端继续执行：强制合并两个不相关的历史记录。（注：--allow-unrelated-histories仅用于本次演示场景，允许合并两条无关联的提交历史，正式项目不建议使用。标准做法是先克隆远程仓库再进行开发。）

git pull origin main --allow-unrelated-histories

执行这句命令后，终端可能会变样，进入一个叫做Vim的文本编辑器，让你输入合并信息（通常屏幕最上方写着Merge branch 'main' of...）。别慌，退出方法如下：
英文半角状态依次输入这三个字符：“:wq”（这代表write&quit，保存并退出），然后按下回车。

只要刚才的拉取合并成功，你的本地文件夹内现在就同时拥有了index.html和从云端拉下来的README.md。现在可以继续推送了：

git push -u origin main

成功后，你去刷新GitHub网页，就能看到你的index.html。

---

6.5 创建分支

1 创建并切换到新分支：

git checkout -b Login

2 确认你在新分支上（带*号的就是当前分支）：

git branch

3 在新分支上开发新功能：打开index.html，加上一行

<p>登录表单</p>

或者用命令：

echo "<p>登录表单</p>" >> index.html

4 提交你的新功能：

git add .
git commit -m "feat: 新增登录表单功能"

---

6.6 Pull Request合并流程

新功能写好了，我们要向团队申请把代码合并进主分支。

1 把你的分支推送到云端：

git push origin Login

2 发起PR：回到GitHub网页端，你会神奇地发现页面上出现了一个黄绿色的提示框Compare & pull request，点击它。

3 填写一下这个PR的标题和描述，告诉大家你做了什么，然后点击绿色的Create pull request。

4 合并PR：假装你现在是团队里的审核员，检查了一下代码没问题，点击绿色的Merge pull request，再点击Confirm merge。

5 完成，你的Login里的代码现在已经成功融入main主分支了。

---

6.7 查看历史版本记录

最后，我们来看看历史记录。

1 切回本地的主分支并拉取最新的代码（因为合并是在云端完成的）：

git checkout main
git pull origin main

2 查看简洁版历史记录：

git log --oneline

你会看到一列带有简短哈希值（如a1b2c3）的提交记录，这就是刚才一步步的记录。我相信通过完整的跑通这一遍，你会对这篇博客里的理论有更深刻的记忆和理解。

---

7 GitHub与SVN/TFS对比分析

随着软件工程的发展，源代码管理工具也经历了从集中式到分布式的发展过程。目前常见的版本控制工具主要包括：

• Git/GitHub
• SVN
• TFS（Azure DevOps）

它们在架构设计、团队协作以及开发方式等方面存在较大差异。接下来我将对几种主流工具进行简单对比分析。

7.1 分布式与集中式架构对比

Git采用：分布式版本控制（Distributed Version Control）。

而SVN与早期TFS主要采用：集中式版本控制（Centralized Version Control）。

两者最核心的区别在于：

类型	数据存储方式
Git	每个开发者本地都拥有完整仓库
SVN/TFS	所有数据集中保存在服务器

因此，Git即使在离线状态下，也依然能够：

• 查看历史版本
• 创建分支
• 提交Commit

而SVN/TFS更依赖服务器连接。

---

7.2 分支管理能力对比

Git最大的优势之一就是：分支管理非常灵活。开发人员可以快速创建多个功能分支：
main
|—— Login
|—— Payment
|—— BugFix

不同功能之间互不影响。而SVN的分支管理相对复杂，创建与合并成本较高，因此很多团队不愿频繁使用分支。相比之下，Git更适合现代敏捷开发模式。

---

7.3 团队协作能力对比

GitHub提供了：

• Pull Request
• Code Review
• Issue管理
• Actions自动化

等完整协作体系。开发团队能够通过GitHub建立：开发➡️审核➡️测试➡️部署的一体化流程。

而传统SVN更偏向“代码存储工具”，协作能力相对有限。TFS虽然也支持项目管理，但整体生态更加偏向微软技术体系。

7.4 不同工具的适用场景

不同工具适用于不同开发环境。

工具	适用场景
Git/GitHub	开源项目、互联网开发、个人学习
SVN	传统企业项目、历史系统维护
TFS/Azure DevOps	微软生态、大型企业开发

目前来看，Git与GitHub已逐渐成为现代软件开发中的主流方案。尤其在开源社区以及互联网开发领域，GitHub已经拥有非常广泛的应用。

8 总结与体会

如今软件项目越做越大，团队一起开发也成了常态，源代码管理工具自然就成了我们编程路上离不开的好帮手。

这篇文章的内容从源码管理的基础概念讲起，陆续介绍了Git、GitHub、SVN、TFS等多款主流工具，其中重点剖析了Git和GitHub的底层原理、实际用法，还有对应的团队协作模式。

慢慢整理下来我才发现，GitHub早就不只是一个单纯存放代码的仓库了。它更像一个全能的开发平台，把版本控制、团队协作、项目管理、自动化开发，还有热闹的开源社区全都整合在了一起，其实里面有许多的资源都是对我们学习非常有价值有帮助的。

和传统的版本管理工具相比，Git搭配GitHub在多方面的表现都十分亮眼，这也难怪现在几乎成了软件开发领域的主流选择。在实际使用中，它既能好好守护我们的代码，避免误操作带来的麻烦，也能让团队的开发流程变得井然有序，整体效率和代码质量都能上一个台阶。像Pull Request、Issue、GitHub Actions这些实用功能，也让我直观地看到，现代软件工程正朝着高效协作、自动运维的方向不断迈进。

这篇完整的博客文章梳理和动手演示实操，对我来说收获也特别大。这让我有了新的感悟：编程从来不是一个人的单打独斗，写代码只是其中一环，完整的工程化协作才是软件开发的核心。今后我也会继续学习Git、DevOps以及自动化部署这类技术，一点点的积累实战经验。路漫漫其修远兮，希望自己能不断进步，努力成为一名更专业的开发者。

这篇文章的篇幅可能有些长，能阅读到最后也是辛苦各位了，我相信里面有些内容可能对刚准备了解或者正在接触的你也会有一点帮助，那么这就足够啦~

如果你也有什么见解或者看法，欢迎在评论区留言🤗我们可以一起讨论。最后，还是祝各位生活愉快，万事胜意~😄