Ubuntu set up Proxy

nano /etc/environment
 export http_proxy=http://127.0.0.1:8118
 export https_proxy=http://127.0.0.1:8118
 export no_proxy="127.0.0.1, localhost" 

save and go.

<转载>真正的敏捷工作流 —— GitHub flow

GitHub flow,顾名思义,就是 GitHub 所推崇的 Workflow。千万不要理解成 GitHub 上才能用的 Workflow

其官网的描述为:

GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.

从中我们可以得出的信息是 —— 这段描述完全就是废话 GitHub flow 具有很高的通用性。

为了更便于了解 GitHub flow 的内容,我们从流程图入手:

真正的敏捷工作流 —— GitHub flow

其中的主要流程为:

  • 新建分支(Create a branch);
  • 提交修改(Add commits);
  • 创建 PR(Open a Pull Request);
  • 代码评审(Discuss and review your code);
  • 部署(Deploy);
  • 合并(Merge);

细心的同学可能很快会发现,GitHub flow 最大的亮点在于部署(Deploy)发生在 合并(Merge)之前,这就是 GitHub flow 的核心,非阻塞式集成 —— 在产生任何副作用之前得知当前修改的所有集成效果,达到真正的持续集成。

GitHub flow 有什么优势?

GitHub flow 的核心优势在于其流程带来的自动化可能性,能够做到其它流程无法实现的检查过程,并极大简化开发团队的体力劳动,真正发挥自身的价值。

如何开始使用 GitHub flow?

使用 GitHub flow 的基本要求有:

  • 具备一个代码版本控制环境;
  • 具备一个持续集成环境;
  • (可选)具备 CI 环境的管理员权限;
  • 能够创建一个有权限访问 VCS 平台的机器人帐号;
  • 能够自由使用 VCS 平台的 WebHook API;
  • 能够自由使用 CI 平台的 Trigger API;
  • (可选)能够自由使用 CI 平台的状态查询 API;
  • 能够创建一个高可用的内部服务器用于机器人帐号的运行;
  • 能够决定开发团队的工作流程;
  • 能够投入成本改善基础设施;

遗憾的是,我至今没有过这种条件,如果你有能力去实践 GitHub flow,希望能够珍惜这次改善开发体验的机会,让更多人了解这种流程优化带来的巨大效率优势。

如果有任何具体的技术问题,也欢迎进一步的讨论。

写在最后

以我个人的体验,GitHub flow 是 世界上唯一的真理 真正能够拯救开发效率的敏捷实践,将开发人员真正从体力劳动中解放出来,从而能够专注于学习与思考。

如果你也觉得 GitHub flow 真正拯救了你的项目开发,不妨将它继续推广下去。

转自:https://www.infoq.cn/article/ICx4zr8mpIYO6kD9Qveb