The Odin Project 课程:Git 基础工作流实战指南——从创建仓库、克隆到提交推送
2026/9/15 21:43:05 网站建设 项目流程

The Odin Project 课程:Git 基础工作流实战指南——从创建仓库、克隆到提交推送

【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum

本指南以 The Odin Project 开放课程仓库中 Git 基础(git_basics) 一课为骨架,系统讲解日常开发中占用率高达 70%~80% 的Git 基础工作流:在 GitHub 上创建仓库、将仓库克隆到本地、用git status/git add/git commit/git log管理快照,以及用git push把本地提交推送到远程。读完本篇,你将能独立完成"本地编写代码 → 分阶段暂存 → 提交快照 → 推送 GitHub"的完整闭环,并掌握原子提交、提交信息规范等能直接提升协作质量的最佳实践。

一、为什么这套工作流值得先掌握

在进入命令之前,先建立两个核心概念:Git 是什么GitHub 又是什么。这两个概念在配套课程 Git 与版本控制入门 中有详细论述,这里只提取与工作流直接相关的要点:

  • Git 是运行在本地机器上的版本控制系统(version control system)。文本编辑器的"保存"只记录单个文件的全部内容,而 Git 的"保存"记录的是文件与目录的差异(differences),并保留每一次保存的历史记录。这意味着你可以随时回看项目如何一步步成长、恢复过去某个时间点的文件状态。
  • GitHub 是存放代码项目的远程(remote)存储设施。本地用 Git 管理,联网后用git push把项目推送到 GitHub,实现展示作品集与团队协作。

理解了"本地 Git 管历史、远程 GitHub 管存放"的分工之后,下面这套基础工作流就是连接两者的日常操作。

二、动手前准备:检查版本与默认分支

开始前有两项一次性配置,直接关系到后面每一步操作是否符合预期:

  1. 确认 Git 版本不低于 2.28。GitHub 已更改默认分支的命名方式,较新的 Git 才能正确支持以main作为默认分支。检查命令:

    git --version
  2. 把本地 Git 的默认初始分支设置为main。执行后没有任何输出即表示成功:

    git config --global init.defaultBranch main

关于从mastermain的迁移背景,可参见本仓库课程 使用 Git 的现实世界技巧 中关于默认分支的说明。需要强调:这里设置的是"新初始化仓库"的默认分支名,并不会改动已有仓库的分支。

三、在 GitHub 上创建远程仓库

  1. 前提:已完成 GitHub 账号注册与 Git 安装配置,对应课程见仓库中的 设置 Git。
  2. 从 GitHub 首页右上角点击"+"按钮,选择"New repository"。如果视口较窄导致按钮被隐藏,可点击右上角头像,该按钮会出现在用户名旁边。
  3. 在仓库名称(repository name)输入框中填写git_test勾选 "Add README"选项——它会自动在新仓库中生成一个README.md文件;最后点击页面底部的"Create repository"按钮。
  4. 创建完成后会跳转到新仓库页面。点击绿色的"Code"按钮(位于当前分支显示按钮的右侧,通常显示main),在"Clone"区域选择SSH选项并复制下方的地址。
    • 注意:必须点击 SSH 选项。如果复制出来的地址形如https://github.com/USER-NAME/REPOSITORY-NAME.git,说明你选中的是 HTTPS,而不是这里要求的 SSH。
# SSH 形式(正确) git clone git@github.com:USER-NAME/REPOSITORY-NAME.git # HTTPS 形式(本课程不采用) https://github.com/USER-NAME/REPOSITORY-NAME.git

四、把远程仓库克隆到本地

在本地命令行中,先为所有 Odin 项目创建一个统一存放目录repos(位于主目录~下),再进入该目录:

mkdir repos cd repos/

提示:不同操作系统下~可能代表/Users/你的用户名/home/你的用户名,不确定时先执行cd ~回到主目录(参考仓库中的 命令行基础)。

接着用git clone加上上一步复制的 SSH 地址,把 GitHub 上的git_test仓库完整下载到本地:

git clone git@github.com:USER-NAME/REPOSITORY-NAME.git

克隆完成后验证本地与远程是否成功建立连接。进入下载下来的git_test目录,执行:

cd git_test git remote -v

预期输出如下(USER-NAME是你的 GitHub 用户名):

origin git@github.com:USER-NAME/git_test.git (fetch) origin git@github.com:USER-NAME/git_test.git (push)

