Git on Jeanphilo Blog

Git Worktree 使用教程：同仓库并行开发多个分支

Wed, 25 Feb 2026 09:27:18 +0800

一篇讲清 Git worktree 常用命令、典型场景、常见坑与最佳实践的中文教程，适合多分支并行开发与临时 hotfix。

Git 入门教程：从零开始管理代码版本

Thu, 15 Jan 2026 00:00:00 +0000

标题

Git 入门教程：从零开始管理代码版本

副标题 / 摘要

一篇面向新手的 Git 基础使用指南，从初始化仓库、提交版本到远程协作，用最少命令完成日常开发流转。

目标读者

初学者：第一次接触 Git，希望快速上手基本命令。
转岗工程师：从单机开发转为团队协作，需要熟悉版本管理流程。
学生：做课程项目或实验，需要规范保存代码历史。

背景 / 动机

没有版本管理时，常见的做法是：

“先复制一份目录，改完再看看哪个好用。”

这种方式很快会失控：文件版本混乱、无法回退、多人协作冲突频发。 Git 的价值在于记录每一次变更，让你随时回到过去的任意状态，并支持多人同时开发而不互相覆盖。

核心概念

仓库（Repository）：一个包含代码与历史记录的目录。
工作区（Working Directory）：你当前编辑的文件。
暂存区（Staging Area）：等待提交的文件清单。
提交（Commit）：一次可追溯的版本快照。
远程仓库（Remote）：托管在服务器上的仓库，用于协作和备份。

实践指南 / 步骤

1️⃣ 初始化仓库

git init

2️⃣ 查看当前状态

git status

3️⃣ 把文件加入暂存区

git add .

4️⃣ 提交一次版本

git commit -m "init: first commit"

5️⃣ 绑定远程仓库并推送

git remote add origin https://example.com/your/repo.git
git branch -M main
git push -u origin main

协作流程（从克隆到提交）

这一部分是团队协作的核心，决定了你能否安全、稳定地和他人同步代码。掌握这些命令，能避免覆盖同事的提交，减少冲突和返工。

用Issue把问题写清楚，从0到TEMPLATE

Tue, 11 Nov 2025 00:00:00 +0000

标题（吸引且准确，包含关键词）

用 Issue 模板把需求写清楚：从 0 配置 GitHub Issue Template 的完整指南

副标题 / 摘要

这篇文章手把手教你在 GitHub 仓库中配置「新需求 / Feature」与「Bug」Issue 模板，包括目录结构、YAML 表单、Markdown 模板以及常见坑。适合想让团队需求沟通更规范、减少反复追问的开发者和团队负责人。

目标读者

这篇文章适合：

经常在 GitHub 仓库里开 Issue、提需求的 后端 / 前端 / 全栈工程师
想把团队需求提交流程「标准化」的 项目负责人 / TL / 架构师
对 GitHub 已经有基本使用经验、但还没用过 Issue 模板的 中级开发者

完全新手也能看懂，但会默认你知道：什么是仓库、什么是 Issue、如何提交代码等。

背景 / 动机：为什么要折腾 Issue 模板？

没有 Issue 模板时，日常可能是这样的：

“这个需求背景是什么？”
“影响哪些模块？”
“验收标准怎么算通过？”
“优先级到底多高？”

一句话 Issue：

“做个导出功能” 直接把所有人整破防。

长期下来会有几个痛点：

沟通成本高：每个需求都要反复追问细节；
信息不对称：请求人脑子里很清楚，但写在 Issue 里的只有一句话；
难以排期：没有明确优先级和验收标准，大家都觉得自己的需求是 P0；
历史难追踪：几个月后再看这个 Issue，完全不知道当时怎么想的。

而 GitHub 提供的 Issue Template，其实就是一套「结构化提问」工具：

如何配置gitea

Tue, 28 Oct 2025 00:00:00 +0000

🚀 本地搭建 Gitea：打造你的私人 GitHub（含已有仓库导入指南）

副标题 / 摘要： 本文将手把手教你在本地电脑上安装轻量级 Git 服务器 —— Gitea。无需 root、不会影响系统环境，让你像在 GitHub 一样管理、查看和推送项目，还能导入已有仓库。

目标读者： 👉 适合个人开发者、独立工程师、小型团队技术负责人。适用于初中级开发者，有 Git 基础即可上手。

🧠 背景 / 动机

很多开发者希望：

在公司电脑或内网环境下托管代码；
不想使用云端（如 GitHub、Gitee）；
又希望有 Web 界面、Pull Request、代码浏览体验。

但 GitLab 太重（动辄占用数 GB 内存），而 Gitea 则：

🌱 轻量级、单可执行文件、支持 PR、Wiki、Issue、CI/CD。

只需几分钟，你就能拥有一个完全属于自己的“小型 GitHub”。

📘 核心概念

名称	说明
GitLab	功能最强大的开源 Git 平台，但资源占用高
Gitea	轻量级自托管 Git 服务，界面类似 GitHub
Bare 仓库	只保存版本数据、不包含工作区的纯仓库
Pull Request	一个分支向另一个分支发起的合并请求
SQLite	Gitea 默认使用的轻量数据库，无需额外配置

🧩 实践指南 / 安装步骤

1️⃣ 准备环境

系统要求：Linux / macOS / Windows 均可推荐配置：内存 ≥ 512MB，磁盘 ≥ 1GB

掌握git提交规范,让团队协作更高效率

Sat, 25 Oct 2025 00:00:00 +0000

标题

🚀 从「feat」到「fix」：掌握 Git 提交规范，让团队协作与自动化更高效

