Set up trunk-based branching strategy — lab audio overview

Host: Welcome back. You're in DevOps Foundations for GenAI Engineers — a course about the operational discipline that sits underneath every real AI system. The plumbing, the guardrails, the workflows. This chapter is all about Git workflows for AI teams. Git, if you haven't heard the term spoken out loud much, is the version control system that tracks every change to your code — think of it as a time machine for your project. And today we're focused on how AI teams should actually use it. Expert: Here's the scenario to hold in your head. Picture a mid-sized company, maybe fifty engineers, that's rolling out a customer support assistant powered by a large language model. They've got prompt templates — those are the instructions they send to the model. They've got model configuration files — settings like temperature and token limits. They've got evaluation datasets — test cases used to measure whether the model is getting better or worse. And they've got deployment manifests — files that describe how the system runs on their servers. Now, three engineers start making changes in parallel. One tweaks a prompt. Another updates a model setting. A third changes an evaluation test. Without a clear workflow, their changes collide. Someone's prompt improvement gets silently overwritten. The evaluation scores look weird and nobody knows why. A week of work evaporates. That's the failure mode this chapter prevents. And the specific strategy you'll set up today is the foundation everything else sits on. Host: Okay, so this is exercise one of three. This is your starting point — no prior code to build on. So what exactly are we going to build, and what's the big idea behind it? Expert: You're going to build a small Python tool — a setup utility — that takes an empty folder and turns it into a properly organized AI project. It creates the standard folders an AI team needs: one for prompts, one for model configurations, one for evaluation datasets, and one for deployment files. It drops in starter templates so the team isn't staring at empty directories. And it configures the version control settings the right way from day one. Now the key idea — the "aha" — is something called trunk-based development. Let me explain it plainly. Imagine a tree. The trunk is the main line of the project — the single source of truth. In trunk-based development, everyone on the team works off that trunk, and everyone merges their changes back into it frequently. Usually within a day. Short-lived side branches, quick integration, always close to the latest version. Compare that to the alternative, where teams maintain long-running parallel branches that drift apart for weeks, and then someone has to painfully stitch them back together. For AI teams, trunk-based is especially valuable because prompts and model configs change constantly, and you want everyone testing against the same recent version. Your tool enforces this pattern from the first commit — it sets up the repository so that pulling in other people's changes happens smoothly, and so that your local work automatically gets tucked aside when you sync with the team, instead of creating messy conflicts. Host: Love that tree analogy. So before someone opens this exercise and starts typing, what's the tricky part? What trips people up here? Expert: The trap is treating this like "just make some folders." It's not. The subtle part is the version control configuration — the behavior settings that decide what happens when two people's changes meet. There's one setting that controls whether updates get layered cleanly on top of each other or get jumbled together with merge markers. There's another that automatically stashes — meaning temporarily sets aside — your unfinished work when you pull in updates, so you don't lose anything. If you skip these, the folder structure looks fine but the team hits conflicts on day two. My tip: treat the configuration step as the real work of this exercise. The directories are the easy part. Also — validate at the end. Your tool should check its own work and confirm the repository genuinely follows the conventions. Don't trust that it worked just because nothing crashed. Host: Great. So what will someone actually walk away able to do, and where does this go next? Expert: After this, you'll be able to take any empty project folder and, in one command, stand up a production-ready AI repository with the right structure, the right version control behavior, and starter files that match how real AI teams organize their work. That's a building block your team can genuinely reuse — the kind of internal tool that saves every new project a half-day of setup and prevents a whole class of workflow mistakes. Next in this chapter, you'll extend this thinking to branch naming. You'll build a validator that enforces consistent names for side branches — things like a feature prefix or a fix prefix — so that when someone glances at the project, they immediately know what each branch is for. And after that, you'll walk through a complete branch lifecycle, from creation to a clean merge back into the trunk. Together, those three exercises give you the full working foundation of Git discipline for an AI team. Thanks for listening, and enjoy the lab.