服务器评测
我已经有十多年的软件开发经验，参与过很多开源项目和非开源项目。在这些项目中，我们使用GitHub作为代码协作平台。在这十年中，根据项目的不同，我经历了各种开发流程。在这篇文章里，我将分享我认为最为高效和实用的开发流程，它可以被用在各种软件开发项目上，开发出高质量的软件。
高质量的软件有很多属性，比如健壮性、可测性、弹性、模块化、可维护性、可用性、安全性、高性能、可伸缩性等，还有其他很多属性视具体的项目而定。本文主要关注以下几点：
- 良好的文档：README、文档页面、变更日志。
- 良好的编码规范。
- 版本管理。
- 自动化测试：不需要太多，专注在功能性非回归测试就可以了。
- 开发者体验。
为了达成上述目标，我建议使用开源工具来协助和自动化大部分任务。如果你在开发开源项目，可以将代码托管在GitHub上。Git和GitHub已经彻底改变了开源项目的开发方式，Git成为版本管理事实上的标准，而GitHub成为代码协作的主要平台。
GitHub官方建议的开发流程叫作github flow，官网上提供了详细的文档https://guides.github.com/introduction/flow。大部分开源项目都遵循这一流程，然后加入一些细微的调整。
GitHub工作流非常灵活，它没有规定如何发布版本和记录变更，没有规定如何合并PR（拉取请求），没有规定使用哪一种工具，没有规定代码提交标准，没有规定如何进行代码评审，一切都取决于开发者自己。不同的团队有不同的需求，所以并不存在标准的解决方案。
以下是根据我的经验总结出来的清单。我主要专注于JavaScript开发，所以我提到的很多工具都是JavaScript生态系统的一部分，不过同样的原则也适用于其他编程语言。
1.通过GitHub的项目功能给问题安排优先级和跟踪进度
2016年9月，GitHub引入了项目功能，让开发者可以创建看板风格的面板，用于管理、组织和跟踪工作内容。如果你在使用GitHub，我强烈建议使用这一个功能。更多的细节可以参看https://help.github.com/articles/tracking-the-progress-of-your-work-with-project-boards。
2.使用标签给问题分类
GitHub提供了非常好用的过滤功能。如果你在开发开源项目，一定希望有人参与到你的项目里来，并为他们提供良好的开发体验。通过使用标签给问题分类，开发者可以更方便地查看问题列表，从而节省时间。
3.使用GitHub模板
使用问题模板和PR模板将给你带来很大好处，让开发者在提交bug和特性请求时使用标准模板可以让你获得足够的信息，以便在后续修复bug或开发新特性。
提交bug的通用指南
在提交bug之前确保已完成以下两个步骤：
- 确保你运行的是最新版本的代码。
- 通过搜索功能确保同样的bug之前没有被提交过。
bug报告应该包含如下信息：
- 概要：简单的问题描述。
- 重现步骤：你是如何发现这个bug的？如何重现？
- 预期行为：预期行为应该是怎样的？
- 实际行为：实际行为是怎样的？
- 引用：相关ticket或信息来源的链接。
- 如果可能，添加一些包含可视化元素的附件文档，比如截屏、视频或gif图片。
PR的通用指南
- 确保不存在要解决同样问题的PR。
- 通过问题跟踪器查找相关的问题。
- 讨论需要作出哪些变更。
- 让别人知道你在解决这个问题。
- 在branch上开发，而不是master。
- 提供有意义的PR描述。
- 遵循项目的提交规范。
- 写好你的PR描述。
- 在描述中加上问题链接。
4.使用命令行
控制台是我们的好朋友。从我的经验来看，在开发开源项目时，通过命令行来操作GitHub是最高效的一种方式。虽然有很多很好的GUI，但都没有命令行那么灵活。还有一些非常好用的命令行工具，也只有使用这些工具才能让开发者如虎添翼：
- hub对git命令进行了封装，不管你是一个初学者还是一个有经验的老手，hub都可以帮到你。可以用它拉取代码库、浏览项目页面、创建分支，甚至是提交PR，这些操作都可以在命令行上完成。项目地址https://hub.github.com。
- tj/git-extras是一组git工具，可用于查看代码库概要、更新变更日志、查看贡献者提交百分比等。项目地址https://github.com/tj/git-extras。
5.遵循严格的提交规范
定义清晰的提交规范，并严格遵循，以下是一些通用指南：
- 每一次修复作为单独的变更来提交。
- 提供有意义的提交信息。
- 在提交信息的第一行提供简短的描述（50到100个字符）。如果不明白为什么要这样做，看看gitk或git log –oneline命令的输出就知道了。
- 在消息体中包含问题的链接。
6.定义编码规范并配置预提交钩子
定义编码规范，并通过预提交钩子来强制执行这些规范，这样非常有助于写出具有可维护性的代码。只要遵循这些规范，不管是谁写的代码，它们看起来都具备了同样的风格，其他人在接手或维护这些代码时会更加省事。
我推荐使用Prettier和StandardJS，不过还有很多其他的选择，具体根据自己的情况而定。
typicode/husky是一个很好的预提交钩子配置工具，项目地址https://github.com/typicode/husky。
7.为PR配置自动化测试
对PR进行自动化功能测试、安全检查和代码风格检查是非常有必要的，但不应该通过手动的方式做。每当有PR提交时，持续集成服务器（如TravisCI）可以在相应的branch上自动执行测试，这样可以防止开发者将未通过测试的PR提交到GitHub上。如果测试失败，GitHub会在PR中显示一条消息，让提交者尽快修复问题。
TravisCI文档https://docs.travis-ci.com/user/pull-requests。
8.保护好master，进行代码评审
GitHub为保护master提供了可能性，避免代码直接提交到master上，或对其进行rebase。当多人合作开发一个项目时，这点是非常重要的。另外，在将代码合并到master时，将代码评审作为必要的步骤。这个可以在每个代码库的settings页面进行配置。
保护好master，并强制执行代码评审，你就可以高枕无忧，无需担心糟糕的代码会被合并到master上，也不会有人提交未经评审的代码。
9.squash你的PR
关于该使用merge、squash还是rebase存在很大的争议，不过我认为最好是使用squash，因为：
- 不是所有的开发者都知道如何进行rebase，大部分开发者都只是简单地在他们的变更之上合并master。squash避免了无用的合并信息和往git日志中添加噪音。
- 不是所有的开发者都会遵循提交规范，squash有助于控制合并到master上的提交信息。
为了更好地进行squash，每个PR都应该属于某个特定的功能、bug修复或任务。
10.版本语义、标签、发布和自动化变更日志
版本管理对于软件来说非常重要，特别是在开源软件中，有很多其他项目可能会依赖你的项目。有了版本语义，我们通过版本号就可以知道某个版本是否包含了突破性变更，或者版本是否包含了新特性或bug修复。
版本格式通常是这样的MAJOR.MINOR.PATCH：
- 在做出不兼容的API变更时，增大MAJOR。
- 增加向后兼容的新特性时，增大MINOR。
- 进行向后兼容的bug修复时，增大PATCH。
我们还可以对这个格式进行扩展，加入额外的标签，作为预发布版本和构建元数据。
Conventional Commits规范（https://conventionalcommits.org）建议基于提交消息引入一种轻量级的规范，与SemVer一起使用，让开发者在提交消息中提供与功能、bug修复和突破性变更相关的描述。
TravisCI有助于自动化这一过程https://docs.travis-ci.com/user/deployment/releases。
11.使用标签钩子进行自动化部署
GitFlow建议使用release分支进行发布，但这不是必需的。我们可以通过git标签获取要部署的文件，TravisCI的文档（https://docs.travis-ci.com/user/deployment/heroku）介绍了如何将git标签部署到heroku上。其实很简单，只需要将标签属性设置为true就可以了。其他CI服务器的配置也类似。
我们可以在开发环境配置钩子，用于部署最新的master代码。我们也可以为每个PR创建临时的测试环境，不过这样做非常复杂，所以不一定要这么做。
12.建立GitHub流式通道
这是一种非常方便的跟踪GitHub活动的方式，可以通过这种方式与其他人进行协作沟通。每个GitHub聊天室都会有通知流，GitHub在2013年为此发明了一个新术语，叫作ChatOps。
13.自动化依赖更新
保持依赖更新是一项非常耗时的重复性工作，所以可以将它自动化。所幸的是，有很多工具可用于保持依赖更新，它们会基于项目的最新版本创建PR，然后自动执行非回归测试，如果测试通过，那么在合并PR后这些代码依然能够正常运行。不过如果有主版本变化，需要进行双重检查。
可以参考这两个工具：https://greenkeeper.io和https://david-dm.org。
14.使用扩展来提升GitHub的UI体验
开源社区开发了很多非常有用的扩展，可用于提升GitHub的使用体验。可以通过https://github.com/showcases/GitHub-browser-extensions查看这些扩展。
15.持续学习和改进
GitHub和开源软件的开发实践一直在演化，我们需要关注GitHub的发布公告，并遵循开源社区的标准，跟上时代的发展步伐。
查看英文原文：https://gaboesquivel.com/blog/2018/15-recommendations-to-enhance-your-github-flow
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx
本文永久更新链接地址：https://www.linuxidc.com/Linux/2018-07/153032.htm
