Code-Review

本文由 yanglbme 原创，首发于公众号“Doocs开源社区”，欢迎转载。选中多行代码添加 Comment一些朋友可能或多或少都会在 GitHub 参与一些项目的Code Review（以下都简称CR） 工作。以前的 GitHub，CR 体验并不好，你无法同时选中多行代码进行 comment。 然而很多时候，我们是需要针对一个代码块进行 comment 的，只能选中一行代码进行 comment 并不满足我们的需求。可能会有一些第三方工具提供相关的功能，但是仅仅一个 CR 的小需求，还有借助其他工具完成，确实是有点麻烦。 好消息就是，现在，没错，就是现在，GitHub 终于为我们已经提供了多行代码 comment 的相关功能。 举个栗子。 比如说，如果你想在第 3-8 行的代码块添加 comment，那么你只需要按住行号 3 后面的蓝色+按钮，往下拖拽到第 8 行，就能选中这个代码块了，之后进行 comment 就可以了，简直完美。 不止于 CR其实，GitHub 近一年已经推出了不少强大的功能或服务，包括： GitHub Actions GitHub Actions 可以为项目自动构建工作流，比如代码检查、自动化打包、自动化测试、发布版本等等，目前该功能处于 beta 测试阶段。 GitHub Package Registry GitHub Package Registry，也即是包管理服务，可以方便地伴随源代码发布公共或私有包。 官方是这样说的： With GitHub Package Registry you can safely publish and consume packages within your organization or with the entire world.目前 GitHub 包管理功能仍处于 beta 测试阶段，想优先体验的朋友，可以进行申请。 ...

1. Awesome-Go 项目参与过awesome-go项目的gopher都知道，每个MR都必须满足它以下的要求： Make sure that you've checked the boxes below before you submit PR: [ ] I have added my package in alphabetical order.[ ] I have an appropriate description with correct grammar.[ ] I know that this package was not listed before.[ ] I have added godoc link to the repo and to my pull request.[ ] I have added coverage service link to the repo and to my pull request.[ ] I have added goreportcard link to the repo and to my pull request.[ ] I have read Contribution guidelines, maintainers note and Quality standard.总结出来，就是两项关键质量指标： ...

工程代码质量，一个永恒的话题。好的质量的好处不言而喻，团队成员间除了保持统一的风格和较高的自我约束力之外，还需要一些工具来统计分析代码质量问题。 本文就是针对 OC 项目，提出的一个思路和实践步骤的记录，最后形成了一个可以直接用的脚本。如果觉得文章篇幅过长，则直接可以下载脚本 OCLint is a static code analysis tool for improving quality and reducing defects by inspecting C, C++ and Objective-C code and looking for potential problems ...从官方的解释来看，它通过检查 C、C++、Objective-C 代码来寻找潜在问题，来提高代码质量并减少缺陷的静态代码分析工具 OCLint 的下载和安装有3种方式安装，分别为 Homebrew、源代码编译安装、下载安装包安装。区别： 如果需要自定义 Lint 规则，则需要下载源码编译安装如果仅仅是使用自带的规则来 Lint，那么以上3种安装方式都可以1. Homebrew 安装在安装前，确保安装了 homebrew。步骤简单快捷 brew tap oclint/formulae brew install oclint2. 安装包安装进入 OCLint 在 Github 中的地址，选择 Release。选择最新版本的安装包（目前最新版本为：oclint-0.13.1-x86_64-darwin-17.4.0.tar.gz）解压下载文件。将文件存放到一个合适的位置。（比如我选择将这些需要的源代码存放到 Document 目录下）在终端编辑当前环境的配置文件，我使用的是 zsh，所以编辑 .zshrc 文件。(如果使用系统的终端则编辑 .bash_profile 文件) OCLint_PATH=/Users/liubinpeng/Desktop/oclint/build/oclint-releaseexport PATH=$OCLint_PATH/bin:$PATH将配置文件 source 一下。 source .zshrc // 如果你使用系统的终端则执行 soucer .bash_profile验证是否安装成功。在终端输入 oclint --version3. 源码编译安装homebrew 安装 CMake 和 Ninja 这2个编译工具 ...