这段输出展示了两条信息:

  • 第一行与第二行分别记录了**拉取(fetch)推送(push)**所使用的远程仓库 URL,即你在 GitHub 上创建的仓库地址;
  • 行首的origin是这条远程连接的名称,它既是默认值也是业界惯例。它完全可以被命名为 "party-parrot" 或 "dancing-banana"——只是origin成了约定俗成的默认叫法。origin这个概念在后续推送(git push origin main)中还会再次出现,其深层原理可参考 深入理解 Git 与 远程仓库协作 两课。

五、基础工作流:快照的三步走

Git 保存文件采用两阶段(two-stage)系统:先把变更加入暂存区(staging area),再一次性提交(commit)成快照。暂存区可以理解为"等待室"——所有想进入本次提交的变更先在这里集合。

5.1 创建一个新文件并观察状态

git_test目录下创建一个新文件:

touch hello_world.txt

执行git status查看仓库状态。输出中hello_world.txt会以红色文本显示,并出现在名为"Untracked files"的段落中——意思是该文件尚未被 Git 跟踪,也还没有进入暂存区。

5.2 加入暂存区:git add

git add hello_world.txt

再次执行git status,此时文件变为绿色,出现在名为"Changes to be committed"的段落中,表示它已经进入暂存区。

5.3 提交快照:git commit

git commit -m "Add hello_world.txt"

提交后再次运行git status,输出应显示:

nothing to commit, working tree clean

意为"没有待提交的内容,工作树是干净的",你的变更已经成为一条提交记录。

两个常见的提示信息需要正确理解:

  • 如果看到"upstream is gone",不必担心:这只说明克隆下来的仓库当前还没有分支建立上游关联,在完成后续步骤后会自动消失;
  • 如果看到"Your branch is ahead of 'origin/main' by 1 commit",意思是你的本地快照比远程仓库新了 1 条提交——这正是后面要git push上传的内容。

5.4 查看提交历史:git log

git log

输出中会看到刚才那条"Add hello_world.txt"提交,包含提交者(author)与提交的日期时间。如果终端卡在底部显示(END)的界面,按q键退出即可。

六、修改文件:让工作流转起来

