标签：#dev

Introduction When a query runs in ClickHouse®, the database does much more than simply read data and return results. Before execution begins, ClickHouse® parses the SQL statement, analyzes it, applies optimizations, and builds an execution plan that determines the most efficient way to process the query. Understanding query execution plans is one of the most valuable skills for anyone working with ClickHouse®. They provide visibility into how queries are executed, helping you identify bottlenecks, validate optimization efforts, and troubleshoot performance issues. In this article, we'll explore how ClickHouse® generates execution plans, the different EXPLAIN modes, and how to interpret them for better query optimization. Why Query Execution Plans Matter A SQL query defines what data you want, but it doesn't explain how the database retrieves it. Consider the following query: SELECT country , count () FROM events GROUP BY country ; Although the query looks simple, ClickHouse® must determine: Which data parts to read Whether primary indexes can reduce the scan If data skipping indexes can be used How aggregation should be performed Whether parallel execution is possible How intermediate results should be merged A query execution plan provides answers to these questions, making it an essential tool for performance tuning. The ClickHouse Query Lifecycle Every query passes through several stages before producing results. The lifecycle typically looks like this: SQL Query │ ▼ Parser │ ▼ Analyzer │ ▼ Optimizer │ ▼ Query Plan │ ▼ Execution Pipeline │ ▼ Results Each stage plays an important role: Parser validates SQL syntax. Analyzer resolves tables, columns, and expressions. Optimizer applies query optimizations. Query Plan determines the logical execution steps. Pipeline distributes work across multiple threads. Execution processes the data and returns the results. Understanding this workflow makes execution plans much easier to interpret. Introducing the EXPLAIN Statement

I applied to a YC W25 startup the normal way. Filled out the form, wrote a decent cover letter, hit submit. Silence. While waiting, I found their open-source repo on GitHub. Read through the codebase out of genuine curiosity I wanted to understand what they were actually building. Found a bug. Fixed it. Opened a PR. It got merged in 2 days. They still hadn't replied to my application. Here's what that taught me about job hunting in 2025: A cover letter tells someone what you claim you can do. A merged PR shows them. One of those gets read. The other gets filed under "maybe later" -which is just "no" with extra steps. I'm not saying cold applications are dead. I'm saying they're the last resort, not the first move. If a company has a public repo, you have a backdoor that most applicants don't even think to try. Read the code deep and find something small but real. Fix it and Open a PR. Now you're not a stranger in their inbox you're someone who already ships for them. The reply came eventually, by the way. But by then, the maintainers already knew my GitHub handle. That matters more than you think. Have you ever landed something through a contribution instead of an application? Drop it in the comments curious how many people have done this.

Here's a thinking process: Analyze User Input: Role: Ghostwriter for Roberto Luna Osorio Editorial Profile: Developer Storytelling (primary), Build in Public, Técnico, Reflexivo. Philosophy: Share the process/learnings, not just the perfect result. Mandatory narrative questions: Problem, First attempt, What went wrong, How solved, What learned, What's next. Tone: First person, direct, honest, technical but accessible, curious. Avoid corporate jargon, clickbait, marketing hype, false modesty, empty summaries. Language: Spanish (natural/colloquial tech MX/LatAm) OR English (conversational, dev-friendly). Wait, the prompt says "English only (Dev.to is primarily English)" for this specific article. I'll stick to English as instructed for the Dev.to angle. Angle: TECHNICAL DEEP-DIVE ("HOW I BUILT IT"). Focus on code, architecture, specific files. Different from Medium's narrative style. Style: Technical, precise, code-forward. Real file/function names, error messages. First person but engineer-voice. English only. Mandatory Structure: TL;DR, The Problem, What I Tried First, The Implementation, Key Takeaway, What's Next. Length: 800-1200 words. Tags: #vibecoding #buildinpublic + relevant tech tags. Input Data: Repo: VS, Date: 2026-06-23. Commits show v1.6.0 sprint 1, booking reminders, /confirm/:token, notifications, bulk actions, pipeline v2. Files modified: booking-reminders.service.ts , booking.controller.ts , email.cron.ts , notifications.controller.ts , NotificationBell.tsx , confirm/[token]/page.tsx , ventas/pipeline/page.tsx , etc. Diffs show version bumps, cron integration, notification controller refactor, new components. Constraint: Do NOT repeat angles from this week: "El control de acceso y la caja negra de las publicaciones". Choose a completely different angle. Final Instruction: Write complete article. Start directly with TL;DR. Include actual code snippets. Do NOT write a story — write a technical breakdown. Map to Editorial Profile & Constraints: Profile

