福生无量摸鱼天尊

基本操作:(一)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. 合并后删分支

保持仓库干净。

常见前缀

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

  • 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. 在弹出的提交列表中,除了第一个提交,把其他的都改为 squashfixup

  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. 推送到远程:

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