Published2025-12-22
Topic基本功 · 教程
Size2234 chars · 1 code blocks

基本操作：（一）github is all you need

基本操作：（一）github is all you need

码农圣地 github

github众所周知，是最大的同性交友网站开源项目公布网站，每个人都可以在这里share自己的项目。

由于open-source往往由一个团队进行开发，所有有很多开发版本，为了管理不同的开发版本之间的异同，远古linux大神linus写了git的原型来管理不同的fork。每个opensource都有一条master主线，然后有不同的分支合并到master分支上。由此也看出，git最主要的功能就是派生（fork）、合并（merge）。

这里我不想重复造轮子，请直接观看我觉得非常棒的讲解。

issues和PR

把 GitHub 想成一个研发团队的工单系统：

Issue 像工单 / 任务卡，比如：

  • 这个 bug 要修
  • 这个功能要加
  • 这个文档要补
  • 这个体验要优化

PR 像交付单 / 审核单，比如：

  • 我已经写完了
  • 请大家 review 一下
  • 没问题就把代码合进去

常见的过程就是Issue 提出问题 → 开分支开发 → 提交代码 → 创建 PR → PR 合并后，Issue 关闭。

需要注意的是两者的区别：

  • Issue：讲问题、目标、背景、验收
  • PR：讲改动、实现、测试、风险

一个PR可以修多个issues，但是不建议这么做。那么具体来说如何进行流转呢

常见流程

1. 有事先开 Issue

哪怕一句话也行，例如：

  • Fix dev child process cleanup
  • Add OSS upload helper
  • Hide LLM config entry

2. 从 Issue 开分支

分支名和 issue 对应起来：

  • fix/dev-process-exit
  • feat/oss-upload
  • feat/hide-llm-config

3. 改完开 PR

PR 标题写清楚：

  • fix: improve dev process exit handling
  • feat: add OSS upload flow
  • feat: hide LLM config entry

4. PR 描述里写关联

例如：

Closes #4

5. 合并后删分支

保持仓库干净。

看到这里，你可能已经懂了大概的意思了，具体怎么做呢，可能还有点迷茫，推荐看我get shit down的那篇博客。

常见前缀

你以后也会经常看到这些：

  • feat: 新功能
  • fix: 修复 bug
  • refactor: 重构，但不新增功能也不修具体 bug
  • docs: 文档修改
  • style: 代码格式、排版、lint 修正
  • test: 测试相关
  • chore: 杂项维护，比如依赖更新、脚本调整、构建配置

格式

那么如何写好一个issues呢，一个好 Issue 只需要说清楚 4 件事：

  • 是什么问题：现象是什么
  • 为什么要做：影响是什么，值不值得做
  • 怎么判断做完了：验收标准是什么
  • 有什么补充信息：日志、截图、复现步骤、参考链接

PR也差不多

  • 总结：这个PR改了什么
  • 为什么要做：影响是什么
  • 测试：验收标准是什么
  • 关联：关闭哪个issues

其实没有格式是绝对的，只要能说清楚就行，上面每一个加黑的点都用##进行markdown的分段就行

sourcetree

网络代理

首先，网络代理方面非常重要，这关乎于能否正常链接github，在 SourceTree 中设置代理：

  1. 点击菜单 工具(Tools) → 选项(Options)

  2. 选择 网络(Network) 标签页

  3. 勾选 启用代理服务器(Enable HTTP proxy server)

  4. 填写你的代理信息：

    • 代理主机：127.0.0.1 或你的代理服务器地址
    • 代理端口：7890 或你的代理端口（常见的是 7890, 1080, 8080）
    • 如果代理需要认证，填写用户名和密码

  5. 点击 确定(OK)

所有的起点 —— 新建一条分支

创建新分支：

  1. 在左侧 "分支" 面板中，右键点击当前分支（如 main）
  2. 选择 "新建分支"
  3. 输入你的分支名（如 my-custom-feature）
  4. 勾选 "检出新分支"（自动切换到这个分支）
  5. 点击 "确定"

魔改的日常

进行修改：

  • 在你的项目文件夹中编辑代码（"魔改"）

提交更改：

  1. 在 SourceTree 中，你会看到 "未暂存文件" 列表
  2. 勾选要提交的文件（或点击 "暂存所有"）
  3. 在下方的提交信息框中填写说明（如 "添加了新功能X"）
  4. 点击右下角的 "提交" 按钮

推送到远程：

  • 点击工具栏的 "推送" 按钮
  • 确保勾选你的分支（如 my-custom-feature）
  • 点击 "确定"

合并一条分支的多个节点

方法A：交互式变基（推荐）

  1. 右键点击你的分支，选择 "变基子代"
  2. 勾选 "交互式变基"
  3. 在弹出的提交列表中，除了第一个提交，把其他的都改为 squash 或 fixup
  4. 完成后会生成一个新的合并提交

方法B：软重置后重新提交

  1. 右键点击分支最早的父提交，选择 "重置当前分支到此次提交"
  2. 选择 "软重置"（保留工作区更改）
  3. 所有更改会回到暂存区
  4. 重新做一次提交，包含所有更改

AB的虽然最终代码一样，但生成的 Git 历史不同：

  • 交互式变基：产生一个可追溯的合并提交，包含所有被压缩提交的元数据，推荐合并多个模块的时候使用
  • 软重置：产生一个全新的提交，与之前的历史完全断开，推荐单个模块内合并多次开发的时候使用

举个例子：

  • 交互式变基：像用扫描仪把 5 张草图扫描后，用 Photoshop 分层合并，可以保留每层的标签和备注
  • 软重置：像把 5 张草图全撕了，直接在一张新纸上重新画，之前的草图痕迹完全消失
特性方法A：交互式变基方法B：软重置+重新提交
操作方式Git 自动合并提交手动重置后重新提交
灵活性高，可选择保留哪些提交、调整顺序低，一次性合并所有提交
提交信息保留所有原始提交信息，可编辑合并完全丢弃中间提交信息，需重写
操作难度稍复杂，需要理解 rebase 流程简单直接，适合新手
适用场景需要精细控制合并过程快速合并，不关心中间历史

合并一条分支到主分支

  1. 切换到主分支：

    • 双击左侧的 main 分支

  2. 合并你的分支：

    • 右键点击你的分支（如 my-custom-feature）

    • 选择 "合并 my-custom-feature 到当前分支"

    • 选择合并方式：

      • 合并提交：保留两个分支历史（推荐）
      • 变基：把你的提交应用到主分支顶端（历史更线性）
      • squash ：把你的所有提交压缩成一个提交

  3. 推送到远程：

    • 点击 "推送" 按钮，推送合并后的主分支