One-time passcodes are everywhere: sign up for a service, log in from a new device, confirm an action, and a six-digit code lands in your email. A human glances at it and types it in. An automated flow, a signup script, an end-to-end test, or an AI agent connecting to a third-party service, can't glance at anything. It has to pull the code out of the mailbox programmatically, and that's a surprisingly fiddly job: the code arrives seconds after a trigger, it's buried in a templated email, and every sender formats it differently. This post covers extracting verification codes from two angles: the nylas CLI , which does it for you in one command, and the Email API pattern you build when it's part of a larger flow. I work on the CLI, so the terminal commands below are the ones I reach for when I just need the code. Two ways to get the code There are two paths depending on what you're building. For terminal workflows, local testing, or scripting a login, the CLI has a dedicated nylas otp command that finds the latest code in a mailbox and hands it to you. For an application or an agent that reacts to incoming mail, you build the extraction into your own flow: catch the message when it arrives, pull the body, and parse the code out. The difference is who drives. The CLI is pull-based: you ask for the latest code when you need it. The API pattern is push-based: a webhook tells you a message arrived, and your code extracts the value as part of handling it. Both end at the same place, a string of digits you feed into whatever's waiting for it, but the CLI is the fast path for a developer and the API pattern is the durable path for a product. In practice you use both: the CLI to learn which sender and code format you're dealing with during development, then that same understanding baked into the application pattern for production. Grab the latest code from the CLI When you've just triggered a code and want it now, nylas otp get finds the most recent one in your default accoun

A webhook endpoint is a public URL sitting on the internet, and anything on the internet can send it a POST . If your app acts on whatever lands there, an attacker who guesses the URL can forge events: fake an inbound email, trigger a workflow, or feed your system garbage. The fix is to confirm two things before you trust a request, that you own the endpoint and that Nylas actually sent the payload, and both are built into how webhooks work. This post covers verifying webhooks from two angles: the HTTP mechanics your endpoint implements, and the nylas CLI for testing a signature without standing up a server. I work on the CLI, so the terminal commands below are the ones I reach for when I'm debugging a signature mismatch. Two layers of webhook trust There are two separate checks, and they happen at different times. The first is a one-time endpoint challenge: when you register or activate a webhook, Nylas sends your URL a request with a challenge value you echo back, proving you control the endpoint. The second runs on every notification afterward: each delivery carries a cryptographic signature you verify against a shared secret, proving the payload is genuine and wasn't tampered with. You need both because they defend against different things. The challenge stops you from accidentally registering an endpoint you don't own and confirms the URL is live. The signature stops anyone else from posting forged events to that URL once it's known. Skip the signature check and your public endpoint will trust any POST that reaches it, which is the most common webhook security mistake. Pass the endpoint challenge The first time you set up a webhook or flip one to active , Nylas sends a GET request to your endpoint with a challenge query parameter. Your endpoint has to return the exact value of that challenge in the body of a 200 OK response, within 10 seconds, or the webhook won't verify. It's a quick handshake that proves the URL is yours and reachable. // Express: echo the ch

Every Nylas request you make on a user's behalf needs one thing first: their permission. Before you can list a mailbox, send on someone's behalf, or read a calendar, the user has to authorize your application through their provider, and that authorization is what's called a grant. Doing the OAuth dance yourself means registering with Google and Microsoft separately, handling each provider's consent screen, token exchange, and refresh quirks. Hosted OAuth collapses that into one flow that works the same across every provider. This post walks through connecting an account from two angles: the HTTP API your web app uses in production, and the nylas CLI for connecting a test account from the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I need a grant to develop against. What a grant is A grant is an authenticated connection to a single user's account. When a user authorizes your application, Nylas stores the connection and hands you a grant_id , a stable identifier you pass on every subsequent request to act on that user's email, calendar, or contacts. The grant is the unit of access: one user who connected one mailbox is one grant, and everything you build addresses /v3/grants/{grant_id}/... . Keep two credentials distinct here. Your API key authenticates your application to Nylas and goes in the Authorization header on every request; the grant_id identifies which connected user that request acts on. The API key is yours and stays on your backend, while a grant_id is minted per user when they connect. The grant is also where provider differences disappear. A Gmail grant and a Microsoft grant have different OAuth scopes and token mechanics underneath, but once connected, both are just a grant_id you use the same way. That's the point of hosted OAuth: you run one flow, the user picks their provider, and you get back the same kind of identifier regardless of who hosts the mailbox. Hosted OAuth supports Google, Microsoft, Yahoo,

