Git

Patch Application 补丁应用类似下面这样（Codex 使用的 OpenAI Patch 是不是借鉴的这个？）的描述文件变更的文本文件，通常包含： 哪些文件被修改 具体的行级变更 上下文信息 # 创建补丁 git diff > changes.patch # 未暂存的修改 git diff --cached > changes.patch # 已暂存的修改 git format-patch HEAD~3 # 最近 3 次提交生成补丁 # 应用补丁 git apply changes.patch # 直接应用，不创建提交 git am changes.patch # 应用并创建提交（用于format-patch生成的） 命令如 git diff、git stach 和 git rebase 都使用 patch。 这种修改方法，如果产生冲突则需要手动处理。 3-Way Merge 三方合并则是一种智能的合并算法，使用三个版本来解决合并冲突： A - B (feature分支) / Base \ C - D (main分支) Base: 共同的祖先提交 Current: 当前分支的最新提交 Incoming: 要合并进来的分支的最新提交 合并过程： ...

有时你开启了一个新的项目, 运行了 cargo init、uv init 和 go mod init 这些命令创建了工作所需要的必要文件, 同时也在 .gitignore 文件中添加了以下内容 target __pycache__ bin 一切都很顺利, 你继续开发新功能, 等到时机成熟时就将项目发布到了 Git 托管平台上 人们开始对你的项目感兴趣, 甚至有人决定为你实现一个新功能, 这简直是免费劳动力! 当你查看代码, 发现了一个格格不入的文件 .DS_Store, 你问那个人这是什么, 他说他根本不知道 然后你只是将该文件从分支里面删除, 并把文件名加入了仓库的 .gitignore target __pycache__ bin .DS_Store 现在代码合并到了 main, 仓库里只包含有用的内容 接着, 另一人使用基于 Web 技术的 IDE 提交了另一个合并请求, 一看发现有一个完全无关的目录也被提交了, 于是 .gitignore 里又增加了一条内容 target __pycache__ bin .DS_Store .vscode 接下来, 有人使用 IntelliJ IDEA 提交了五百个 XML 文件和 .idea 目录, 这时又不得不将其加入 .gitignore target __pycache__ bin .DS_Store .vscode .idea 多年后, .gitignore 已经有了上百行, 但是仍然时不时有各种奇怪的文件, 例如 testscripts、foo、a、qux、data.tar.gz、start.sh、cat …… ...