Chrome开发工具 对 Chrome 开发工具的贡献

kout my_branchgit rebase master解决任何冲突如果你结束了对你分支的很多版本的修订，复位可能是很混乱的，因为它适用于每个变化，所以你可能需要不停地解决冲突。你可以使用 git rebase -i master 来把不同分支合并，它会打开一个编辑器并且内容是多行 pick XXXX。除了第一条 pisk._to_squash 之外都要改动，使用 s 来代替 pick。git diff master确认是你要上传的补丁git CL 上传合并的工作流程相对来说工作量要小一些，但你最终会将历史版本合并。此外，你可能很难想象你所提交的代码/补丁最终会成为 master 分支中的一员。选择工作流 #2在 https://code.google.com/p/chromium/issues/list 上创建一个新的问题，或找到你想修复的问题。在你本地的 git checkout 为这个问题创建一个分支。就像像 [verbose-name]-[issue-number]。这使得你更容易找到问题出现在哪个分支中，反之亦然。给自己分配一个问题是很好的，把它标记为“开始”状态，这样别人就不会开始做同样的工作了。编码并测试该分支的内容。在那个分支提交变更。您可以把所有的提交合并为一个。这样在有需要的时候使用复位会更加容易。git cl upload。在提交中你需要填写描述以及问题编号，例如“BUG=231904”。稍后你将被要求提供补丁说明，这些说明会被添加到相同的代码问题中。请看 https://chromiumcodereview.appspot.com/14329024/ 上的 "Patch Set #1"，"PatchSet #2" 等等。在更新列表中添加评论，请他们再次审查。你应该从主档案中挑选审稿人，使用 git cl upload 建议审稿人。收到评论后，如果需要的话可以交流一下。如果从使用者哪里收到了 LGTM - 请按提交按钮。否则，在本地修改这一分支的评论，然后跳转到步骤 3。有时你的提交可能没有通过审查，这时候你可能想进行复位。但是有些审核人员不喜欢在审查期间复位，因为这使得整个审核过程更加麻烦了。在等待评论时，你可以切换到另一个分支，并且修复另一个“冻结”的问题，然后等待审查。 运行布局测试要建立一个可以运行的布局测试，先了解 https://codereview.chromium.org/ 上的 layout tests。根据你提交的补丁类型，可能会有些开发工具布局测试是你希望在提交前先运行一下的。 首先，使用 gclient 来运行 git。你可以遵循 Git 使用指南中的步骤来体验这个过程。总之，确保 depot_tools 在你的路径中。在你想存储 Chromium 源的目录中执行 fetch blink --nosvn=True（这将需要一些时间，你可以买点零食，或者在手心中画一个球）。 当你完成这一过程，你可以通过构建 shell 脚本来加快构建过程。 在 Mac 或 Linux 机上，你可以简单地执行： ninja -C out/Debug content_shell如果你有问题，这一步你可以看看为 Mac 的 clang 帮助和 Linux 指令。 这也将需要一些时间。一旦它完成，你可以从 blink/tools/run_layout_tests.sh. 目录中运行布局测试，这个过程中你的电脑可能会有点发热。如果你是在 Windows，用 .bat 代替 .sh。预期中可能会出现一些失败！（不幸）。一个好的方法是在你做出任何改变之前先运行它们，然后在你做出改变后再运行它们。你也可以把目录作为一个参数传递，这样你只需指明 LayoutTests/inspector 目录就可以运行。经常问问题结构是什么?DevTools前端和后端的核心/检验员使用线性协议（又名远程调试协议）互动。关于它有一些老的文件（2012）:https://www.webkit.org/blog/1875/announcing-remote-debugging-protocol-v1-0/ https://developer.chrome.com/devtools/docs/debugger-protocol 所有涉及本地的网页 DOM 和其他属性的代码都是原生的。对于和运行中页面的 js 有接触的代码是一定要进行控制的。当添加一个新的功能，它应该怎么实现？如果它取决于输出信息，你应该添加一个新的方法到协议中（protocol.json），例如到 DOM 代理。这将产生绑定到 inspectordomagent 接口的前端部分和相应的处理函数的 js。然后，你实现他们的后端部分，并呼吁从前端操作。