Dein bestes Google-Ranking ist wertlos, wenn die Antwort schon vor dem Klick gegeben wurde. Genau das passiert gerade: Nutzer fragen ChatGPT, Claude oder Perplexity – und bekommen eine fertige Antwort mit drei, vier zitierten Quellen. Bist du nicht darunter, existierst du in diesem Moment nicht. Kein Ranking, kein Klick, keine zweite Chance. Die Disziplin, die das adressiert, heißt Generative Engine Optimization (GEO) . Und sie ist – anders als der Marketing-Lärm vermuten lässt – zu großen Teilen ein Engineering-Problem. Crawler-Zugang, Rendering, strukturierte Daten. Lauter Dinge, über die ein Entwickler entscheidet, nicht das Content-Team. SEO optimiert auf den Klick. GEO optimiert auf das Zitat. Der Unterschied ist nicht kosmetisch. Klassisches SEO will, dass du auf Platz eins rankst, damit jemand klickt. GEO will, dass ein Sprachmodell deinen Absatz wörtlich in seine Antwort übernimmt – inklusive Quellenangabe. Der Klick ist nur noch Bonus. Daraus folgt ein anderer Tech-Stack an Signalen: Aspekt Klassisches SEO GEO / KI-Sichtbarkeit Ziel Top-10 in Google Zitat in ChatGPT, Claude, Perplexity Relevante Bots Googlebot, Bingbot GPTBot, ClaudeBot, PerplexityBot Index-Hinweis sitemap.xml llms.txt + sitemap.xml Strukturierte Daten Rich Snippets Entity-Linking ( Organization , sameAs , @graph ) Rendering Google rendert JS (verzögert) viele KI-Bots rendern kein JS → SSR Pflicht Erfolgskontrolle Search Console, Rank-Tracker Citation- & Mention-Tracking in LLMs Die Hebel überschneiden sich – sauberes HTML, schnelle Antwortzeiten, valides Markup helfen beidem. Aber die Bots, die Index-Signale und die Erfolgskontrolle sind eigenständig. Wer GEO als „SEO mit neuem Namen" abtut, übersieht genau die Stellen, an denen es klemmt. Schritt 1: Lass die Bots überhaupt rein Bevor du über Content-Qualität nachdenkst, klär die banale Frage: Kommt der Crawler durch? Erstaunlich oft lautet die Antwort nein – und niemand merkt es, weil ein Browser die Seite ja problemlos lädt. Die drei Use

Most "Shopware vs Shopify" posts compare dashboards, app stores, and pricing tables. None of that matters to you until the day a client asks for something the platform won't let you build. Then the comparison stops being a feature grid and becomes a question about ceilings: how high can I go before the platform says no, and what happens when I hit it? That's the only axis I care about as a developer, so that's the one I'll argue on. Shopify is an outstanding product. It's also a closed SaaS that decides, on your behalf, where customization ends. Shopware is open source built on Symfony, which means the ceiling is "however far PHP and HTTP will take you." Below are the three places that difference actually bites, with code. Angle 1: The checkout is the wall This is the headline because it's where most agency developers first hit something they cannot do. For years the Shopify answer to "customize the checkout" was checkout.liquid . That era is over. Shopify deprecated checkout.liquid in favour of Checkout Extensibility . Plus stores had to migrate their Thank-you and Order-status pages by August 28, 2025 , and in January 2026 Shopify began auto-upgrading stores — wiping customizations built on additional scripts, script-tag apps, or checkout.liquid . Non-Plus stores have until August 26, 2026 , and legacy Shopify Scripts keep working only until June 30, 2026 . ( Shopify migration timeline ) The replacement, Checkout Extensibility, is genuinely more upgrade-safe. It's also a smaller box. You get Checkout UI Extensions (declarative components that render in slots Shopify defines) and Shopify Functions for backend logic — and that's the surface. You don't own the checkout template; you decorate the pieces Shopify exposes. Worth noting: full visual checkout customization (branding API, custom fields beyond the defaults, full UI extension power) is gated to Shopify Plus anyway. On Shopware, the checkout is a Twig template like every other page, and you override it the sam

