Operations | Monitoring | ITSM | DevOps | Cloud

Merge conflicts rarely make it into a sprint retrospective, but they should. They’re one of the most reliable ways to lose an hour of flow without anyone noticing it’s gone. Every developer expects them eventually, but almost nobody questions the workflow around resolving them.

GitBench is our attempt to see how well LLMs handle git-specific tasks. We put together a suite of 17 benchmark categories with a total of 204 specific test cases. We ran these benchmarks against 43 (and counting) different models with all of their supported effort/reasoning levels.

From plan to main. Software is no longer just a tool. It is the infrastructure of modern life. Software keeps airplanes in the sky and power flowing into our homes. It helps doctors save lives, scientists discover cures, farmers feed cities, and astronauts navigate space. It powers economies, protects supply chains, and connects billions of people across the world. Every major system humanity depends on now depends on software. Which means developers are no longer just building applications.

You’re no longer writing code. You’re managing a pipeline of agents writing it for you. If you’ve been running two, three, or four AI coding agents in parallel, you already know the problem. The agents are fast. The orchestration is chaos. You’re bouncing between terminal windows, manually rebasing branches, cleaning up messy commits, and trying to remember which agent is touching which repo.

Your pull request has been open for three days. Your reviewer hasn’t commented. You’re starting to wonder if anyone will ever look at it—and whether the code you wrote on Monday still makes sense on Thursday. This feeling is common. PR lifecycle time—the duration from first commit to merged code—directly impacts how quickly you ship features, how fresh your code stays, and how engaged your reviewers remain.

Tracking down who made a specific change in your codebase can feel like detective work. Whether you’re debugging an issue or trying to understand why a particular piece of logic exists, knowing the history behind each line is invaluable. GitKraken makes this process simple with tools like GitLens for VS Code and GitKraken Desktop, which bring blame annotations directly into your workflow.

Engineering leaders need more than raw metrics, they need actionable insights they can trust with their data. When evaluating engineering intelligence platforms, privacy controls and centralized repository oversight should top your criteria list. The platforms on this list each offer distinct approaches to tracking DORA metrics, developer productivity, and code quality while keeping your data secure.

The Agent Impact Leaderboard and the Business Impact & ROI Dashboard are live in preview inside GitKraken Insights today. We built them because the questions engineering leaders are getting asked about AI shifted faster than the tools to answer them. Here’s what shipped and how to get access.

If you are a software developer or engineer, you most likely have to do code review. At the bare minimum, you probably have had your pull requests reviewed. If you haven’t, then you are probably curious about how the rest of the world deals with the process. In general, we use code review to make sure we are shipping high quality code that does what it’s supposed to and is easy to maintain. That’s the goal, at least. In practice, code review can get messy.

Choosing the right Git extension for your VS Code setup can make the difference between a smooth workflow and hours lost hunting for context. GitLens, developed by GitKraken, and VS Code Git Graph both aim to enhance your Git experience, but they approach the problem differently. This article ranks both extensions across key workflow scenarios – merge conflicts, commit history, code review, debugging, UX, and performance – so you can pick the right tool for how you work.