nano ~/.bashrc
add the alias below: alias proxy=" export http_proxy=http://127.0.0.1:12333; export https_proxy=http://127.0.0.1:12333;" alias unproxy=" unset http_proxy; unset https_proxy;"
save and go.
交流を、より自然に Oops, not AI, but HI (human massive intelligence)
nano ~/.bashrc
add the alias below: alias proxy=" export http_proxy=http://127.0.0.1:12333; export https_proxy=http://127.0.0.1:12333;" alias unproxy=" unset http_proxy; unset https_proxy;"
save and go.
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 最大的亮点在于部署(Deploy)发生在 合并(Merge)之前,这就是 GitHub flow 的核心,非阻塞式集成 —— 在产生任何副作用之前得知当前修改的所有集成效果,达到真正的持续集成。
GitHub flow 的核心优势在于其流程带来的自动化可能性,能够做到其它流程无法实现的检查过程,并极大简化开发团队的体力劳动,真正发挥自身的价值。
使用 GitHub flow 的基本要求有:
遗憾的是,我至今没有过这种条件,如果你有能力去实践 GitHub flow,希望能够珍惜这次改善开发体验的机会,让更多人了解这种流程优化带来的巨大效率优势。
如果有任何具体的技术问题,也欢迎进一步的讨论。
以我个人的体验,GitHub flow 是 世界上唯一的真理 真正能够拯救开发效率的敏捷实践,将开发人员真正从体力劳动中解放出来,从而能够专注于学习与思考。
如果你也觉得 GitHub flow 真正拯救了你的项目开发,不妨将它继续推广下去。