惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Last Week in AI
Last Week in AI
S
Schneier on Security
The GitHub Blog
The GitHub Blog
宝玉的分享
宝玉的分享
GbyAI
GbyAI
L
LINUX DO - 热门话题
大猫的无限游戏
大猫的无限游戏
Hacker News: Ask HN
Hacker News: Ask HN
A
Arctic Wolf
罗磊的独立博客
S
Securelist
I
Intezer
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
D
Darknet – Hacking Tools, Hacker News & Cyber Security
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The Register - Security
The Register - Security
M
MIT News - Artificial intelligence
C
Cisco Blogs
G
GRAHAM CLULEY
P
Proofpoint News Feed
美团技术团队
MongoDB | Blog
MongoDB | Blog
Cyberwarzone
Cyberwarzone
T
Tor Project blog
P
Proofpoint News Feed
NISL@THU
NISL@THU
J
Java Code Geeks
有赞技术团队
有赞技术团队
AWS News Blog
AWS News Blog
D
Docker
博客园 - 聂微东
I
InfoQ
AI
AI
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
O
OpenAI News
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
C
Cybersecurity and Infrastructure Security Agency CISA
Know Your Adversary
Know Your Adversary
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Application and Cybersecurity Blog
Application and Cybersecurity Blog
N
News | PayPal Newsroom
L
LangChain Blog
Hugging Face - Blog
Hugging Face - Blog
T
Tenable Blog
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
MyScale Blog
MyScale Blog
T
Tailwind CSS Blog
K
Kaspersky official blog

Butler's Log

Agentic Version Control Benchmarks Grit: rewriting Git in Rust with agents Git Merge 2026 Agent-safe Git with GitButler We’ve raised $17M to build what comes after Git Announcing the GitButler CLI for Linux The Great CSS Expansion A couple of git nits Introducing the GitButler CLI GitButler 0.19 - "Commander Keen" But Head: Crafting a Custom Font MCP vs RAG: Two Very Different Ways to Gain Context Getting Started With GitButler Agents Using the GitButler MCP Server to Build Better AI-Driven Git Workflows Using GitButler With Multiple GitHub Accounts Advent of Code! Upcoming GitButler Events Use GitButler for your Gerrit workflow Integrating GitButler and GitHub Enterprise Butler Flow: shipping code faster (but less like Alfred, more like CI on steroids) - Part 3 Butler Flow: shipping code faster (but less like Alfred, more like CI on steroids) - Part 2 Butler Flow: shipping code faster (but less like Alfred, more like CI on steroids) - Part 1 Grid Happens: Because Flexbox Wasn’t Enough Using Cursor Hooks for automatic version control Deep Dive into the new Cursor Hooks A Responsive Item Counter with CSS only GitButler 0.16 - "Sweet Sixteen" GitButler's Claude Code tab GitButler's Annual Open Source Pledge Report Git Mini Summit 2025 Videos Automate Your AI Workflows with Claude Code Hooks Managing Multiple Claude Code Sessions Without Worktrees GitButler 0.15 - "Quirky Quinceañera" 20 years of Git. Still weird, still wonderful. GitButler's new patch based Code Review (Beta) Going down the rabbit hole of Git's new bundle-uri How to do patch-based review with git range-diff How Core Git Developers Configure Git Why is Git Autocorrect too fast for Formula One drivers? Stacked Branches with GitButler Git Merge 2024 Talks are Up GitButler 0.13 - "Lucky Baseball" Fearless Rebasing Git Merge 2024 Why GitHub Actually Won GitButler is joining the Open Source Pledge The New Era of Town Hall Chat The Future of Open Source GitButler is now Fair Source Git Merge 2024 GitButler 0.12 - "Stingy Baker" The Birth of THE MERGE GitButler for Windows Fixing up Git with Autosquash The Git Zeitgeist Git Worktrees and GitButler DevWorld Git Slides Git Tips and Tricks Git Tips 1: Oldies but Goodies Git Tips 2: New Stuff in Git Git Tips 3: Really Large Repositories FOSDEM Git Talk Opening Up GitButler Debugging Tauri in VS Code Advent of GitButler Code Signing Commits in Git, Explained Virtual Branches Alpha Our We Are Developers Adventure Building Virtual Branches DevDays in Vilnius The Future of Software and Open Source Introducing GitButler
Simplifying Git by Using GitButler
PJ Hagerty · 2026-02-23 · via Butler's Log

Git is great - and has been for twenty years. But in that time, how many of us have advanced our git skills? Most of us know about five or six commands: clone, status, push/pull, add, commit, branch, and checkout.

But there is so much more you can do with git, and GitButler can help you take advantage of it.

The gap between what git can do and how we use it

Git has quietly accumulated an enormous amount of power. Features like interactive rebasing, selective staging, multiple concurrent branches, worktrees, reflog, and sophisticated history rewriting have been around for years. Yet many developers actively avoid them. Not because they are unnecessary, but because they are hard to visualize, easy to misuse, and painful to recover from when something goes wrong.

Most teams end up with a simplified workflow not because it is optimal, but because it is survivable. Linear history, small commits, and rebasing are aspirational goals. In practice, developers juggle half finished work, context switches, and production interruptions. Git can handle this reality, but the command line does a poor job of showing what is actually happening.

GitButler exists to close that gap. It does not replace git. It exposes git. It gives you a mental model of advanced git features and lets you use them safely, incrementally, and with confidence.

One of the biggest blockers to using advanced git features is uncertainty. When you run a command like git rebase -i, you are operating on an invisible structure. Commits move, hashes change, branches detach, and you are expected to trust that everything went according to plan.

GitButler makes git state visible. Instead of thinking in terms of opaque commands, you see branches, commits, uncommitted changes, and their relationships laid out visually. This matters because advanced git usage is less about memorizing flags and more about understanding how history is shaped.

