CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
后端入门实战/课时/Git 与托管
RawBlame
课时目录12 节

后端入门实战

  1. 01后端入门概览
  2. 02Git 与托管
  3. 03语言选型
  4. 04PostgreSQL
  5. 05数据库进阶
  6. 06Redis 与缓存
  7. 07REST API
  8. 08认证
  9. 09ORM
  10. 10单元测试
  11. 11集成与功能测试
  12. 12综合练习

Git 与托管

Git、GitHub 与托管服务。

30 分钟

Git 与托管

这一课你将能做到

  1. 独立完成「建分支 → 提交 → 推送 → Pull Request → 合并」的完整团队工作流
  2. 遇到合并冲突时,不慌张地手动解决并完成合并
  3. 写出符合 Conventional Commits 规范的提交信息,并说出代码评审(Code Review)都看什么

为什么要学

后端代码是团队资产:同一份服务多人同时改,改坏了要能回到昨天能跑的版本,出了线上事故要能定位是哪次提交引入的。没有 Git 的团队等于在悬崖边上不系安全绳。

人话:Git 是代码的「时间机器 + 并行宇宙」。时间机器让你随时回到任何一个历史版本;并行宇宙(分支)让你在不影响主线的情况下大胆尝试。GitHub/GitLab 则是把你的仓库放到云端,团队协作的枢纽。

面试与实战都绕不开:入职第一件事就是配 Git 权限,第一个任务就是在 feature 分支上改一个小需求然后提 PR。

先建立图像

Git 本地有三个「区域」,理解它们,90% 的 Git 疑惑就消失了:

工作区                暂存区               本地仓库              远程仓库
(你正在编辑的文件)    (git add 后)         (git commit 后)       (git push 后)
┌──────────┐  add   ┌──────────┐ commit  ┌──────────┐  push   ┌──────────┐
│ notes.js │ ─────▶ │ 待打包的  │ ──────▶ │ v1,v2,v3 │ ──────▶ │ GitHub   │
│ 已修改    │        │ 变更快照  │         │ 历史版本  │         │ GitLab   │
└──────────┘        └──────────┘         └──────────┘         └──────────┘
  • git add:挑选本次要提交的变更(可以只挑一部分文件)
  • git commit:打包成一个带说明的版本快照
  • git push:同步到远端,让团队看见

跟着做

步骤 1:安装与最小配置

从 git-scm.com 安装(Windows 装 Git Bash),然后配置身份——每个提交都会署名:

git config --global user.name "你的名字"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main   # 新仓库默认分支叫 main

步骤 2:创建仓库,理解三区

mkdir git-demo && cd git-demo
git init                    # 初始化仓库,出现隐藏的 .git 目录
echo "console.log('v1')" > app.js
git status                  # 红色:app.js 未跟踪
git add app.js              # 进入暂存区
git status                  # 绿色:已暂存
git commit -m "feat: 初始化应用脚本"   # 打包成第一个版本
git log --oneline           # 查看提交历史,每行一个版本

git status 是你最好的朋友——任何时候不知道自己处于什么状态,先敲它。

步骤 3:分支操作

git branch                          # 查看分支,* 表示当前所在
git switch -c feature/add-greeting  # 创建并切换到新分支(-c 即 create)
echo "console.log('hello from feature')" >> app.js
git add app.js
git commit -m "feat: 增加问候语输出"
git switch main                     # 切回 main,文件里没有那行——各分支互不干扰
git merge feature/add-greeting      # 合并进 main(默认快进合并)
git branch -d feature/add-greeting  # 合并完删掉分支

步骤 4:制造并解决一次冲突

冲突只发生在「两个分支改了同一文件的同一处」时,练一次就不怕了:

git switch -c feature/change-message
# 把 app.js 第一行改成 console.log('from feature'),然后:
git commit -am "feat: 修改启动信息为 feature 版"   # -a 直接暂存已跟踪文件的修改

git switch main
# 把同一行改成 console.log('from main'),然后:
git commit -am "feat: 修改启动信息为 main 版"

git merge feature/change-message
# CONFLICT (content): Merge conflict in app.js

打开 app.js,你会看到:

<<<<<<< HEAD
console.log('from main')
=======
console.log('from feature')
>>>>>>> feature/change-message

手动编辑成你想要的最终内容(比如保留一行 console.log('from main')),删掉所有 <<<<<<<、=======、>>>>>>> 标记,然后:

git add app.js
git commit -m "merge: 解决启动信息冲突,保留 main 版本"

步骤 5:推送到 GitHub,走一次 PR 流程

  1. 在 GitHub 上新建空仓库 git-demo(不要勾选 README)
  2. 关联并推送:
git remote add origin https://github.com/你的用户名/git-demo.git
git push -u origin main      # -u 记住关联,以后直接 git push
  1. 单独推送功能分支并开 PR:
git switch -c feature/readme
echo "# Git Demo" > README.md
git add README.md
git commit -m "docs: 添加 README"
git push -u origin feature/readme
  1. 打开 GitHub 仓库页面,点黄色提示条上的 Compare & pull request,写清标题与描述,点 Create pull request
  2. (模拟他人)在 Files changed 页面留一条评论 → 回到自己的终端补一个修改并 push(PR 会自动更新)→ 点 Merge pull request

企业里 PR 就是这么走的,只是评审人是同事而不是你自己。

步骤 6:撤销操作——先学安全的 revert

git log --oneline                  # 找到想撤销的提交哈希,如 a1b2c3d
git revert a1b2c3d                 # 生成一个「反向提交」,历史不被改写,安全