真实开发中文件几乎总是不断变化,下面用修改README.md演示"修改 → 暂存 → 提交"的完整循环。

  1. 用编辑器打开仓库。如果使用 Visual Studio Code,可直接在仓库目录下执行code .(若提示command not found: code,请先按 命令行基础 中"从命令行打开 VS Code"一节的指引配置)。

  2. README.md末尾新增一行文本Hello Odin!,保存文件(VS Code 未开启自动保存时按Ctrl+S,Mac 为Cmd+S)。

  3. 回到终端(VS Code 内置终端可用Ctrl+</kbd> 调出),执行git status。注意输出与之前创建hello_world.txt时的区别:这次README.md` 出现在名为"Changes not staged for commit"的段落中。该段与 "Untracked files" 含义类似——文件有改动,但尚未加入暂存区。

  4. README.md加入暂存区:

    git add README.md
  5. 再次运行git statusREADME.md以绿色显示在 "Changes to be committed" 中。而hello_world.txt不会出现,因为它自提交以来没有被修改过。

  6. 修改hello_world.txt,保存后暂存。此时可以体验一个常用快捷方式——用git add .当前目录及其所有子目录中的变更一次性加入暂存区:

    git add .

    再执行git status,此时所有变更都应处于暂存区中。

  7. 提交暂存区中的所有文件,并附上描述性信息:

    git commit -m "Edit README.md and hello_world.txt"

    git status再次显示 "nothing to commit"。

  8. 最后用git log查看提交历史,现在应该能看到三条提交记录。

七、推送工作到 GitHub

至此本地历史已经领先于远程仓库,把它们上传到开头创建的 GitHub 仓库:

git push origin main

由于当前只使用main一个分支、也只使用origin一个远程,也可以简写为git push以节省按键。

关键排错提示:如果推送时收到"Support for password authentication was removed on August 13, 2021. Please use a personal access token instead."的报错,说明你在克隆时误用了 HTTPS 而不是 SSH。解决办法是参考远程仓库切换指引,把远程 URL 从 HTTPS 改为 SSH,再重新推送。

推送完成后,执行最后一次git status,预期输出:

Your branch is up to date with 'origin/main'. nothing to commit, working tree clean

刷新 GitHub 仓库页面,即可看到刚刚从本地推送上来的README.mdhello_world.txt

避免直接在 GitHub 上编辑

刚上手时,看到 README 里有错别字,很容易顺手在 GitHub 网页上直接修改。这一阶段请务必避免:直接编辑 GitHub 会制造本地与远程历史的分叉,解决它需要更高级的 Git 知识(本课程后续会覆盖)。现阶段坚持"本地改 → 提交 → 推送"的单一流向,是最稳妥的做法。

八、命令速查表与语法记忆法

以下命令值得收藏并逐步背熟:

  • 远程仓库相关
    • git clone git@github.com:USER-NAME/REPOSITORY-NAME.git—— 克隆远程仓库到本地
    • git pushgit push origin main—— 推送本地提交到远程(当前场景下二者等价)
  • 工作流相关
    • git add .—— 把当前目录及子目录的所有变更加入暂存区
    • git commit -m "A message describing what you have done to make this snapshot different"—— 把暂存区内容提交成一条快照
  • 状态与历史相关
    • git status—— 查看工作树与暂存区状态
    • git log—— 查看提交历史

记忆诀窍是掌握 Git 的基础语法程序 | 动作 | 目的地(program | action | destination)

命令解析
git add .git|add|.,其中.代表当前目录下的所有内容
git commit -m "message"git|commit -m|"message"
git statusgit|status| (无目的地)

九、Git 最佳实践:原子提交(Atomic Commits)

工作流跑通之后,要刻意培养两个习惯:原子提交,以及利用原子提交写出对协作者更有价值的提交信息。本仓库专门设有 提交信息规范 一课,这里先给出核心要点:

原子提交是指一次提交只包含与程序某一个功能或任务相关的变更。这样做的两个主要原因:

  1. 便于回退:如果某处改动引入了问题,可以只回退那一个具体变更,而不会牵连其他无关改动;
  2. 利于撰写提交信息:变更范围聚焦了,提交信息自然清晰可写。

Git 不只对团队协作有用,独立开发时同样重要——未来回看旧代码时,你会越来越依赖自己的提交历史。随着项目复杂度上升,掌握历史重写(git commit --amendgit rebasegit reset)、分支即指针等进阶知识将成为必需品,这些内容对应本仓库 深入理解 Git 一课;而涉及远程历史改写(如git push --force的危险性与git push --force-with-lease的安全替代)可查阅 远程仓库协作。

十、更换 Git 提交信息编辑器

默认情况下,不带-m参数执行git commit会打开 Vim 编辑器,对初学者不太友好。把默认编辑器换成 VS Code 是个一劳永逸的选择:

git config --global core.editor "code --wait"

执行后终端不会有任何确认输出,这是正常的。配置完成后,你有两种提交方式:

  • git commit -m "your message here":一条命令直接写完提交信息;
  • git commit:自动打开一个新的 VS Code 标签页,可以在多行中撰写更详细的提交信息(主题行 + 正文,用空行分隔——这是 提交信息规范 中强烈推荐的最佳实践),保存并关闭标签页后,终端会显示你的提交信息与变更摘要。

值得注意的是,本仓库 提交信息规范 一课还补充了两条实用约束:提交信息的主题行建议不超过 72 个字符;使用主动语态(如 "Fix card generator"),避免 "saved"、"updated" 这类含糊表述。此外,把 Git 提交信息编辑器设置为 VS Code 后,还能借助拼写检查插件与每行字符数显示,更容易写出规范的多行提交信息。

十一、知识自检

以下问题覆盖了本课全部核心知识点,可逐条自查:

  1. 如何在 GitHub 上创建一个新仓库?
  2. 如何把 GitHub 上的仓库复制(克隆)到本地?
  3. 远程连接的默认名称是什么?
  4. 解释git push origin mainorigin的含义。
  5. 解释git push origin mainmain的含义。
  6. 解释 Git 保存文件的两阶段系统。
  7. 如何查看当前仓库的状态?
  8. 如何把文件加入暂存区?
  9. 如何提交暂存区中的文件并附上描述性信息?
  10. 如何把本地变更推送到 GitHub 仓库?
  11. 如何查看之前所有提交的历史记录?

继续深入

本篇对应课程位于仓库 git/foundations_git/git_basics.md,完整的 Git 学习路径如下:

  • 前置概念:Git 与版本控制入门
  • 提交信息规范:提交信息(commit_messages)
  • 进阶原理:深入理解 Git:历史重写与指针
  • 远程协作:远程仓库与强制推送的边界
  • 实战应用:在真实世界中使用 Git

值得一提的是,本仓库本身就是用 Git 工作流维护的开放课程:课程文件经过 markdownlint 的自动化校验(见仓库根目录 package.json 中的lint/fix/test脚本),每一次课程修订都以规范的提交记录在案。你在学习本工作流时产出的每一次git commit,都在练习未来雇主会在你的 GitHub 上查看的那种"可读的提交历史"。

【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询