Operations | Monitoring | ITSM | DevOps | Cloud

Most teams use Jira to plan work and GitHub to build it. The problem is those two tools don’t talk to each other by default. Developers end up manually copying commit references into tickets, project managers hunt through GitHub to answer basic status questions, and sprint reviews become archaeology expeditions through two disconnected systems. Git Integration for Jira closes that gap.

Introducing GitKraken Desktop 12.0. At some point in the last year, the question shifted. It stopped being “should I use AI coding agents?” and became “how do I run more than one at a time without losing my mind?” If you’ve been there, you know what the management layer looks like. A terminal per agent. A worktree created by hand before each session.

There’s a version of the AI story that engineering leaders want to hear. It goes like this: adopt AI coding tools, watch output multiply, ship faster, do more with less. Clean. Simple. Boardroom-ready. The data tells a different story. Not a worse one. Just a more honest one. We recently analyzed 2,172 developer-weeks of real coding activity across teams using GitHub Copilot, Cursor, and Claude Code. The headline numbers are striking: power users show 4-14x higher activity than non-users.

During International Women’s Month, we celebrate women whose technical work changed entire industries. But the lessons from engineers like Margaret Hamilton aren’t seasonal, they’re fundamental to how we should approach software development every single day. Margaret coined the term “software engineering” and built the code that landed humans on the moon. Her approach to rigor is as relevant to your next Git commit as it was to Apollo 11’s descent engine.

Seven developer-requested features. Tighter control over branches, history, and large repos. No CLI detours required. If you have been using GitKraken Desktop in a complex repo, you already know what it feels like when the commit graph turns into a wall of branches. When rebasing requires more ceremony than it should. When you just need one file back from three commits ago but have to orchestrate a whole checkout to get it. GitKraken Desktop 11.10 is built for those moments.

When we rolled out AI coding tools across our engineering team, the first few weeks felt great. Developers were enthusiastic. Acceptance rates looked healthy. Everyone said they felt more productive. Then my CEO asked me a simple question: “Is it working?” And I realized I didn’t have a good answer. Feeling productive and being productive are not the same thing.

Most developers spend hours each week wrestling with Git. Not because they’re bad at their jobs, but because Git doesn’t actively teach you its most powerful features. At GitKon 2025, our Senior Product Marketing Manager Jonathan Silva revealed 6 underused Git commands that solve the workflow problems developers face every day: botched rebases, lost commits, and merge conflict chaos. These aren’t advanced techniques.

As developers, we’ve all been there: a frantic coding session, a few hasty commits, and suddenly our Git history looks like a patchwork quilt of “fix,” “oops,” and “stuff.” While git rebase -i is a powerful tool for cleaning up, it’s also a source of anxiety for many, often leading to more headaches than it solves. What if you could achieve a pristine, meaningful commit history without the fear of breaking things or hours spent squashing and rewriting?

Some releases break new ground. Others clear the path. GitKraken Desktop 11.8 does both. You know that moment when you’re three commits deep into an interactive rebase and realize you’ve made a terrible mistake? Or when you’re trying to explain what changed on a feature branch, but it means manually selecting 47 commits? Or when you just want to preview a README without opening another app?

You’ve probably used AI earlier today. Maybe you asked it to debug a function, generate a test case, or explain a legacy codebase you just inherited. But here’s the thing: you didn’t just type a question and get an answer. You explained your problem, shared background context, pasted code snippets, clarified what you meant, then refined the output until it was actually useful. In other words, you were context engineering.