I'll be honest — I didn't set out to build a developer tool. I'm an engineer by trade. I build structural and forensic engineering software. C++, WinUI 3, heavy desktop apps. But a big chunk of my prototyping and internal tooling happens in Python — and every time I sat down to spin up a quick Python desktop app, I hit the same wall. Every launcher, every hot-reload tool, every dev cockpit I found wanted something from me. Install this. License that. Set up a virtual environment. Add five dependencies just to watch a file change. I just wanted to run my app, see it update when I changed something, and get back to work. So I built ILX Launcher. The rule I gave myself was simple: pure Python stdlib and tkinter. Nothing else. If it couldn't be done with what Python already ships with, I didn't need it. What came out of that constraint surprised me. No pip install. No virtual environment required. No licensing headaches. You clone it, you run it, it works. That's it. It's a developer cockpit for Python desktop apps — run, hot-reload, test, profile, and ship, all from one place. The kind of tool I wished existed six months ago. It's early. It's rough around the edges. But it works, and it's already saving me time every single day. If you've ever felt like your dev tooling was getting in the way of actually building — I'd love for you to try it and tell me what you think. 👉 github.com/ilxstudio/ILX-Launcher And if it saves you even five minutes — drop a ⭐ on the repo. It genuinely helps others find it.

Our infrastructure "documentation" was a Google Sheet. Anyone on the team could edit it. Nobody...

Remember how I promised you (or rather myself) two weeks ago that from now on I'd only write light,...

I remember the exact moment my first AI side project died. It was 3 AM, I had just spent two full weeks building an elaborate RAG pipeline with vector databases, custom embeddings, and a fine-tuned model—all for a tool that would "revolutionize how developers read documentation." I hadn't written a single line of user-facing code. I hadn't even validated if anyone wanted it. And when I finally deployed it to a hobby server, the cost of hosting the model alone was $200/month. I killed the project before anyone ever visited the URL. That was three months ago. Since then, I've shipped three AI side projects that actually have users. Not millions—but real people who use them daily. Two of them even cover their own hosting costs now. The difference? I stopped trying to build the perfect AI infrastructure and started shipping the stupidest thing that could work. Here's what I learned from those three MVPs, and how you can break out of the "AI side project graveyard" too. The Trap: Thinking You Need to Build Everything The biggest lie in the AI side project space is that you need to own the stack. Every tutorial screams "self-host Llama 3," "set up your own vector database," "build a custom agent framework." That's great for learning, but it's death for shipping. For my second project—a tool that automatically generates commit messages from diffs—I spent exactly one evening. I used the OpenAI API directly, with no caching, no streaming, no error handling. Here's the core of it: import openai import subprocess def get_diff (): result = subprocess . run ([ " git " , " diff " , " --cached " ], capture_output = True , text = True ) return result . stdout def generate_commit_message ( diff ): response = openai . chat . completions . create ( model = " gpt-3.5-turbo " , messages = [ { " role " : " system " , " content " : " Write a concise git commit message summarizing the changes. " }, { " role " : " user " , " content " : diff } ] ) return response . choices [ 0 ]. message .