github contributions一般而言，任何一个人的github主页都有一个这样的方格图；每一个小格代表了one day，不同的颜色深度，代表了不同的contributions次数，那么这个次数是怎么计算的呢？本文的翻译就是上图底部的蓝色链接中的Learn how we count contributions.译文正文为什么我的contributions没有在个人profile中体现出来？个人profile中的contributions绘图是用于记录个人对github所做的contributions记录，贡献按照协调世界时（UTC）而不是您当地的时区加上时间戳。只有在满足特定标准的情况下才会当做contributions计算；在某些情况下，我们可能需要重建您的contributions绘图才能显示你的contributions。没有被记录的contributionsIssues和pull requests如果Issues和pull requests只有是在独立仓库中操作的，才会显示在您的contributions绘图上，而对于fork的仓库无法被记录的。Commits如果Commits符合以下所有条件，则会在您的contributions绘图上显示：用于Commits的电子邮件地址与您的GitHub帐户相关联Commits是在独立的仓库中进行的，而不是forkCommits在一下条件下完成在仓库的默认分支（通常是master）在gh-pages分支中（对于具有Project Pages站点的仓库）此外，必须至少满足下列条件之一：你是该仓库的协作者，或者是这个仓库所属组织的一员；你已经fork了该工程你对这个仓库提过Issues或者pull requests你star加星过这个仓库，通常的一些没有被记录的原因要显示在您的contributions绘图上，共同提交的提交必须符合与一个作者的提交相同的标准。当合并pull requests并且Commit时，只有合并pull requests的用户和打开pull requests的用户才会收到贡献积分。拉取请求的任何其他贡献者都不会获得贡献积分。当重新提交Commit时，Commit的原始作者和重新提交的人，无论是在命令行还是在GitHub上，都会收到贡献信用。Commit是在不到24小时前完成在完成符合要求的Commit后，您可能需要等待最多24小时才能看到贡献出现在您的贡献图表上。您尚未将本地Git提交电子邮件添加到您的个人资料中必须使用已添加到您的GitHub个人资料中的电子邮件地址进行提交，以便显示在您的贡献图表上。您可以通过将.patch添加到提交URL的末尾来检查用于提交的电子邮件地址，例如：https://github.com/octocat/octocat.github.io/commit/67c0afc1da354d8571f51b6f0af8f2794117fd10.patchFrom 67c0afc1da354d8571f51b6f0af8f2794117fd10 Mon Sep 17 00:00:00 2001From: The Octocat <octocat@nowhere.com>Date: Sun, 27 Apr 2014 15:36:39 +0530Subject: [PATCH] updated index for better welcome message可以配合：查看email：git config –global user.email 设置email：git config –global user.email XXXX@gmail.com未在默认master或gh-pages分支中进行提交只有在默认分支（通常为master）或gh-pages分支（对于具有Project Pages站点的存储库）中进行提交时才会计算提交。提交共同作者无权访问存储库如果在共同作者无权访问的存储库中进行了提交，则该提交将不计入共同作者的贡献。提交是在一个fork分支中进行的用fork做的提交不会计入你的贡献。要使它们计数，您必须执行以下操作之一：打开pull requests以将更改合并到父存储库中。要分离fork并将其转换为GitHub上的独立存储库，请联系GitHub支持或GitHub Premium支持。如果fork具有自己的分支，请让支持知道分支是否应随存储库移动到新网络中或保留在当前网络中。Commit是在合并和压缩的pull requests中完成的合并和压缩的pull requests中的Commit将不计入您的贡献。只有合并pull requests的用户和打开pull requests的用户才会收到贡献积分。拉取请求的任何其他贡献者都不会获得贡献积分。