Git | 锤子前端

《Domenic 的 Agentic 编码工作流：2026 年 7 月实战指南》

Mon, 03 Aug 2026 00:54:30 GMT

《Domenic 的 Agentic 编码工作流：2026 年 7 月实战指南》

标签：#前端 #AI_Agent #Claude_Code #ChatGPT #Tailscale #Git_Worktrees #DevOps #远程开发

总结：
Domenic 分享了他脱离企业环境后搭建的一套 AI 辅助开发工作流：以一台常驻开机的 Linux VM 为中枢，通过 Tailscale 构建跨设备私有网络，让 ChatGPT/Claude 桌面应用作为瘦客户端远程操控 Agent。核心亮点包括零审批的"YOLO"安全策略、Git worktrees 实现多 Agent 并行开发、Portless 自动暴露安全预览服务器、VS Code Remote-SSH 审查代码，以及 chezmoi 同步配置。最终效果惊人——他能在火车上用手机连接 VM，让前沿模型修复生产 bug 并直接合并 PR。

文章要点：
1. Linux VM + Tailscale 是地基：Agent 训练数据几乎全是 Bash/Unix 工具，Windows 下寸步难行。用 Ubuntu Server 搭一台可抛弃的 VM，配合 Tailscale 的魔法 SSH 和 HTTPS 证书，无论在哪台设备、哪个 Wi-Fi 下都能无缝接入，还能让 Agent 启动的开发服务器拥有安全上下文。
2. ChatGPT 桌面应用体验完胜 Claude：ChatGPT 原生支持远程 SSH 会话，断线重连优雅、worktree 管理清爽（默认放在 ~/.codex/worktrees/）；Claude 桌面应用则在 SSH/Remote Control 混合逻辑、会话同步、worktree 目录污染项目等方面表现糟糕，目前只能退而求其次用 Claude Code + tmux。
3. Git Worktrees 解锁并行开发：在 VM 上让多个 Agent 同时 hack 同一个仓库而不互相踩脚，ChatGPT 和 Claude 都支持一键勾选 worktree 模式。Agent 会自动处理 origin/main 同步、依赖安装和 .env 复制，人类完全不用操心。
4. Portless 让预览服务器"零摩擦"：不用改 npm run dev 绑定 0.0.0.0，也不用记端口。tportless 包装器自动把 localhost 服务代理到 Tailscale 专属域名（如 https://agents-base.tail234567.ts.net:8443/），多 Agent 并行时端口自动隔离，且外网无法访问。
5. "危险模式"下的生存策略：把 ~/.codex/config.toml 和 ~/.claude/settings.json 都设为"永不询问权限"，配合 sudo 和 gh CLI 登录，让 Agent 能自主装工具、发 PR、合并代码。风险靠"频繁推送到 GitHub 私有仓库"来对冲——VM 炸了代码也在云端。
6. 手机修生产 Bug 已成现实：完整闭环——聚会发现 bug → 火车上打开 ChatGPT App → 远程连接 VM 启动修复 → 收到推送通知里的预览链接验证 → 手机审阅 diff 并合并 PR → 到家前 GitHub Actions 已部署上线。这就是未来。

URL：https://domenic.me/agentic-coding-setup/

Domenic Denicola

My Agentic Coding Setup, July 2026

With the right tools, coding agents can run autonomously, in parallel, and be reachable from anywhere. Here's how I've stitched them together.

《Git Worktrees 入门指南：把分支变成平行工作空间》

Sat, 18 Jul 2026 15:26:37 GMT

《Git Worktrees 入门指南：把分支变成平行工作空间》

标签：#Git #工作流 #AI辅助编程 #开发工具 #分支管理

总结：

Git worktrees 是一个被低估十年的功能，它将分支检出到独立目录而非项目根目录，让开发者能在同一仓库中并行处理多个任务。文章从基础命令讲起，演示了如何创建、管理和清理 worktree，特别强调了它在 AI 编码代理时代的新价值——多个智能体可在独立工作树中自主工作互不干扰，完成后合并回主仓库，无需将代码推送到云端即可实现并行开发。

文章要点：

1. Worktree 的本质就是"检出到不同目录的分支"，它共享完整提交历史，能正常推拉远程，唯一区别是文件物理位置不同
2. 创建命令 git worktree add ../project.worktrees/feature-name -b feature/name main 会在指定目录新建分支，但依赖需要重新安装（如 node_modules 不共享），且该分支在 worktree 存在时无法在别处检出
3. 目录组织有两种风格：与主仓库平级的直接兄弟目录，或统一放在 .worktrees 共享父目录下；后者更整洁，尤其适合 AI 代理批量创建工作树
4. 合并变更既可以通过常规的 push + PR 流程，也可以在本地用 rebase 后 merge；清理时用 git worktree remove 删除目录但保留分支，确认无用后再 git branch -d 删除分支
5. git worktree list 能查看所有工作树状态，配合 git config --global alias.wt worktree 设置别名后，整个工作流（创建、查看、移除）都能用简短的 wt 命令完成
6. 核心价值在于"本地并行"：AI 编码工具现在常用 worktrees 让多个代理同时修改代码，既避免了分支切换的上下文丢失，也省去了云端暂存的麻烦

