版权所有（C）2006-2024 Free Software Foundation，Inc。有关许可条件，请参见文件末尾。*开发人员如何为GNU Emacs做出贡献以下是软件开发人员如何为Emacs做出贡献。（非开发商：参见https://www.gnu.org/software/emacs/manual/html_node/emacs/Contribution.html或运行shell命令“info”（emacs）Contributing“”。）**Emacs存储库Emacs开发使用Savannah上的Git作为其主存储库。要为Emacs开发配置Git，可以运行以下命令：git-config--全局用户名'Your name'git配置--全局用户电子邮件'your.name@example.com'git-config--全局转移.fsckObjects true然后，以下shell命令从头开始构建和运行Emacs：git克隆git://git.sv.gnu.org/emacs.gitcd电子邮件./autogen.sh./配置制作源代码/emacs有关更多详细信息，请参阅https://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs网站和https://www.emacswiki.org/emacs/GitForEmacsDevs网站或查看文件admin/notes/git-workflow。**参与发展关于Emacs开发的讨论发生在emacs-devel@gnu.org。您可以订阅电子邮件-devel@gnu.org邮件列表。如果你只想收到重要的邮件（比如功能冻结），选择仅接收“电子邮件通知”主题（尽管到目前为止，该功能还没有得到很好或一致的使用）。请参见https://lists.gnu.org/mailman/listinfo/emacs-devel用于邮件列表说明和档案。您可以在自己的存储库副本，并讨论邮件列表。Emacs的频繁贡献者可以请求写访问权限那里。错误报告和修复、功能请求和补丁/实现应发送至bug-gnu-emacs@gnu.org，错误/功能列表。这个耦合到https://debbugs.gnu.org跟踪器。最好使用命令“M-x report emacs bug RET”向跟踪器报告问题（如下所述）。准备接收以下方面的评论和请求提交后，您的修补程序发生了更改。萨凡纳信息页面https://savannah.gnu.org/mail/？group=emacs描述如何订阅邮件列表或查看列表档案。要通过电子邮件发送补丁，可以使用类似“git format-patch-1”的shell命令创建一个文件，然后将该文件附加到您的电子邮件中。这个很好打包修补程序的提交消息和更改，并确保各种邮件在传输过程中不会占用格式和空白代理人。如果只发送一个这样的补丁而不附加备注，那么也可以使用如下命令git发送电子邮件--至=bug-gnu-emacs@gnu.org0001-说明.批次然而，我们更喜欢带附件的“git-format-patch”方法，因为这样可以以正确且易于识别的格式提供补丁更可靠，使应用补丁的工作更容易、更少容易出错。它还允许发送作者是某人的补丁而不是电子邮件发件人。一旦您提交的累计数量超过十几个左右非平凡的改变，我们需要你分配给FSF您的贡献的版权。（查看有多少行非隐私更改，仅统计中添加和修改的行补丁代码。如果添加或更改行包括至少一个标识符、字符串或实质性注释。）在大多数情况下，要开始分配过程，您应该下载https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future并将填写好的信息返回到顶部的地址。（还有其他赋值选项，但使用频率低得多。）如果您对作业过程有疑问，可以向表格上列出的地址，和/或emacs-devel@gnu.org。**问题跟踪器（也称为“错误跟踪器”）Emacs问题跟踪程序位于https://debbugs.gnu.org允许您查看bug报告并搜索数据库中与多个标准匹配的错误。发布到的消息bug-gnu-emacs@gnu.org邮件列表，已提及由跟踪器用相应的错误/问题。如果发送给bug跟踪器的消息中包含补丁，请在消息主题中包含字符串“[PATCH]”，以便让bug跟踪器正确标记bug。GNU ELPA有一个“debbugs”包，允许访问跟踪器Emacs数据库。臭虫需要定期关注。大量积压的错误是让开发人员沮丧的是，忽视bug的文化对期望软件正常工作的用户有害。臭虫一定是定期观察并采取行动。并非所有的bug都是关键的，但至少，需要定期重新检查每个bug以确保它仍然可以复制。检查旧的或新的错误并采取行动的过程是称为bug分类。文件中描述了此过程admin/notes/bug-triage。**记录您的更改任何对最终用户重要的更改都应该在etc/NEWS中有一个条目。试着用一句话来概括每个新闻条目只需一行——这将允许阅读大纲中的新闻模式。文档字符串应与代码一起更新。新的defcustom和defface应始终具有“：version”标记说明它们将出现的第一个Emacs版本。同样地使用值已更改的defcustom或defface，更新它们“：version”标记。想想您的更改是否需要更新手册。如果你如果不知道，请在NEWS条目前用“---”标记。如果你知道所有必要的文档更新都已经完成了作为您或其他人更改的一部分，请用“+++”标记条目。否则，不要对其进行标记。如果您的更改需要更新手册以记录新的函数/命令/变量/面，然后使用适当的Texinfo命令对其进行索引；例如，使用@vindex作为变量和@函数/命令的findex。有关预定义索引的完整列表，请参阅https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Prefined-Indices.html或运行shell命令“info”（texinfo）预定义索引“”。我们更喜欢文档字符串和手册中的美式英语。这包括拼写（例如，“behavior”，而不是“behabior”）和句子之间留两个空格的习惯。有关Emacs文档样式的更多具体提示，请参阅https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html在提交修补程序之前，使用“checkdoc”检查文档错误。**测试您的更改请在提交更改或将更改发送到列表。如果可能，添加新测试以及任何错误修复或新测试您提交的功能（当然，有些更改并不容易测试）。Emacs使用ERT（Emacs Lisp回归测试）进行测试。请参见https://www.gnu.org/software/emacs/manual/html_node/ert/或运行“info”（ert）“”以获取有关写入和运行的详细信息测验。如果测试持续时间超过几秒钟，请在其带有“：tags”（：expensive-test）的“ert-deftest”定义。要在整个Emacs树上运行测试，请从顶级目录。大多数测试都在“test/”目录中。发件人“test/”目录，运行“make“为运行测试.el（c）。有关更多信息，请参阅“测试/自述”。如果您正在进行涉及Emacs构建系统的更改，请测试“树外”构建，即：mkdir emacs内部版本cd emac构建../电子邮件路径-源/配置制作**提交消息通常，您提交的变更集应该包含对更改其提交消息，并且不应接触存储库的ChangeLog文件。以下是提交消息示例（缩进）：停用移动区域不要无声地扩展未高亮显示的区域；这可能会在换班后发生（错误号19003）。*doc/emacs/mark.texi（Shift Selection）：记录更改。*lisp/window.el（手动选择窗口）：*src/frame.c（Fhandle_switch_frame，Fselected_frame）：停用标记。有时，会收集提交消息并将其添加到生成的ChangeLog文件，可以在其中进行更正。这样可以节省时间为了第一次就把它们做好，下面是一些指导原则格式化它们：-从一个未凹陷的摘要行开始解释更改；此行不要以句点结尾。如果可能，尽量保持摘要行不超过50个字符；这是为了兼容性使用某些Git命令以宽度约束打印该行上下文。如果摘要行以分号和空格“；”开头，则提交消息将被跳过，并且不会添加到生成的ChangeLog文件。将此选项用于不需要在ChangeLog文件中提到，例如etc/NEWS中的更改、输入错误修复等。-摘要行之后应该有一个空行。-未登录的ChangeLog条目通常排在后面。然而，如果无法在简要摘要行中正确总结提交，你可以在空行之后和单个ChangeLog条目），进一步描述提交。-ChangeLog条目中的行最好不超过63字符，并且不得超过78个字符，除非它们由一个最多140个字符的单词；这个78/140的极限是由提交挂钩强制执行。-如果只更改了一个文件，则摘要行可以是正常的ChangeLog条目的第一行（以星号开头）。然后除了摘要行。-如果提交有多个作者，则提交消息应包含单独的行以提及其他作者，如以下内容：合著者：Joe Schmoe-如果承诺是一个小小的改变，不受版权文书的约束，提交消息应包含一个单独的行，如下所示：版权所有-免除：是-如果提交消息与debbugs数据库中的错误号NNNNN。此字符串通常括号中，如“（Bug#19003）”。-引用URL时，如果两者都可以，则首选https:而不是http:。在特别是，gnu.org和fsf.org的URL应该以“https:”开头。-提交消息应仅包含可打印的UTF-8字符。然而，我们要求仅当严格要求时才使用非ASCII字符必要的，不仅仅是为了美观。-提交消息不应包含“Signed-off-by:”行用于其他一些项目。-忽略提交消息中以“；”开头的任何行来自生成的ChangeLog。-最好在评论中解释设计选择的基本原理在源代码中。然而，有时描述一下变更的理由；可以在提交消息中完成在摘要行和以下ChangeLog条目之间。-Emacs遵循ChangeLog条目的GNU编码标准：请参阅https://www.gnu.org/prep/standards/html_node/Change-Logs.html或运行“info”（标准）更改日志“”。一个例外是提交仍然有时引用“like this”（就像过去的标准一样推荐），而不是“喜欢这个”或“喜欢这样”（就像他们现在做的那样），作为“…”在Emacs的其他地方被广泛使用。-GNU编码标准中的一些注释规则也适用到ChangeLog条目：它们必须是英文的，并且是完整的句子以大写字母开头，以句点结尾（除了摘要行不应以句点结尾）。请参见https://www.gnu.org/prep/standards/html_node/Comments.html或运行“info”（标准）Comments“”。美式英语优先在Emacs中；包括拼写和在句子。ChangeLog条目被无限期保留，并且具有未来被阅读的可能性比较大，所以最好是他们的表现很好。-使用现在时态；描述“变化做了什么”，而不是“什么”改变做到了”。-具有相同内容的多个条目的首选格式：*lisp/menu-bar.el（剪贴板-猛拉，剪贴板-杀死-环保存）（剪贴板-kill-区域）：*lisp/eshell/esh-io.el（eshell-虚拟目标）（eshell-clipboard-append）：将选项gui-select-enable-clipboard替换为选择-电动滑板；更名为2014年10月。（错误号25145）（而不是任何涉及“同上”之类的内容。）-没有标准或推荐的方法来识别ChangeLog条目。使用Git SHA1值限制了对Git的引用，如果使用Emacs，则会变得不那么有用切换到不同的VCS。因此，我们建议不要只这样做。识别修订的一种方法是引用其摘要行。在摘要前加上提交日期可以提供有用的上下文（使用“git show-s”--漂亮=格式：%cd\“%s\”“--日期=短HASH”生产该产品）。通常，“我以前的承诺”就足够了。-无需提及NEWS和MAINTAINERS等文件，或以指示文件的重新生成，如“lib/gnulib.mk”ChangeLog条目。“没有必要”意味着你不必这样做，但是如果你愿意，你可以。**生成ChangeLog条目-如果使用Emacs VC，可以使用“C-C C-w”生成格式化的提交的diff中的空白ChangeLog条目，然后使用“M-q”组合并填充。请参阅“info”（emacs）Log Buffer“”。-如果使用第三方软件包Magit，可以使用来自提交消息缓冲区的“magit-generate-changelog”。另请参阅“magit-add-change-log-entry”和“magit-add-change-log-entry-other-window”。-或者，您可以对ChangeLog文件使用Emacs函数；看见https://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html或运行“info”（emacs）Change Log Commands“”。要使用Emacs VC格式化ChangeLog条目，请创建一个顶级手动更改日志文件，并像往常一样用“C-x 4 a”更新它。做不在git下注册ChangeLog文件；相反，使用“C-C C-a”将其内容插入您的vc-log缓冲区。或者如果“log-edit-hook”包括“log-eedit-insert-changelog”（它确实如此默认情况下），将自动为您填写。-您可以使用VC-dwim命令来维护提交，而不是Emacs VC信息。创建源目录时，运行shell命令“git-changelog-symlink-init”创建符号链接将日志更改为.git/c/ChangeLog。通过符号链接编辑此ChangeLog使用Emacs命令，如“C-x 4 a”，并使用shell命令“vc dwim--commit”。键入“vc-dwim--help”了解更多信息。**提交更改。当您提交更改时，Git会调用几个脚本来测试提交以确保有效性，如果某些测试失败。这些脚本位于存储库的顶级目录，它们执行以下操作测验：-提交日志消息不能为空；-提交日志消息的第一行不是以开头的空白字符；-提交日志消息的第二行必须为空；-提交日志消息应仅包含有效的可打印ASCII和UTF-8字符；-提交日志消息行必须少于79个字符，除非一行由一个长单词组成，在这种情况下，该单词可以长度不超过140个字符；-提交日志中不应该有任何“Signed-off-by:”标记消息和“git提交”不应使用“-s”选项调用（自动添加“Signed-off-by:”）；-如果提交添加了新文件，则文件名不能以开头“-”，必须由ASCII字母、数字和设置[-+./_]；-这些更改不包括未解决的合并冲突标记；-这些更改不会引入空白错误：尾随空白，仅包含空白字符且缩进的行SPC字符后面紧跟TAB的行线条的初始缩进**由他人提交更改如果提交其他人编写的更改，请以他们的名义提交，不是你的。您可以使用“git commit--author=“author””指定更改的作者。使用Emacs VC提交时，作者可以通过添加“Author:Author”头在日志编辑缓冲区中指定行（设置“日志编辑设置添加作者”非nil以具有此标题行自动添加）。请注意上一节仍然适用，因此您必须更正他们在其他人提交的更改中发现的问题。**分支机构未来的开发通常在主分支上进行。有时，以前在其他分支上开发了专门的功能可能被合并到主服务器。发布分支已命名“emacs-NN”，其中NN是主要版本号，主要是用于更具保护性的更改，如错误修复。通常，集体发展在主分支上是积极的，可能在当前发布分支。定期地，当前发布分支使用中描述的gitmerge函数合并到主节点admin/notes/git-workflow。如果您正在修复当前版本中存在的错误，您应该通常将其提交给发布分支；它将合并到之后通过gitmerge函数进行主分支。然而，当发布分支适用于Emacs版本NN.2及更高版本，或适用于Emacs版本NN.1正处于预测试的最后阶段，该分支被视为处于功能冻结状态：仅修复错误“安全”或正在修复主要问题的应提交到发布分支，其余的应该提交给主分支。这是真的以避免破坏下一个Emacs版本的稳定性。如果你不确定对于发布分支来说，您的错误修复是否“安全”，请继续询问emacs级别的邮件列表。文档修复（在文档字符串、手册、新闻和注释）应始终转到发布分支，如果文档to be fixed存在，并且与发布分支代码库相关。文档修复始终被认为是“安全的”——即使是在发布分支时处于功能冻结状态，它仍然可以接收文档修复。然而，这规则仅限于解决文档中的实际问题；清理并且排除了文体上的变化。当您知道更改将很难合并到master（例如，因为master上的代码更改了很多），您可以将更改应用于master和branch。它还可以发生了一个从master到release的变化分支，因此不需要合并回去。在这些情况下，在发布分支提交消息中说不需要合并通过使用“Backport:”启动提交消息，将提交到主服务器。gitmerge函数将这些提交从合并到主节点中排除。无论如何，有些更改根本不应该合并到master中原因。这些应该标记为“不要merge to master”或任何与gitmerge-skip-regexp匹配的内容（请参见admin/gitmerge.el）。**Emacs中的一些包是外部维护的有时，作为GNU Emacs的一部分发布的包被维护为独立的项目，有自己的上游存储库和维护者集团、其自身的开发惯例等。上游项目的代码定期合并到Emacs中（具体时间和方式合并的发生取决于包）。因此，当您做出贡献时——例如修复错误或对其中一个外部维护的包，您有时需要在其上游处理该包来源。在“admin/MAINAINERS”中的“外部维护包”部分我们保留了一份此类包的列表。**GNU ELPA公司此存储库不包含Emacs Lisp包存档（elpa.gnu.org）。有关如何访问GNU elpa，请参阅admin/notes/elpa存储库。**了解Emacs内部理解Emacs内部的最好方法是阅读代码。一些源文件（如xdisp.c）包含大量注释，用于描述设计和实施。以下资源也可能有所帮助：https://www.gnu.org/software/emacs/manual/html/node/elisp/Tips.htmlhttps://www.gnu.org/software/emacs/manual/html_node/elisp/gnu-emacs-Internals.html或运行“info”（elisp）Tips“”或“info”（elisp）GNU Emacs Internal“”。文件etc/DEBUG描述了如何调试Emacs错误。***Emacs文件中的非ASCII字符如果在Emacs源文件中引入非ASCII字符，请使用UTF-8编码，除非它由于某些好的原因无法完成这项工作。尽管将“编码：”cookie添加到非ASCII源文件，UTF-8编码*.el中不需要cookie仅用于Emacs 24.5及更高版本的文件。***admin/目录中的有用文件查看“admin/notes/*”中的所有文件。具体请参见“admin/notes/newfile”和“admin/notes/repo”。文件admin/MAINAINERS记录了经常关注的领域Emacs贡献者。如果您正在其中一个文件中进行更改上面提到过，最好咨询一下对该文件感兴趣，和/或获得他/她的更改反馈。如果你经常投稿，并且有兴趣维护具体文件，请在该文件中记录这些兴趣，以便其他人可能会意识到这一点。***git与重命名Git不显式表示文件重命名；它使用百分比更改了启发式以推断文件已重命名。所以如果你是计划在重命名文件后对其进行大量更改（或将其移动到另一个目录），您应该：-创建要素分支。-提交重命名而不进行任何更改。-进行其他更改。-将要素分支合并到主分支，而不是挤压将提交合并为一个。此合并的提交消息应该总结重命名和所有更改。此文件是GNU Emacs的一部分。GNU Emacs是一个自由软件：你可以重新发布和/或修改它它根据由自由软件基金会，许可证版本3，或（由您选择）任何更高版本。GNU Emacs的发布是为了希望它会有用，但无任何保证；甚至没有适销性或特定用途的适用性。请参阅GNU通用公共许可证了解更多详细信息。您应该已经收到GNU通用公共许可证的副本以及GNU Emacs。如果没有，请参阅.局部变量：模式：轮廓段落分隔：“[]*$”编码：utf-8结束时间：