For example, when working with multiple branches at once, many developers fall back to stashing. Stash is useful, but it is also a black box. GitButler encourages a different approach by making it easy to keep multiple lines of work active simultaneously without hiding changes away. You can see what belongs where and switch context without losing track of what is in progress.

Branches are one of git’s superpowers, yet they are often underused. Many developers treat branches as heavyweight objects tied strictly to tickets or pull requests. In reality, branches are cheap, local, and disposable. They are ideal for experimentation, refactoring, and parallel work.

GitButler leans into this idea by making branch creation and management frictionless. You can spin up branches for small ideas, partial fixes, or exploratory changes without worrying about cleanup later. Because the UI clearly shows which commits live on which branches, it becomes obvious when a branch is safe to delete or ready to merge.

This lowers the cost of branching to almost zero. As a result, developers start using branches the way git intended, as a lightweight mechanism for isolating change rather than a bureaucratic requirement.

Understanding and using stacked changes

One of the more advanced workflows supported by git is stacking changes. Instead of one large branch with many unrelated commits, you create a series of small, dependent branches. Each branch builds on the previous one and can be reviewed, tested, and merged independently.

This workflow is powerful but notoriously hard to manage with the command line alone. Rebasing stacks, keeping branches aligned, and updating dependent changes requires careful coordination.

GitButler makes stacked changes a first class concept. You can see the stack, understand the dependency order, and adjust it visually. When the base branch changes, GitButler helps rebase the stack safely. When one layer is merged, you can easily update or collapse the remaining branches.

For teams that care about clean history and incremental review, this is a major unlock. It turns what is usually an advanced, error prone workflow into something approachable.

Interactive rebase is one of the most powerful features in git. It allows you to reorder commits, squash them, split them, edit messages, and generally craft a clean narrative of your work. It is also a feature many developers avoid unless absolutely necessary.

The reason is simple. One wrong move and you are staring at a broken state with little confidence in how to recover.

GitButler reduces this anxiety by showing you exactly what rebasing will do before it happens. Instead of editing a text file and hoping the result matches your intent, you manipulate commits directly. You can reorder them, combine them, or modify them while seeing the outcome in real time.

This encourages more frequent use of interactive rebasing. Over time, developers stop thinking of rebasing as a dangerous last resort and start using it as a normal part of preparing work for review.

Most developers know that git add -p exists. Fewer use it regularly. Selective staging is one of the easiest ways to improve commit quality, but it requires patience and attention at the command line.

GitButler brings selective staging into the foreground. You can stage individual lines or hunks with a click, making it natural to create focused commits even when working in a messy file. This is especially useful during refactors, where mechanical changes and logical changes often get mixed together.

By lowering the friction of selective staging, GitButler helps teams build better commit hygiene without enforcing rigid rules or adding extra process.

A subtle but important benefit of GitButler is confidence. When developers know they can see what is happening and recover from mistakes, they are more willing to experiment.

Git itself is extremely forgiving. Reflog alone can save you from almost any mistake. But reflog is hidden, cryptic, and rarely taught. GitButler surfaces this safety net. You can see where commits came from and where they went. Undoing an action feels safe instead of risky.

This changes how people work. They try things. They learn by doing. Advanced features stop being theoretical and start becoming practical tools.

GitButler is intentionally local first. It works with your local repository and respects your existing remotes, hosting providers, and workflows. There is no requirement to change how your team uses GitHub, GitLab, or any other service.

This matters for adoption. Developers can start using GitButler on their own without asking permission or changing team conventions. Over time, the benefits show up naturally in cleaner commits, clearer history, and fewer git related mishaps.

For experienced developers, this also means GitButler does not abstract away git. You can still drop to the command line at any time. The tool complements your existing knowledge rather than replacing it.

Documentation and tutorials are valuable, but they rarely stick unless reinforced by daily use. GitButler effectively teaches advanced git concepts by making them part of normal workflows.

When you see how rebasing affects a stack of commits, the mental model becomes clear. When you visualize branch relationships, concepts like fast forward merges and divergence stop being abstract. Over time, developers internalize how git works under the hood.

This has a compounding effect. As comfort increases, so does willingness to use more of git’s feature set. Teams that once avoided rebasing start using it routinely. Developers who feared history rewriting begin to see it as a tool for clarity.

Not every developer wants to become a git expert. Most just want to ship good code without fighting their tools. GitButler recognizes this reality.

By surfacing advanced capabilities in an intuitive way, GitButler allows developers to benefit from git’s power without memorizing arcane commands or flags. You get the upside of advanced workflows with a fraction of the cognitive load.

This does not dumbing down git. It is about aligning the interface with how developers actually think about their work.

Git has not stood still over the past twenty years. It has become more capable, more flexible, and more powerful. The limiting factor is no longer the tool, but how comfortably we can use it.

GitButler helps close that gap. It turns advanced git features into everyday tools by making state visible, actions reversible, and workflows understandable. For technical teams that care about code quality, history clarity, and developer sanity, this is a meaningful upgrade.

Don't relearn git, learn how best to use it by leveraging GitButler.

PJ Hagerty

Written by PJ Hagerty

PJ Hagerty is a well-known figure in the tech industry, particularly within the developer relations and DevOps communities. He's also Head of Developer and Community Relations at GitButler.

Table of Contents

  • The gap between what git can do and how we use it
  • Seeing git state instead of guessing it
  • Branching without fear
  • Understanding and using stacked changes
  • Interactive rebasing without the stress
  • Selective staging as a daily habit
  • Recoverability changes behavior
  • Local first, developer focused
  • Teaching git by doing
  • Advanced git without becoming a git expert
  • Closing the skills gap