构建工具（五）：CMake 入门——为什么你的项目需要一个 CMakeLists.txt
1、从 Makefile 到 CMake：为什么还要再学一个工具？ 前面几篇文章，我们一直在聊 Makefile。它够用了吗？ 如果你的项目只在 Linux 上用 gcc 编译，make 基本够用。但一旦你需要： 在 Windows 上用 Visual Studio 编译 在 macOS 上用 Xcode 编译 检测系统上有没有某个库...
墨影闲谈
一个开发出身的DevOps工程师 · 代码有理性，文章有温度
构建工具（四）：pkg-config——解决依赖地狱的那把钥匙
1、一个令人抓狂的场景 假设你要用 libcurl 写一个 HTTP 请求的程序。你知道代码怎么写： #include <curl/curl.h> // 用 curl_easy_* 系列函数发请求 但是编译的时候，问题来了——你不知道该加哪些参数。 头文件在哪？库文件在哪？libcurl 还可能依赖别的库，那些库又在哪？ 你试着...
构建工具（三）：静态库 vs 动态库——.a、.so、.dylib 到底有什么不同
1、从一段尴尬的经历说起 你一定遇到过这样的场景： 同事给了你一个编译好的程序，你兴冲冲地双击运行——弹出错误框：找不到 xxx.dll。 或者你在 Linux 下编译好了程序，拷贝到另一台机器上运行： ./myapp: error while loading shared libraries: libxxx.so.1: cannot open...
构建工具（二）：GCC 编译四阶段——你的 .c 文件到底经历了什么
1、一个看似简单的问题 每天你都在敲 gcc -o hello hello.c，回车，然后得到一个可执行文件。一切好像浑然天成。 但如果你打开那个可执行文件，会看到一堆乱码——它已经不是人能读懂的东西了。 所以 .c 文件变成 hello 的过程中，到底发生了什么？ 答案比你想象的要复杂：编译器不是一步到位的，它经历了四个阶段。
构建工具（一）：从手敲 gcc 到 Makefile——构建工具的第一次进化
1、你最早是怎么编译 C 程序的？ 回想一下，你第一次写 C 程序是什么场景？ // hello.c #include <stdio.h> int main() { printf("hello world\n"); return 0; } 然后打开终端，敲下： gcc -o hello hello.c ./hell...
Git 分支模型（四）：Trunk-Based Development
1、更极致的理念 前面介绍的三种模型，都允许特性分支存在一定时间。但有一派人认为：分支存在的时间越长，合并冲突的风险越大，集成反馈越慢。 这就是 Trunk-Based Development（TBD，主干开发） 的核心主张：所有开发者直接在一个主干分支（trunk，即 main）上提交，或使用极短命的分支（不超过一天）。 TBD 不是什么新概念...
Git 分支模型（三）：GitLab Flow
1、Git Flow 太重，GitHub Flow 太轻 前两篇分别介绍了 Git Flow 和 GitHub Flow。前者规则严谨但繁琐，后者极简但对多版本维护支持不足。有没有一个折中方案？ GitLab 团队也思考了这个问题。他们在实践中发现 GitHub Flow 的一个明显缺陷：当需要维护多个版本或需要环境隔离时，只有一个 main 分支...
Git 分支模型（二）：GitHub Flow
1、为什么需要更轻量的模型 上一篇介绍了 Git Flow，它虽然严谨，但流程繁琐。对于 Web 应用这种需要快速迭代、持续部署的项目来说，Git Flow 的 develop → release → main 流程太重了。 GitHub 作为全球最大的代码托管平台，他们的开发团队也面临这个问题。于是 GitHub Flow 应运而生——这是 Gi...
Git 分支模型（一）：Git Flow
1、什么是分支模型 在团队协作中，代码管理离不开分支。但分支怎么建、怎么合、什么时候发版，如果没有一套约定，很快就会乱成一团。分支模型就是团队对分支管理方式的一种约定——规定哪些分支是长期存在的、分支之间如何合并、发布流程怎么走。 Git 本身只是一个工具，它没有强制你必须怎么用。真正决定协作效率的，是团队选择的分支模型。 常见的分支模型有四种：...
Gradle增量构建和构建缓存优化
随着项目越来越大，Gradle 构建时间可能越来越长。掌握增量构建和缓存机制可以显著加速日常开发。