Git 笔记

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

标题 Git Worktree 使用教程：同仓库并行开发多个分支副标题 / 摘要 git worktree 让你在同一个 Git 仓库下，同时打开多个分支对应的工作目录，不用来回 checkout 和 stash。本文覆盖常用命令、典型场景、常见坑，以及你最关心的 hotfix 分支创建方式（先进入 worktree 再建分支 / 一步建分支）。目标读者正在同时处理多个需求分支（feature / bugfix / hotfix）的开发者经常需要切到 main 修紧急问题，但不想污染当前工作目录的人需要对比不同分支代码、并行运行不同版本服务的工程师背景 / 动机很多人第一次遇到并行任务时，会用这套流程： git stash git checkout main # 修 bug git checkout feature/xxx git stash pop 这套流程不是不能用，但有几个问题： stash 容易忘记清理或弹错时机来回切分支容易打断当前开发节奏长时间运行测试/构建会占住当前工作目录对比两个分支代码时不够直观 git worktree 的价值就是：在一个仓库里同时拥有多个工作目录，各做各的事，互不干扰。核心概念 worktree（工作树）：同一仓库的一个额外工作目录共享对象库：多个 worktree 共享同一套 Git 对象数据（不是多个独立 clone）独立工作目录：每个 worktree 有自己的文件内容、当前分支、未提交修改分支占用限制：同一分支不能同时被多个 worktree 检出（Git 会保护你） stash 是仓库级别：不是 worktree 级别，多个 worktree 共享同一个 stash 列表结构示意（ASCII）： ...

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

标题 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

标题（吸引且准确，包含关键词）用 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

🚀 本地搭建 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提交规范,让团队协作更高效率

标题 🚀 从「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

在局域网访问 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分支管理方法

🌿 简化 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裸仓库实现开发环境和测试环境隔离

在本地使用 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) 说明配置成功。 ...

推荐阅读