目录
1 简介
本文档旨在提供一组有用的 Git 命令的快速参考。 您应该始终使用 Git 直接提供的详尽详细的文档
git --help man git
显示可用的子命令，
git <command> --help man git-<command>
显示关于子命令 <command> 的信息。
更多信息可以在 Git 参考网站上找到。
有关 Git 项目的更多信息，请访问 Git 网站。
当您遇到问题时，请查阅这些资源，它们非常详尽。
接下来是 Git 的基本介绍和一些 FFmpeg 特定的指导原则，以方便为该项目做出贡献。
2 基本用法
2.1 获取 Git
您可以从 https://git-scm.cn/ 获取 Git。 大多数发行版和操作系统都为此提供了软件包。
2.2 克隆源代码树
git clone https://git.ffmpeg.org/ffmpeg.git <target>
这会将 FFmpeg 源代码放入目录 <target>。
git clone [email protected]:ffmpeg <target>
这会将 FFmpeg 源代码放入目录 <target>，并允许您将更改推送回远程存储库。
git clone [email protected]:ffmpeg-web <target>
这会将 FFmpeg 网站的源代码放入目录 <target>，并允许您将更改推送回远程存储库。
如果您没有 ffmpeg-web 存储库的写入权限，您可以在创建只读的 ffmpeg-web 克隆后创建补丁。
git clone git://ffmpeg.cpp.org.cn/ffmpeg-web <target>
确保您的检出中没有 Windows 行尾符，否则您可能会遇到虚假的编译失败。 实现此目的的一种方法是运行
git config --global core.autocrlf false
2.3 将源代码树更新到最新版本
git pull (--rebase)
从跟踪分支中拉取最新的更改。 跟踪分支可以是远程的。 默认情况下，master 分支跟踪远程 origin 中的 master 分支。
建议使用 --rebase（见下文）。
2.4 变基本地分支
git pull --rebase
从主存储库获取更改并在其上重放您的本地提交。 这是必需的，以使您的所有本地更改保持在 FFmpeg 的 master 树的顶部。 master 树将拒绝包含合并提交的推送。
2.5 添加/删除文件/目录
git add [-A] <filename/dirname> git rm [-r] <filename/dirname>
Git 需要收到您对工作目录所做的所有更改的通知，这些更改会使文件出现或消失。 文件之间的行移动会自动跟踪。
2.6 显示修改
git diff <filename(s)>
将以统一差异的形式显示您的工作目录中的所有本地修改。
2.7 检查变更日志
git log <filename(s)>
您还可以使用图形工具，如 gitview 或 gitk，或者在 http://source.ffmpeg.org/ 上提供的 Web 界面。
2.8 检查源代码树状态
git status
检测您所做的所有更改，并列出在提交情况下将采取哪些操作（添加、修改、删除等）。
2.9 提交
git diff --check
在将更改提交之前仔细检查，以避免以后出现麻烦。 所有经验丰富的开发人员都会在每次提交时都这样做，无论多么小。
他们中的每个人都曾多次通过这样做避免了看起来像个傻瓜。 很容易滑入杂散的调试输出或外观修改，请通过这种额外的审查级别来避免问题。
对于仅外观的提交，您应该从以下位置获得（几乎）空的输出
git diff -w -b <filename(s)>
还要检查以下输出
git status
以确保您没有未跟踪的文件或删除。
git add [-i|-p|-A] <filenames/dirnames>
确保您已告知 Git 您的姓名、电子邮件地址和 GPG 密钥
git config --global user.name "My Name" git config --global user.email [email protected] git config --global user.signingkey ABCDEF0123245
启用对所有提交进行签名或使用 -S
git config --global commit.gpgsign true
使用 --global 为您的所有 Git 检出设置全局配置。
Git 将选择要提交的文件更改。 或者，您可以使用交互模式或补丁模式，逐块选择应添加到提交的内容。
git commit
Git 将把选定的更改提交到您当前的本地分支。
系统将提示您在编辑器中输入日志消息，该编辑器要么在您的个人配置文件中通过以下方式设置
git config --global core.editor
或由以下环境变量之一设置：GIT_EDITOR、VISUAL 或 EDITOR。
2.10 编写提交信息
日志消息应简洁但具有描述性。
第一行必须包含上下文、一个冒号和一个非常简短的提交内容摘要。 如果需要，可以添加详细信息，并以空行分隔。 这些详细信息每行不应超过 60-72 个字符，除非包含代码。
一个好的提交消息的示例
avcodec/cbs: add a helper to read extradata within packet side data Using ff_cbs_read() on the raw buffer will not parse it as extradata, resulting in parsing errors for example when handling ISOBMFF avcC. This helper works around that.
ptr might be NULL
如果第一行的摘要不够，请在消息正文中解释为什么进行更改，您所做的操作在大多数情况下从更改本身就很明显。 只说“错误修复”或“10l”是不好的。 请记住，不同技能水平的人在阅读您的代码时会进行查看和学习。 不要将文件名包含在日志消息中，除非在上下文中，Git 会提供该信息。
如果提交修复了已注册的问题，请在正文的单独一行中声明：Fix Trac ticket #42.
第一行将用于通过 git format-patch 命名补丁。
在 git log --oneline 中看到的，第一行的常见错误包括：开头缺少上下文； 描述补丁之前的代码所做的事情； 行太长或换行到第二行。
2.11 准备补丁集
git format-patch <commit> [-o directory]
将为 <commit> 和当前 HEAD 之间的每个提交生成一组补丁。 例如
git format-patch origin/master
将为当前分支上不存在于上游的所有提交生成补丁。 一个有用的快捷方式也是
git format-patch -n
它将从最后的 n 次提交生成补丁。 默认情况下，补丁在当前目录中创建。
2.12 发送补丁进行审查
git send-email <commit list|directory>
将发送由 git format-patch 创建的补丁或直接生成补丁。 所有电子邮件字段都可以在全局/本地配置中配置，也可以通过命令行覆盖。 请注意，此工具通常必须单独安装（例如，基于 Debian 的发行版上的 git-email 软件包）。
2.13 重命名/移动/复制文件或文件内容
Git 会自动跟踪此类更改，将其作为普通提交。
mv/cp path/file otherpath/otherfile git add [-A] . git commit
3 Git 配置
为了简化一些工作流程，建议同时配置您的个人 Git 安装和本地 FFmpeg 存储库。
3.1 个人 Git 安装
将以下内容添加到您的 ~/.gitconfig 中，以帮助 git send-email 和 git format-patch 检测重命名
[diff]
renames = copy
3.2 仓库配置
为了让 git send-email 自动将补丁发送到 ffmpeg-devel 邮件列表，请将以下节添加到 /path/to/ffmpeg/repository/.git/config
[sendemail]
to = [email protected]
4 FFmpeg 特定
4.1 回滚损坏的提交
git reset <commit>
git reset 将取消提交直到 <commit> 的更改，从而重写当前分支历史记录。
git commit --amend
允许快速修改上次提交的详细信息。
git rebase -i origin/master
将在主存储库上重播本地提交，从而允许您在过程中编辑、合并或删除其中一些提交。
git reset、git commit --amend 和 git rebase 会重写历史记录，因此您应该**仅在本地或主题分支上**使用它们。主存储库将拒绝这些更改。
git revert <commit>
git revert 将生成一个还原提交。这不会使错误的提交从历史记录中消失。
4.2 将更改推送到远程树
git push origin master --dry-run
将模拟将本地 master 分支推送到默认远程存储库（origin）。并列出将要推送的分支和范围或提交。如果本地和远程树不同步，Git 将阻止您推送更改。请参阅将源代码树更新到最新版本。
git remote add <name> <url>
将添加一个带有名称引用的附加远程存储库，如果您想将本地分支推送到远程主机进行审查，这将非常有用。
git push <remote> <refspec>
将更改推送到 <remote> 存储库。省略 <refspec> 会使 git push 更新所有与本地分支匹配的远程分支。
4.3 查找特定的 svn 版本
自 1.7.1 版本起，Git 支持使用 ‘:/foo’ 语法基于正则表达式指定提交。请参阅 man gitrevisions
git show :/'as revision 23456'
将显示 svn 变更集 ‘r23456’。对于较旧的 Git 版本，在 git log 输出中搜索是最简单的选择（尤其是在使用了具有搜索功能的寻呼器时）。
可以使用以下命令检出此提交：
git checkout -b svn_23456 :/'as revision 23456'
或者对于 Git < 1.7.1，使用：
git checkout -b svn_23456 $SHA1
其中 $SHA1 是 git log 输出中的提交哈希值。
5 gpg 密钥生成
如果您还没有 GPG 密钥，我们建议您创建一个基于 ed25519 的密钥，因为它体积小、速度快且安全。尤其是在 git 中会产生较小的签名。
gpg --default-new-key-algo "ed25519/cert,sign+cv25519/encr" --quick-generate-key "[email protected]"
生成密钥时，请确保指定的电子邮件与 git 中使用的电子邮件匹配，因为像 GitHub 这样的某些站点会认为不匹配是声明此类提交未验证的原因。生成密钥后，您可以将其添加到 MAINTAINER 文件并将其上传到密钥服务器。
6 推送前检查清单
一旦您有一组准备好推送的提交，请仔细检查以下清单，以确保一切正常。此列表力求详尽。如果您只是在注释中推送一个错别字，那么某些步骤可能是不必要的。运用您的常识，但如有疑问，请谨慎行事。
首先，确保您要推送的提交和分支与您要推送的内容匹配，并且没有任何遗漏、多余或错误。您可以先运行带有 --dry-run 的 git push 命令来查看将要推送的内容。然后使用 git log -p 1234567..987654 检查列出的提交。git status 命令可能有助于查找已忘记添加的本地更改。
接下来，让代码完整运行我们的测试套件。
-
make distclean -
/path/to/ffmpeg/configure -
make fate - 如果由于缺少示例而导致 fate 失败，请运行
make fate-rsync并重试
确保在推送之前检查过您的所有更改，测试套件仅检查回归，而且只在一定程度上。它显然不会检查新添加的功能/代码是否有效，除非您为此添加了测试（建议这样做）。
另请注意，每个提交都应该通过测试套件，而不仅仅是一系列补丁的结果。
一切通过后，将更改推送到您的公共 ffmpeg 克隆版本，并向 ffmpeg-devel 发布合并请求。您也可以直接推送它们，但不建议这样做。
7 服务器问题
如果您在 Git 服务器方面遇到技术问题，请通过 [email protected] 联系项目管理员。
本文档于 *2025 年 1 月 21 日* 使用 makeinfo 生成。
由 telepoint.bg 提供托管