URL：https://humanwhocodes.com/blog/2026/07/introduction-git-worktrees/

Human Who Codes

A gentle introduction to Git worktrees - Human Who Codes

Git worktrees let you check out multiple branches into separate directories simultaneously, making parallel local development straightforward whether you're working solo or alongside AI coding agents.

《Git_Worktree_是什么以及为什么现在应该使用它》

Sat, 20 Jun 2026 09:52:46 GMT

《Git_Worktree_是什么以及为什么现在应该使用它》

标签：#Git #GitHubCopilot #Worktree #上下文切换 #AI_并行开发

总结：
Git Worktree 是 Git 2015 年就已内置的功能，但最近因 AI 时代并行开发需求激增而重新流行。它允许你在同一仓库的不同分支上同时工作，每个分支拥有独立的文件夹，彻底告别 stash 切换和编辑器上下文中断的烦恼。GitHub Copilot 应用已将其作为默认工作模式。

文章要点：
1. 告别 stash 地狱：紧急修 bug 时再也不用 stash 当前工作、切分支、修完再切回来 pop stash 了，Worktree 让你原地不动就能开新窗口干活
2. 每个分支一个文件夹：用 git worktree add 瞬间创建基于任意分支的独立工作目录，原编辑器窗口完全不受影响，真正实现并行开发
3. AI 时代让它翻红：以前 Worktree 鲜为人知，现在因为 AI Agent 和人类开发者需要大量并行会话，它成了 GitHub Copilot 等工具的默认模式
4. 注意几个小坑：每个 Worktree 都要独立装依赖（磁盘会胖）、文件夹要记得清理、同一分支不能同时在两个 Worktree 检出
5. VS Code 和 Copilot 都原生支持：不需要记命令，图形界面里直接选"New worktree"就能用，路径和变更状态一目了然

URL：https://github.blog/ai-and-ml/github-copilot/what-are-git-worktrees-and-why-should-i-use-them/

The GitHub Blog

What are git worktrees, and why should I use them?

Git worktrees have been around since 2015, but it wasn't until recently they became popular. Learn what they are, how to use them, and why you might.

《Git 的魔法文件》

Sat, 28 Feb 2026 08:14:49 GMT

《Git 的魔法文件》

标签：#Git #版本控制 #GitIgnore #GitAttributes #GitLFS #GitModules #Mailmap #GitBlame #EditorConfig #开发工具

总结：Git 仓库中的"魔法文件"是随代码提交的特殊配置文件，用于控制 Git 行为。文章系统介绍了 .gitignore`、.gitattributes`、`.lfsconfig`、`.gitmodules`、`.mailmap`、`.git-blame-ignore-revs` 等核心文件的功能与语法，涵盖文件忽略、属性管理、大文件存储、子模块、作者映射、blame 忽略等场景，同时提及代码托管平台专用文件夹及其他生态工具（如 .editorconfig`、.dockerignore`）的配置模式，为工具开发者和使用者提供完整参考指南。

文章要点：
- .gitignore 定义忽略规则，支持通配符、目录标记和否定模式，仅影响未跟踪文件；Git 按层级检查多个位置的 ignore 文件
- .gitattributes 控制文件处理逻辑，包括行尾规范化（`text eol=lf`）、diff/合并驱动、二进制标记，以及 GitHub Linguist 的语言检测覆盖（`linguist-vendored`、`linguist-generated`）
- .lfsconfig 存储 Git LFS 服务端配置，使用 git config 格式设置 URL 和传输选项，确保团队成员共享相同设置
- .gitmodules 管理子模块依赖，包含路径、URL 和分支信息；子模块不会随 git clone 自动获取，需使用 --recurse-submodules 或手动初始化
- .mailmap 映射作者身份，将旧邮箱或姓名变体统一为标准身份，影响 git log`、`git shortlog 和 git blame 的输出（但不影响 GitHub 贡献者图表）
- .git-blame-ignore-revs 记录格式化、迁移等无意义提交的 SHA，使 git blame 跳过这些提交，直接显示实际逻辑作者；GitHub、GitLab 15.4+、Gitea 自动支持
- 代码托管平台使用专属文件夹（`.github/、.gitlab/、.gitea/` 等）存储 CI/CD 工作流、Issue 模板和 CODEOWNERS 配置；Forgejo 和 Gitea 支持配置回退链
- 其他生态工具延续相同模式：`.editorconfig` 统一编辑器行为、`.dockerignore` 控制构建上下文、`.ruby-version`/.node-version 指定语言运行时版本

文章URL：https://nesbitt.io/2026/02/05/git-magic-files.html

Andrew Nesbitt

Git’s Magic Files

Magic files and where to find them: .gitignore, .gitattributes, .mailmap, .git-blame-ignore-revs, .lfsconfig, and more.

#Git 多用户配置方法

Fri, 07 Feb 2025 02:01:30 GMT

#Git 多用户配置方法