git revert 是撤销已推送提交的正确方式;git reset --hard 只适合撤销本地未推送的修改,用它改公共历史会坑全组人。

讲清楚要点

  1. 分支策略:小团队主流是 GitHub Flow——main 永远可部署,所有改动走 feature 分支 + PR + 评审后合并;大型项目用 Git Flow(main + develop + feature/release/hotfix 多分支)。初学者先把 GitHub Flow 玩熟。
  2. Commit 规范(Conventional Commits):格式 类型: 描述,常见类型 feat(新功能)、fix(修 bug)、docs、refactor、test、chore。好处是历史可读、可自动生成变更日志。
  3. 小步提交:一个 commit 只做一件事。出了问题能精确回滚,评审的人也能快速看懂。500 行混杂大提交是评审灾难。
  4. 代码评审看什么:正确性(逻辑边界)、可读性(命名、结构)、安全(注入、密钥泄漏)、测试(是否补了用例)、性能(N+1、慢查询)。评审对事不对人,被提意见不是被否定。
  5. merge vs rebase:merge 保留分支历史、产生合并提交;rebase 把你的提交「搬到」目标分支末尾,历史更线性,但会改写提交,已推送的公共分支禁止 rebase。

你可能会懵的地方

  • git pull 和 git fetch 有什么区别? fetch 只把远端新提交下载到本地仓库,不动你的工作区;pull = fetch + merge,直接合并到当前分支。养成 fetch 后先看 git log origin/main..main 再决定怎么合并的习惯,能避免很多意外。

  • clone 和 fork 有什么区别? clone 是把仓库复制到本地;fork 是在 GitHub 上把别人的仓库复制成「自己账号下的仓库」。给开源项目贡献代码:fork → clone 自己的 fork → 改 → push 到自己的 fork → 向原仓库发 PR。

  • 为什么我的提交作者显示不对? 提交署名来自 user.name/user.email,公司项目常要求用企业邮箱。仓库级覆盖:git config user.email "工作邮箱"(去掉 --global)。

  • .gitignore 是干什么的? 声明哪些文件不进版本库:node_modules/、.env(密钥!)、日志、编译产物。必须在第一次提交前就配好,密钥一旦提交,即使后面删掉,历史里仍然找得到。

  • HEAD 是什么? 指向「你当前所在的提交」的指针。HEAD~1 是上一个提交,git diff HEAD 看当前与最近提交的差异。

错法对照

错法问题正解
所有开发直接在 main 上进行无法评审、无法回滚单个功能feature 分支 + PR
git commit -m "update"三个月后没人知道改了什么fix: 修复订单金额计算精度问题
git push -f 到共享分支覆盖别人的提交,团队事故强推只允许在自己的 feature 分支
用 reset --hard 撤销已推送提交改写公共历史,协作者全乱用 git revert
提交 .env、密钥、大文件泄漏风险 + 仓库膨胀写进 .gitignore,密钥用环境变量
半年才 merge 一次分支冲突堆积如山分支存活不超过 2-3 天,勤拉 main

卡点急救

  1. push 被拒 ! [rejected] ... fetch first:远端有别人新提交。git pull --rebase 后再 push;有冲突就按步骤 4 解决。
  2. 不小心 commit 了不该提交的文件(还没 push):git reset --soft HEAD~1 撤销提交(保留改动),重新选择性 add。
  3. 误改一堆文件想全部还原(未提交):git restore .,注意这会丢弃工作区修改,不可恢复。
  4. GitHub push 要求登录:密码已废弃,用 Personal Access Token(Settings → Developer settings → Tokens)当密码,或配置 SSH key。
  5. 每次提交都提示换行符警告(LF/CRLF):Windows 上执行 git config --global core.autocrlf true,macOS/Linux 用 input,警告无害但统一配置可减少无意义 diff。

面试常问

  • merge 和 rebase 的区别与选择? merge 保留完整分支拓扑、安全不改历史;rebase 线性干净但改写提交。个人未推送的分支 rebase 到最新 main 后再提 PR,历史整洁;公共分支一律 merge。

  • 如何撤销一次已经 push 的错误提交? git revert <hash> 生成反向提交再 push,绝不 reset 改写公共历史。若是敏感信息泄漏,revert 不够,需要历史清除 + 立即换密钥。

  • hotfix 流程怎么走? 从 main(或最新生产 tag)拉 hotfix/xxx 分支 → 修复 + 补测试 → PR 加急评审 → 合并 → 发布 → 按需同步回开发分支。

  • Git 内部的对象模型了解吗? commit → tree → blob 三层对象:commit 记录快照指针与父提交,tree 记录目录结构,blob 存文件内容。这解释了为什么 Git 分支只是「一个指向 commit 的可移动指针」,建分支几乎零成本。

自测三问

  1. 工作区、暂存区、本地仓库、远程仓库分别对应哪条命令的流转?
  2. git revert 和 git reset --hard 的本质区别是什么?各适合什么场景?
  3. 给团队写一份 5 条以内的 Git 提交规范(类型 + 描述格式 + 粒度要求)。

小结一句话

Git 用三区模型管理变更、用分支支持并行开发、用 PR 保证团队质量;把「小步提交 + 规范信息 + 评审合并」变成肌肉记忆,协作就不慌。

延伸

  • Pro Git 中文版——Git 权威教材,免费
  • Conventional Commits 规范
  • 下一课:语言选型——四大后端语言各写一个 HTTP 服务,选出你的第一门。
加载本节练习…
← 上一课后端入门概览下一课 →语言选型