目录
1 简介
本文档旨在提供一些有关一组有用的 Git 命令的快速参考。您应该始终使用 Git 直接提供的广泛且详细的文档：
git --help man git
显示可用的子命令，
git <command> --help man git-<command>
显示有关子命令 <command> 的信息。
其他信息可以在Git 参考网站上找到 。
有关 Git 项目的更多信息，请访问 Git 网站。
每当您遇到问题时，请查阅这些资源，它们非常详尽。
接下来是 Git 的基本介绍和一些特定于 FFmpeg 的指南，以简化对项目的贡献。
2 基础用法
2.1 Get Git
您可以从http://git-scm.com/获取 Git 大多数发行版和操作系统都为其提供了软件包。
2.2 Cloning the source tree
git clone https://git.ffmpeg.org/ffmpeg.git <target>
这会将 FFmpeg 源放入目录<target>中。
git clone git@source.ffmpeg.org:ffmpeg <target>
这会将 FFmpeg 源放入目录<target>中，并让您将更改推送回远程存储库。
git clone gil@ffmpeg.org:ffmpeg-web <target>
这会将 FFmpeg 网站的源代码放入目录 <target>中，并让您将更改推送到远程存储库。（请注意，gil代表 GItoLite，并不是git的拼写错误。）
如果您没有 ffmpeg-web 存储库的写访问权限，则可以在制作只读 ffmpeg-web 克隆后创建补丁：
git clone git://ffmpeg.org/ffmpeg-web <target>
确保您的结帐中没有 Windows 行结尾，否则您可能会遇到虚假的编译失败。实现此目的的一种方法是运行
git config --global core.autocrlf false
2.3 Updating the source tree to the latest revision
git pull (--rebase)
从跟踪的分支中提取最新的更改。跟踪的分支可以是远程的。默认情况下，master 分支跟踪远程源中的分支 master。
--rebase（见下文）推荐。
2.4 Rebasing your local branches
git pull --rebase
从主存储库中获取更改并重播您的本地提交。这是将所有本地更改保留在 FFmpeg 主树顶部所必需的。主树将拒绝合并提交的推送。
2.5 Adding/removing files/directories
git add [-A] <filename/dirname> git rm [-r] <filename/dirname>
Git 需要收到您对工作目录所做的所有导致文件出现或消失的更改的通知。自动跟踪跨文件的行移动。
2.6 Showing modifications
git diff <filename(s)>
会将工作目录中的所有本地修改显示为统一差异。
2.7 Inspecting the changelog
git log <filename(s)>
您还可以使用图形工具，例如gitview或或http://source.ffmpeg.org/gitk
上提供的 Web 界面。
2.8 Checking source tree status
git status
检测您所做的所有更改并列出提交时将采取的操作（添加、修改、删除等）。
2.9 Committing
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 my@email.invalid git config --global user.signingkey ABCDEF0123245
启用对所有提交进行签名或使用 -S
git config --global commit.gpgsign true
使用- 全球的为所有 Git 签出设置全局配置。
Git 将选择对文件的更改进行提交。或者，您可以使用交互或修补模式来逐块选择应添加到提交中的内容。
git commit
Git 会将选定的更改提交到当前的本地分支。
系统将提示您在编辑器中输入日志消息，该消息可以通过以下方式在您的个人配置文件中设置
git config --global core.editor
或通过以下环境变量之一设置： GIT_EDITOR、VISUAL或EDITOR。
2.10 Writing a commit message
日志消息应该简洁但具有描述性。
第一行必须包含上下文、冒号和提交内容的简短摘要。如有必要，可以添加详细信息，并用空行分隔。这些详细信息每行不应超过 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 Preparing a patchset
git format-patch <commit> [-o directory]
将为<commit>和当前HEAD之间的每次提交生成一组补丁。例如
git format-patch origin/master
将为当前分支上不存在于上游的所有提交生成补丁。一个有用的快捷方式也是
git format-patch -n
这将从最后n次提交中生成补丁。默认情况下，补丁会在当前目录中创建。
2.12 Sending patches for review
git send-email <commit list|directory>
git format-patch将发送由它们创建或直接生成的补丁。所有电子邮件字段都可以在全局/本地配置中配置或通过命令行覆盖。请注意，此工具通常必须单独安装（例如基于 Debian 的发行版上的git-email
软件包）。
2.13 Renaming/moving/copying files or contents of files
Git 会自动跟踪此类更改，并进行正常提交。
mv/cp path/file otherpath/otherfile git add [-A] . git commit
3.Git配置
为了简化一些工作流程，建议配置您的个人 Git 安装和本地 FFmpeg 存储库。
3.1 Personal Git installation
将以下内容添加到您的〜/.gitconfig帮助git send-email
和git format-patch检测重命名：
[diff]
renames = copy
3.2 Repository configuration
为了git send-email自动将补丁发送到 ffmpeg-devel 邮件列表，请将以下节添加到/path/to/ffmpeg/repository/.git/config:
[sendemail]
to = ffmpeg-devel@ffmpeg.org
4 FFmpeg具体
4.1 Reverting broken commits
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 Pushing changes to remote trees
git push origin master --dry-run
将模拟将本地 master 分支推送到默认远程 ( origin )。并列出哪些分支和范围或提交将被推送。如果本地树和远程树不同步，Git 将阻止您推送更改。请参阅将源代码树更新到最新版本。
git remote add <name> <url>
将添加带有名称引用的附加远程，如果您想将本地分支推送到远程主机上进行审查，这会很有用。
git push <remote> <refspec>
将更改推送到<remote>存储库。省略<refspec>会git push更新所有与本地分支匹配的远程分支。
4.3 Finding a specific svn revision
从 1.7.1 版开始，Git 支持 '：/富' 基于正则表达式指定提交的语法。参见 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 "human@server.com"
生成密钥时，请确保指定的电子邮件与 git 中使用的电子邮件匹配，因为 github 等某些网站认为不匹配是声明此类提交未经验证的原因。生成密钥后，您可以将其添加到 MAINTAINER 文件并将其上传到密钥服务器。
6 预推清单
一旦您拥有了一组您认为已准备好推送的提交，请完成以下检查表以仔细检查所有内容是否按正确顺序排列。这份清单试图做到详尽无遗。如果您只是在评论中输入拼写错误，则某些步骤可能是不必要的。运用您的常识，但如果有疑问，请谨慎行事。
首先，确保您要推送的提交和分支与您想要推送的内容匹配，并且没有任何遗漏、无关或错误的内容。您可以通过运行 git push 命令来查看将推送的内容--试运行第一的。然后检查用 列出的提交
git log -p 1234567..987654。该git status命令可能有助于查找已忘记添加的本地更改。
接下来让代码通过我们的测试套件的完整运行。
-
make distclean -
/path/to/ffmpeg/configure -
make fate - 如果由于缺少样本而导致命运失败，请运行
make fate-rsync并重试
确保在推送之前检查所有更改，测试套件仅检查回归，并且仅在某种程度上进行检查。显然，它不会检查新添加的功能/代码是否正常工作，除非您为此添加了测试（推荐）。
另请注意，每个提交都应该通过测试套件，而不仅仅是一系列补丁的结果。
一旦一切通过，将更改推送到您的公共 ffmpeg 克隆并向 ffmpeg-devel 发布合并请求。您也可以直接推送它们，但不建议这样做。
7 服务器问题
如果您有 Git 服务器的技术问题， 请通过root@ffmpeg.org联系项目管理员。
本文档于2023 年 11 月 17 日使用makeinfo 生成。
由telepoint.bg提供的托管