网站翻译由林建有提供支持
1 简介
本文档旨在为一组有用的 Git 命令提供一些快速参考。您应始终使用 Git 直接提供的广泛且详尽的文档:
git --help man git
显示可用的子命令,
git <command> --help man git-<command>
显示有关子命令 <command> 的信息。
其他信息可以在Git 参考网站上找到。
欲了解有关 Git 项目的更多信息,请访问Git 网站.
在遇到问题时请咨询这些资源,它们相当详尽。
接下来是对 Git 的基本介绍以及一些 FFmpeg 特定的指南,以便于对项目的贡献。
2 基本使用
2.1 获取 Git
您可以从以下网址获取 Githttp://git-scm.com/大多数发行版和操作系统都提供了一个相应的包。
2.2 克隆源代码树
git clone https://git.ffmpeg.org/ffmpeg.git <target>
这将在目录<target>.
git clone git@source.ffmpeg.org:ffmpeg <target>
将 FFmpeg 源代码放入目录<target>并允许您将更改推送回远程库。
git clone git@ffmpeg.org:ffmpeg-web <target>
这将在目录<target>中放入 FFmpeg 网站的源代码,并允许您将更改推送回远程库。 (请注意,gil是 GItoLite 的缩写,并不是git.)
的错别字。)如果您没有对 ffmpeg-web 库的写权限,可以在创建只读的 ffmpeg-web 克隆后生成补丁:
git clone git://ffmpeg.org/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 主树的顶部,这是必要的。如果存在合并提交,主树将拒绝推送。
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/.
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 my@email.invalid 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
如果第一行的摘要不足以说明,在消息正文中解释您为什么进行了更改, 多数情况下您进行了什么更改可以通过代码展示出来。 简单地说“Bug 修复”或“10l”是糟糕的。 请记住,不同技能水平的人可能会阅读您的代码并从中学习。 除非是上下文,日志信息中不要包含文件名,因为 Git 已提供此信息。
如果提交修复了一个已登记的问题,请在消息正文的单独一行中说明:Fix Trac ticket #42.
第一行将被用于git format-patch
.
中给补丁命名的git log --oneline
常见的第一行错误例子(如在
中看到的):开头缺少上下文;描述补丁之前的代码行为;行过长或换到第二行。
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 = ffmpeg-devel@ffmpeg.org
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 "human@server.com"
生成密钥时,请确保指定的电子邮件与 git 中使用的电子邮件匹配,因为某些网站(如 github)会因电子邮件不匹配而判定这些提交为未经验证的。 生成密钥后,您可以将其添加到 MAINTAINER 文件,并上传到密钥服务器。
6 推送前检查清单
一旦您有一组您认为已准备好推送的提交,请按照以下检查清单逐步检查确保一切都妥当。 本清单旨在尽可能详尽。如果您只是推送了评论中的拼写错误,某些步骤可能是多余的。 请依靠您的常识行事,但如果不确定,请宁可多做也不要少做。
首先,确保您即将推送的提交和分支
与您想推送的一致,且没有遗漏内容,也没有多余或错误内容。
可以通过运行 git push 命令并带有--dry-run来查看将被推送的内容。
然后检查通过以下命令列出的提交git log -p 1234567..987654
。命令git status
可能有助于查找遗漏的本地更改。
接下来让代码通过我们的测试套件进行一次完整运行。
-
make distclean
-
/path/to/ffmpeg/configure
-
make fate
- 如果 fate 因缺少示例而失败,可以运行
make fate-rsync
并重试
确保所有更改在推送前都已被检查。 测试套件只检查回归,而且仅在一定范围内检查显然。 它显然不会检查新添加的功能/代码的工作情况,除非您为其添加了测试(推荐这样做)。
另请注意,每个提交都应该通过测试套件,而不仅仅是多个补丁后的结果。
一旦一切都通过,将更改推送到您的公共 ffmpeg 克隆中并发布一个 合并请求到 ffmpeg-devel。您也可以直接推送,但不推荐这样做。
7 服务器问题
请联系项目管理员root@ffmpeg.org如果您在使用 Git 服务器时遇到技术问题。
本文档由以下工具生成makeinfo.
托管由以下公司提供telepoint.bg