✅ CONTENIDO_TECNICO | Tech Researcher
Home / Open Source / Git Highlights from Git 2.54 The open source Git project just released Git 2.54. Here is GitHub’s look at some of the most interesting features and changes introduced since last time. Taylor Blau · @ttaylorr April 20, 2026 | 10 minutes Share: The open-source Git project just released Git 2.54 with features and bug fixes from over 137 contributors, 66 of them new. We last caught up with you on the latest in Git back when 2.52 was released . To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time. 💡 Since the last Git release we wrote about was Git 2.52, this blog post covers the highlights from both the 2.53 and 2.54 releases. Rewrite history with git history The Git project has a long history of providing tools to rewrite your repository’s history. git rebase –i is the most well-known, and it’s remarkably flexible: you can reorder, squash, edit, and drop commits. But that flexibility comes with complexity: an interactive rebase operates on a range of commits, updates your working tree and index as it goes, and can leave you in a conflicted state that you need to resolve before proceeding. For simpler cases, all of that machinery can feel like overkill. If all you want to do is fix a typo in a commit message three commits back, or split one commit into two, an interactive rebase works, but requires you to set up a to-do list, mark the right commit for editing, and then drive the rebase to completion. Git 2.54 introduces a new experimental command that is designed for exactly these simpler cases: git history . The history command currently supports two operations: reword and split . git history reword opens your editor with the specified commit’s message and rewrites it in place, updating any branches that descend from that commit. Unlike git rebase , it doesn’t touch your working tree or index, and it can even operate in a bare repository . git history split lets you interactively split a commit into two by selecting which hunks should be carved out into a new parent commit. The interface will look familiar if you’ve ever used add in interactive mode via git add –p : $ git history split HEAD diff –git a/bar b/bar new file mode 100644 index 0000000..50810a5 — /dev/null +++ b/bar @@ -0,0 +1 @@ +bar (1/1) Stage addition [y,n,q,a,d,p,?]? y After selecting hunks, Git creates a new commit with those changes as the parent of the original commit (which retains whatever hunks you didn’t select) and rewrites any descendent branches to point at the updated history. There are a couple of intentional limitations worth noting. The history command does not support histories that contain merge commits, and it will refuse to perform any operation that would result in a merge conflict. By design, git history is meant for targeted, non-interactive rewrites, not the kind of open-ended history rewriting typically relegated to git rebase –i . The history command is built on top of git replay ‘s core machinery, which was itself extracted into a library as part of this work. That foundation means that git history benefits from replay ‘s ability to operate without touching the working tree, making it a natural fit for scripting and automation in addition to interactive use. This command is still marked as experimental, so its interface may evolve. Give it a try with git history reword and git history split , available in Git 2.54. [ source , source , source , source , source ] Config-based hooks If you’ve ever wanted to share a Git hook across multiple repositories, you’ve probably had to reach for a third-party hook manager, or manually symlink scripts into each repository’s $GIT_DIR/hooks directory. That’s because, historically, Git hooks could only be defined as executable scripts living in one place: the hooks…
📰 Fuente Original
GitHub Blog – Leer completo →
🤖 Publicado por Tech Researcher
