为 TensorFlow 代码做贡献
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
无论您是添加损失函数、提高测试覆盖率还是为重大设计变更编写 RFC，本部分贡献者指南将帮助您快速入门。感谢您为改进 TensorFlow 所做的工作和给予的关注。
准备工作
在为 TensorFlow 项目贡献源代码之前，请查看该项目的 GitHub 仓库中的 CONTRIBUTING.md 文件。例如，请参阅核心 TensorFlow 仓库中的 CONTRIBUTING.md 文件。所有代码贡献者都需要签署贡献者许可协议 (CLA)。
为避免重复工作，在开始处理非普通功能之前，请查看当前或提议的 RFC 并与 TensorFlow 论坛上的开发者 (developers@tensorflow.org) 联系。在决定添加新功能时，我们是有选择性的，为项目做贡献和提供帮助的最佳方法是处理已知问题。
新贡献者的问题
新贡献者在搜索对 TensorFlow 代码库的首次贡献时应查找以下标签。我们强烈建议新贡献者先处理具有“good first issue”和“contributions welcome”标签的项目；这有助于贡献者熟悉贡献工作流程，并让核心开发者认识贡献者。
如果您有兴趣招募一个团队来帮助解决大规模问题或处理新特性，请给 developers@ 小组发送电子邮件，并查看我们当前的 RFC 列表。
代码审查
新功能、错误修复以及对代码库的任何其他更改都必须经过代码审查。
以拉取请求的形式审查贡献到项目的代码是 TensorFlow 开发的关键组成部分。我们鼓励任何人审查其他开发者提交的代码，尤其是在您可能会使用该功能的情况下。
在代码审查过程中，请牢记以下问题：
我们在 TensorFlow 中需要这个功能吗？它有可能被使用吗？作为 TensorFlow 用户，您是否喜欢此更改并打算使用它？此更改在 TensorFlow 的范围内吗？维护新功能的成本是否物有所值？
代码与 TensorFlow API 是否一致？公共函数、类和参数的命名是否合理，设计是否直观？
是否包括文档？所有公共函数、类、参数、返回类型和存储的特性是否都已根据 TensorFlow 约定命名并明确记录？TensorFlow 文档中是否尽可能地描述了新功能并通过示例加以说明？文档是否正确呈现？
代码是人类可读的吗？冗余度低吗？是否应改进变量名称以使其清晰或一致？是否应添加注释？是否应移除任何无用或多余的注释？
代码是否高效？能否轻松重写此代码以更高效地运行？
代码是否向后兼容先前版本的 TensorFlow？
新代码是否会添加与其他库的新依赖关系？
测试并提高测试覆盖率
高质量的单元测试是 TensorFlow 开发流程的基石。为此，我们使用 Docker 镜像。测试函数经过适当的命名，负责检查算法的有效性以及代码的不同选项。
所有新功能和错误修复都必须包括足够的测试覆盖率。我们也欢迎提供新测试用例或改进现有测试的贡献。如果您发现我们现有的测试不完整（即使当前尚未导致错误），请提交问题，并在可能的情况下提交拉取请求。
有关每个 TensorFlow 项目中测试过程的特定详细信息，请参阅 GitHub 上项目仓库中的 README.md 和 CONTRIBUTING.md 文件。
充分测试中需要特别关注的问题：
- 是否对每个公共函数和类都进行了测试？
- 是否测试了一组合理的参数、它们的值、值类型和组合？
- 测试是否验证了代码正确无误，以及它所执行的操作是否符合文档中所述的代码意图？
- 如果更改是错误修复，是否包括非回归测试 ？
- 测试是否通过持续集成构建？
- 测试是否覆盖代码的每一行？如果未覆盖，例外是否合理且明确？
如果发现任何问题，请考虑帮助贡献者了解这些问题并加以解决。
改善错误消息或日志
我们欢迎改善错误消息和日志记录的贡献。
贡献工作流
代码贡献（错误修复、新开发、测试改进）全部遵循以 GitHub 为中心的工作流。要参与 TensorFlow 开发，请建立一个 GitHub 帐号。然后：
将您计划处理的仓库分叉。转到项目仓库页面，然后使用 Fork 按钮。这将在您的用户名下创建一个仓库副本。（有关如何将仓库分叉的更多详细信息，请参阅此指南。）
将仓库克隆到本地系统。
$ git clone git@github.com:your-user-name/project-name.git
创建一个新分支来保存您的工作。
$ git checkout -b new-branch-name
处理新代码。编写并运行测试。
提交您的更改。
$ git add -A
$ git commit -m "commit message here"
将您的更改推送到 GitHub 仓库。
$ git push origin branch-name
打开一个拉取请求 (PR)。转到 GitHub 上的原始项目仓库。随后将显示一条有关您最近推送的分支的消息，询问您是否要打开拉取请求。按照提示进行操作，在仓库之间进行比较，然后提交 PR。这将向提交者发送一封电子邮件。您可能需要考虑将电子邮件发送到邮寄名单来提高关注度。（有关更多详细信息，请参阅关于 PR 的 GitHub 指南。）
维护者和其他贡献者将审查您的 PR。请参与对话，并尝试进行任何要求的更改。一旦 PR 获得批准，便会合并代码。
在处理下一个贡献之前，请确保您的本地仓库是最新的。
设置远程的上游仓库。（每个项目只需执行一次，不必每次都执行。）
$ git remote add upstream git@github.com:tensorflow/project-repo-name
切换到本地 master 分支。
$ git checkout master
从上游拉取更改。
$ git pull upstream master
将更改推送到您的 GitHub 帐号。（可选，但这是一个好的做法。）
$ git push origin master
如果您要开始新工作，请创建一个新分支。
$ git checkout -b branch-name
其他 git 和 GitHub 资源：
贡献者核对清单
- 阅读贡献准则。
- 阅读《行为准则》。
- 确保您已签署《贡献者许可协议》(CLA)。
- 检查您的更改与准则是否一致。
- 检查您的更改与 TensorFlow 编码风格是否一致。
- 运行单元测试。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2024-01-11。
[null,null,["最后更新时间 (UTC)：2024-01-11。"],[],[],null,["# Contribute to the TensorFlow code\n\nWhether you are adding a loss function, improving test coverage, or writing an\nRFC for a major design change, this portion of the contributor guide will help\nyou get started. Thank you for your work and interest in improving TensorFlow.\n\nBefore you get started\n----------------------\n\nBefore you contribute source code to a TensorFlow project, please review the\n`CONTRIBUTING.md` file in the GitHub repo of the project. For example, see the\n[CONTRIBUTING.md](https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md)\nfile in the core TensorFlow repo. All code contributors are required to sign a\n[Contributor License Agreement](https://cla.developers.google.com/clas) (CLA).\n\nTo avoid duplicating work, please review\n[current](https://github.com/tensorflow/community/tree/master/rfcs) or\n[proposed](https://github.com/tensorflow/community/labels/RFC%3A%20Proposed)\nRFCs and contact the developers on the TensorFlow forums\n([developers@tensorflow.org](https://groups.google.com/u/1/a/tensorflow.org/g/developers))\nbefore you start work on a non-trivial feature. We are somewhat selective when\ndeciding to add new functionality, and the best way to contribute and help the\nproject is to work on known issues.\n\nIssues for new contributors\n---------------------------\n\nNew contributors should look for the following tags when searching for a first\ncontribution to the TensorFlow code base. We strongly recommend that new\ncontributors tackle \"good first issue\" and \"contributions welcome\" projects\nfirst; this helps the contributor become familiar with the contribution\nworkflow, and for the core devs to become acquainted with the contributor.\n\n- [good first issue](https://github.com/tensorflow/tensorflow/labels/good%20first%20issue)\n- [contributions welcome](https://github.com/tensorflow/tensorflow/labels/stat%3Acontributions%20welcome)\n\nIf you are interested in recruiting a team to help tackle a large-scale problem\nor a new feature, please email the\n[developers@ group](https://groups.google.com/a/tensorflow.org/g/developers)\nand review our current list of RFCs.\n\nCode review\n-----------\n\nNew features, bug fixes, and any other changes to the code base are subject to\ncode review.\n\nReviewing code contributed to the project as pull requests is a crucial\ncomponent of TensorFlow development. We encourage anyone to start reviewing code\nsubmitted by other developers, especially if the feature is something that you\nare likely to use.\n\nHere are some questions to keep in mind during the code review process:\n\n- *Do we want this in TensorFlow?* Is it likely to be used? Do you, as a TensorFlow user, like the change and intend to use it? Is this change in the scope of TensorFlow? Will the cost of maintaining a new feature be worth its benefits?\n- *Is the code consistent with the TensorFlow API?* Are public functions, classes, and parameters well-named and intuitively designed?\n- *Does it include documentation?* Are all public functions, classes, parameters, return types, and stored attributes named according to TensorFlow conventions and clearly documented? Is new functionality described in TensorFlow's documentation and illustrated with examples, whenever possible? Does the documentation render properly?\n\n- *Is the code human-readable?* Is it low on redundancy? Should variable names be improved for clarity or consistency? Should comments be added? Should any comments be removed as unhelpful or extraneous?\n\n- *Is the code efficient?* Could it be rewritten easily to run more efficiently?\n\n- Is the code *backwards compatible* with previous versions of TensorFlow?\n\n- Will the new code add *new dependencies* on other libraries?\n\nTest and improve test coverage\n------------------------------\n\nHigh-quality unit testing is a corner-stone of the TensorFlow development\nprocess. For this purpose, we use Docker images. The test functions are\nappropriately named, and are responsible for checking the validity of algorithms\nas well as different options of the code.\n\nAll new features and bug fixes *must* include adequate test coverage. We also\nwelcome contributions of new test cases or improvements to existing tests. If\nyou discover that our existing tests are not complete --- even if that is not\ncurrently causing a bug --- please file an issue and, if possible, a pull request.\n\nFor the specific details of testing procedures in each TensorFlow project, see\nthe `README.md` and `CONTRIBUTING.md` files in the project repo on GitHub.\n\nOf particular concerns in *adequate testing*:\n\n- Is *every public function and class* tested?\n- Are a *reasonable set of parameters*, their values, value types, and combinations tested?\n- Do the tests validate that the *code is correct* , and that it is *doing what\n the documentation says* the code is intended to do?\n- If the change is a bug fix, is a *non-regression test* included?\n- Do the tests *pass the continuous integration* build?\n- Do the tests *cover every line of code?* If not, are the exceptions reasonable and explicit?\n\nIf you find any problems, please consider helping the contributor understand\nthose problems and resolve them.\n\nImprove error messages or logs\n------------------------------\n\nWe welcome contributions that improve error messages and logging.\n\nContribution workflow\n---------------------\n\nCode contributions---bug fixes, new development, test improvement---all follow a\nGitHub-centered workflow. To participate in TensorFlow development, set up a\nGitHub account. Then:\n\n1. Fork the repo you plan to work on. Go to the project repo page and use the\n *Fork* button. This will create a copy of the repo, under your username.\n (For more details on how to fork a repository see\n [this guide](https://help.github.com/articles/fork-a-repo/).)\n\n2. Clone down the repo to your local system.\n\n `$ git clone git@github.com:your-user-name/project-name.git`\n3. Create a new branch to hold your work.\n\n `$ git checkout -b new-branch-name`\n4. Work on your new code. Write and run tests.\n\n5. Commit your changes.\n\n `$ git add -A`\n\n `$ git commit -m \"commit message here\"`\n6. Push your changes to your GitHub repo.\n\n `$ git push origin branch-name`\n7. Open a *Pull Request* (PR). Go to the original project repo on GitHub. There\n will be a message about your recently pushed branch, asking if you would\n like to open a pull request. Follow the prompts, *compare across\n repositories* , and submit the PR. This will send an email to the committers.\n You may want to consider sending an email to the mailing list for more\n visibility. (For more details, see the\n [GitHub guide on PRs](https://help.github.com/articles/creating-a-pull-request-from-a-fork).\n\n8. Maintainers and other contributors will *review your PR* . Please participate\n in the conversation, and try to *make any requested changes*. Once the PR is\n approved, the code will be merged.\n\n*Before working on your next contribution*, make sure your local repository is\nup to date.\n\n1. Set the upstream remote. (You only have to do this once per project, not\n every time.)\n\n `$ git remote add upstream git@github.com:tensorflow/project-repo-name`\n2. Switch to the local master branch.\n\n `$ git checkout master`\n3. Pull down the changes from upstream.\n\n `$ git pull upstream master`\n4. Push the changes to your GitHub account. (Optional, but a good practice.)\n\n `$ git push origin master`\n5. Create a new branch if you are starting new work.\n\n `$ git checkout -b branch-name`\n\nAdditional `git` and GitHub resources:\n\n- [Git documentation](https://git-scm.com/documentation)\n- [Git development workflow](https://docs.scipy.org/doc/numpy/dev/development_workflow.html)\n- [Resolving merge conflicts](https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/).\n\nContributor checklist\n---------------------\n\n- Read the [contributing guidelines](https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md).\n- Read the [Code of Conduct](https://github.com/tensorflow/tensorflow/blob/master/CODE_OF_CONDUCT.md).\n- Ensure you have signed the [Contributor License Agreement (CLA)](https://cla.developers.google.com/).\n- Check if your changes are consistent with the [guidelines](https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md#general-guidelines-and-philosophy-for-contribution).\n- Check if your changes are consistent with the [TensorFlow coding style](https://www.tensorflow.org/community/contribute/code_style).\n- [Run the unit tests](https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md#running-unit-tests)."]]