Every developer using Cursor , Claude Code , Windsurf , or GitHub Copilot knows this exact frustration: You are building a cutting-edge Angular 22 application. You ask your AI coding assistant to spin up a dynamic form, a lazy-loaded list, or an asynchronous data card. Instead of leveraging modern fine-grained reactive Signals, optimized native block control flows, or proper SSR hydration hooks, the AI drops an unoptimized pile of legacy tech debt full of NgModules , *ngIf , *ngFor , and raw RxJS BehaviorSubjects . The LLM Training Paradox Why does this happen? Large Language Models are trained on historical code datasets. Statistically, more than 90% of the public Angular repositories and StackOverflow threads on the internet represent older paradigms. Left to their own devices, agents default to the statistical average of their training data. They literally default to the past. The Fix: angular22-agent-skills To solve this, I built a public, open-source repository of custom instruction bundles and system guardrails leveraging the new skills.sh tool standard. By injecting this verified context directly into your development environment, you force your local AI agents to bypass their training averages and write pristine, optimized, modern Angular 22 syntax every single time. 👉 Check out the repo here: https://github.com/PavanAnguluri/angular22-agent-skills 🔍 The Difference: Before vs. After To understand why these guardrails are necessary, look at what an AI agent writes out of the box versus what it writes once you apply the angular22-agent-skills harness. 🚫 What AI Agents Generate by Default (Legacy) // The AI falls back to old decorators and heavy RxJS boilerplate for standard state import { Component , Input , OnInit } from ' @angular/core ' ; import { BehaviorSubject } from ' rxjs ' ; @ Component ({ selector : ' app-user-profile ' , template : ` <div *ngIf="visible"> <h3>{{ firstName }} {{ lastName }}</h3> <div *ngFor="let item of items"> {{ item.name }} </div>

Every identity migration guide eventually reaches the same paragraph, and it's always a little apologetic: "users will need to reset their passwords." It gets treated like a law of nature. It isn't. It's a choice, usually forced by a tool that didn't want to do the harder thing. The harder thing is verifying your users' existing password hashes in place, so they sign in after the move with exactly the credentials they had before and never notice anything happened. Whether you can do it comes down to one question: can you get the old hashes, and can the new system verify them? Password hashes are more portable than people think A password hash isn't a secret algorithm. bcrypt is bcrypt. A bcrypt hash carries its own cost factor and salt inside the string, so anything that implements bcrypt can verify a hash any other bcrypt system produced. The same is true of the PBKDF2 format ASP.NET Identity uses: documented, versioned, self-describing. If you know what you're holding, you can check a password against it without ever knowing the password. So a migration that preserves logins doesn't need the plaintext (nobody has it) and doesn't need to re-hash everyone up front. It needs to obtain the stored hashes and verify against them on sign-in, upgrading each one to its own format quietly the first time a user logs in. That last part is lazy migration: carry the old hash, verify it once, replace it transparently. Over a few weeks of normal logins your user table re-hashes itself and the legacy formats age out, with zero resets and zero support tickets. The dual-path bit The wrinkle is that different sources hand you different formats, and a good importer verifies both: From self-hosted Duende / ASP.NET Identity: the V3 PBKDF2 hashes (and any legacy bcrypt) verify natively and rehash on first sign-in. This is the easy case, because it's the same scheme the destination already uses. Most teams are surprised it's that clean. From Auth0: bcrypt hashes verify verbatim. The catch

After a long and deliberate alpha, spartan/ui is now 1.0 . We shipped the first 30 primitives in August 2023 with a simple bet: building accessible, good-looking UI in Angular is harder than it should be, and the community deserved a better starting point. Almost three years later, that bet has grown into a stable, production-ready library of more than 55 components - built on signals, ready for zoneless, and server-side-rendering compatible out of the box. Here's what 1.0 actually means. Stable, and ready to build on We stayed in alpha for a long time on purpose. It let us refine the APIs in the open, with real applications putting real pressure on the design, instead of freezing a v1 we'd regret six months later. That patience is what 1.0 cashes in. The APIs are now stable and semantically versioned, so you can depend on spartan/ui/brain and upgrade with confidence. The copy-in spartan/ui/helm layer stays exactly as it's always been - yours to own, read, and customize. No black boxes, no fighting the library to change a style. Built for modern Angular Every primitive is built on Angular signals and standalone components. spartan is zoneless-ready and SSR compatible out of the box, so it drops cleanly into how Angular apps are actually written today - no extra setup, no adapters. The split that's defined spartan from day one still holds. spartan/ui/brain carries the hard, unglamorous parts - ARIA, keyboard navigation, focus management - and keeps them maintained so you don't have to. spartan/ui/helm gives you full styling control on top, copied into your project like a recipe. Accessibility you can rely on; appearance you fully own. From 30 primitives to 55+ The alpha shipped with 30 components. 1.0 ships with more than 55 - nearly double - including many of the most-requested additions over the past two years: Data Table - sorting, filtering, and selection, the piece people asked for most Sidebar - composable app navigation Calendar and Date Picker Carousel , Auto