副标题 / 摘要

一篇为开发者准备的实用指南，带你理解并掌握业界通行的 Git 提交信息标准（Conventional Commits），从 commit 标签（如 feat:、fix:）到自动生成 changelog，一次学会写出高质量的提交记录。

目标读者

初学者：刚开始使用 Git，想养成规范提交的习惯。
中级开发者：希望让提交信息对团队和 CI 工具更友好。
团队负责人 / 架构师：想建立统一的代码提交标准，提升协作与版本管理效率。

背景 / 动机

大多数开发者写提交信息的方式都是这样的：

“update code” “fix bug” “修改东西”

这类信息短期可读，长期无用。当团队人数增多、项目复杂时，无法追踪改动意图，也无法让自动化工具正确识别变更类型。这就是为什么业界推出了 Conventional Commits：一个简洁统一的 commit 语法标准，让 Git 提交可读、可追踪、可自动化。

核心概念

Conventional Commits 是一种提交信息格式约定，它规定了提交消息的结构：

<type>(<scope>): <subject>
<body>
<footer>

type：提交类型，如 feat、fix、docs
scope：作用范围，可选（如 ui、api）
subject：简短描述（不超过 50 字）
body：详细说明（可选）
footer：备注（如 BREAKING CHANGE）

实践指南 / 步骤

1️⃣ 设置 Git 编辑器为 Neovim（可选）

局域网Git Bare

Wed, 22 Oct 2025 00:00:00 +0000

在局域网访问 Windows WSL2 上的 Git Bare 仓库

在开发中，我们经常需要在多台电脑之间共享 Git 仓库。如果你在 Windows 上使用 WSL2，并且想在同一局域网的其他电脑访问 WSL2 上的 Git bare 仓库，本文将一步步教你实现。

1. 在 WSL2 创建 Git Bare 仓库

打开 WSL2 终端，进入你想存放仓库的目录，执行：

git init --bare my_project.git

my_project.git 是 bare 仓库，不含工作区，仅用于推送和拉取。
bare 仓库就像远程仓库一样，可以被克隆和操作。

2. 配置 WSL2 的 SSH 服务

为了让其他电脑访问仓库，需要通过 SSH 访问 WSL2。

安装 SSH 服务：

sudo apt update
sudo apt install openssh-server -y

启动 SSH 服务：

sudo service ssh start

检查 SSH 服务状态：

sudo service ssh status

默认端口是 22，可以在 /etc/ssh/sshd_config 修改。

3. 获取 WSL2 IP 地址

在 WSL2 终端运行：

git分支管理方法

Mon, 20 Oct 2025 00:00:00 +0000

🌿 简化 Git 分支工作流（个人 / 小团队）

本工作流基于 Git Flow 精简而来，适合个人或小团队，既规范又不复杂。

🚀 1. 主分支（长期分支）

main
- 永远保持稳定、可发布的状态。
- 部署到生产环境的代码都来自这里。

对于小团队，通常只需要 main，不需要维护 develop。

🛠️ 2. 功能开发（Feature Branch）

分支命名：feature/<功能名>
用途：开发新功能，完成后合并回 main。

示例：


feature/login-api
feature/user-profile

流程：

# 从 main 创建功能分支
git checkout -b feature/login-api main

# 开发完成后，合并到 main
git checkout main
git merge feature/login-api
git branch -d feature/login-api

🐞 3. Bug 修复（Bugfix Branch）

分支命名：bugfix/<问题名>
用途：修复测试或开发环境的 bug。

示例：

bugfix/fix-login-redirect

流程同 feature 分支，完成后合并回 main。

🔥 4. 紧急修复（Hotfix Branch）

分支命名：hotfix/<问题名>
用途：生产环境出现严重问题时的快速修复。

示例：

在本地使用git裸仓库实现开发环境和测试环境隔离

Mon, 20 Oct 2025 00:00:00 +0000

在本地使用 Git 裸仓库实现开发环境和测试环境隔离

在全栈开发的过程中，我们常常遇到一个问题：开发环境和测试环境如何隔离？很多人第一反应是用 GitHub 或 GitLab 来托管代码，但如果项目涉及隐私，不方便放在公共仓库，那该怎么办呢？

其实，Git 是分布式的，我们完全可以在 本地电脑上建立一个“裸仓库 (bare repo)”，当作“远程仓库”来用，从而实现 开发环境 → 测试环境 的代码迁移和同步。

什么是裸仓库 (bare repository)

普通 Git 仓库（git init）包含 工作区 + .git 元数据，可以直接编辑文件。
裸仓库（git init --bare）只有 Git 的版本信息，没有工作区，不能直接编辑文件，通常作为 远程仓库 来存储和同步代码。

简单理解：

开发仓库：我在这里写代码。
裸仓库：我用来存放代码历史，作为远程同步点。
测试仓库：从裸仓库克隆出来，模拟运行环境。

步骤一：创建裸仓库

在本机某个目录（比如 ~/.repos）下创建裸仓库：

mkdir -p ~/.repos
cd ~/.repos
git init --bare scrapy.git

这样你得到一个路径 ~/.repos/scrapy.git，它就是本地的远程仓库。

步骤二：在开发仓库里添加远程

假设你的开发仓库在 ~/scrapy：

cd ~/scrapy
git remote add local ~/.repos/scrapy.git

检查一下远程是否添加成功：

git remote -v

输出类似：

local /home/gong/.repos/scrapy.git (fetch)
local /home/gong/.repos/scrapy.git (push)

说明配置成功。