Top 7 Featured DEV Posts of the Week Cyberpunk cat RPGs and robot personalities Jess Lee Jess Lee Jess Lee Follow for The DEV Team Jun 23 Top 7 Featured DEV Posts of the Week # discuss # top7 34 reactions 7 comments 2 min read

I'm Dr. Mohammad Reza Beheshti, Founder of CyberSiARA. I hold a PhD in Electronic Engineering and Artificial Intelligence and have over 15 years of experience in cybersecurity research and innovation. My passion has always been solving complex security challenges through technology. This journey led me to found CyberSiARA, where we're developing AI-powered bot protection and human verification solutions to help organizations defend against increasingly sophisticated cyber threats. I enjoy combining academic research with practical engineering to create technologies that are both innovative and effective in the real world. Through this blog, I share insights from my research, product development, and experiences building a cybersecurity company, with the aim of helping developers and security professionals stay ahead of emerging threats. I'm always keen to learn, collaborate, and contribute to the global developer and cybersecurity communities.

This is the third piece in a sequence. The first asked whether Sloan had flagged anyone else — it...

I wanted AI code review I could actually own. Not access through a subscription or a black-box service with its own limits. The deployment, credentials, providers, and usage under my control. I kept hitting usage limits mid-week during deep building sessions. The models were capable. The workflow was useful. But access still depended on somebody else's weekly allowance, and centralized platforms can change whenever the company behind them decides to. Pricing, quotas, models, plan boundaries. A workflow that fits this month may sit behind another subscription next month. I could not find a reliable open-source option that gave me the ownership model I wanted. So I built one. That became Codra : A self-hosted AI review engine built around bring-your-own models, your own data boundary, and no Codra-imposed usage ceiling. What Codra Is Codra is an open-source, self-hosted AI code review engine for GitHub pull requests. It listens to pull request events, reviews changed files, posts inline findings, and provides a dashboard for jobs, repositories, model routing, history, usage, and failures. It runs on Cloudflare Workers and uses: Cloudflare Queues for review jobs PostgreSQL through Hyperdrive for storage KV for sessions and cache A React dashboard for operations The GitHub App, model credentials, database, and review history are yours. Provider keys are encrypted with AES-GCM using your deployment secret. Bring Your Own Model, Bring Your Own Limits Changing providers does not require replacing your review history, configuration, or workflow. You configure the provider and model. Supported: OpenAI-compatible APIs OpenRouter Anthropic Google / Gemini Cloudflare Workers AI Why Self-Hosted Matters Here A large frontend repo and a tiny backend repo should not need the same review strategy. Each repository gets its own review settings. You tune triggers, skip generated files, ignore drafts, use mention-triggered reviews, configure labels, set file limits, and define custom ru

One of the most confusing errors you can face while deploying a Node.js or Docker-based application is: fatal: Need to specify how to reconcile divergent branches At first glance, it looks like a Git bug. In reality, it is Git doing exactly what it should do, protecting you from overwriting history. In this article, I’ll break down a real production incident where a deployment failed due to divergent Git branches, how we diagnosed it, and the correct DevOps fix. The Problem A simple deployment script was running: git pull docker compose down --remove-orphans docker compose up --build -d But it failed with: fatal: Need to specify how to reconcile divergent branches This stopped deployment completely. What Git Was Telling Us To understand the issue, we ran: git rev-list --left-right --count HEAD...origin/main Output: 1 16 This means: 1 commit exists locally on the server 16 commits exist on GitHub So the branches had diverged. Why This Happens (Important) This usually happens when: Someone runs git commit directly on a server A previous deployment used git pull with merge commits History between local and remote is no longer linear Git refuses to guess whether you want to: Merge Rebase Or reject changes So it throws an error. Deep Diagnosis We inspected the commits: git log --oneline origin/main..HEAD Result: 6d9046b Merge pull request #222 Then: git log --oneline HEAD..origin/main Showed multiple new GitHub PR merges. Conclusion: The server was behind GitHub The “local commit” was already part of repo history No real production changes existed on server The Real Fix (Production Safe) For deployment servers, you should NEVER rely on git pull . Instead, use a deterministic reset: git fetch origin git reset --hard origin/main Then redeploy: docker compose down --remove-orphans docker compose up --build -d Why This Works This approach ensures: Server always matches GitHub exactly No merge conflicts in production No accidental local commits survive Fully reproducible depl