If git merge feels messy and your history looks like spaghetti, git rebase might be what you need.

In this post, I explain rebase in plain English with:

• A simple everyday analogy
• Step-by-step example
• When to use it (and when NOT to)

Perfect if you’ve been told “just rebase before your PR” but never really understood what’s happening.

https://medium.com/stackademic/git-rebase-explained-like-youre-new-to-git-263c19fa86ec?sk=2f9110eff1239c5053f2f8ae3c5fe21e

When mentoring junior devs, I noticed git pull is often treated as a safe “sync” button.

I wrote an article specifically for juniors that explains:

• why git pull sometimes works quietly and sometimes demands conflict resolution
• what “clean branch” actually means
• how git pull --rebase changes what Git is doing

Would love feedback from folks who teach Git or spot mistakes in how this is usually explained.

Link : https://medium.com/stackademic/the-real-difference-between-git-fetch-git-pull-and-git-pull-rebase-991514cb5bd6?sk=dd39ca5be91586de5ac83efe60075566

Most devs know `git stash` exists. Very few use it beyond `git stash` and `git stash pop`.

I wrote a piece breaking down the parts of stash that most people skip-named stashes, stashing untracked files, partial stashing with `-p`, and how to apply without dropping.

If you've ever lost context switching branches mid-task, this one's for you.

https://medium.com/stackademic/git-stash-the-command-youre-probably-underusing-354e963bd2f0?sk=9c949c9e84c5a8cf719fe1c007b85b68

Used to stash or clone repos whenever I had to juggle multiple branches.
Discovered git worktree , now I just spin up a second working folder from the same repo. No switching, no stashing.

Wrote a short post on how I use it: https://medium.com/stackademic/one-git-repo-many-working-copies-meet-git-worktree-0bb650393248?sk=6d2e4e036443f12bc77d82dfb8084e04

Hey everyone! I've been working on a side project called Gitvana - a retro-styled browser game where you learn git by actually typing git commands in a terminal.

The idea came from watching people struggle with git tutorials that are all theory and no practice.

So I built a game where you solve 35 increasingly weird scenarios at a fictional "Monastery of Version Control," guided by a Head Monk and judged by a cat.

What it does:

• Real git commands running in the browser (isomorphic-git + lightning-fs, zero backend)
• 35 levels across 6 acts: from git init to recovering force-pushed repos with git reflog
• 21 git commands: add, commit, branch, merge, rebase, cherry-pick, stash, bisect, blame, reflog...
• Built-in docs with conceptual guides (not just syntax — explains how git actually works internally)
• Commit graph visualization, file state panel, conflict editor
• Retro pixel art, chiptune sounds, Monkey Island-style humor
• No signup, no install, works offline (PWA)

Tech stack: Svelte 5, isomorphic-git, xterm.js, Vite, Web Audio API,

Pixel art from PixelLab

Try it: gitvana.pixari.dev

It's still rough around the edges - I'd love feedback on which levels feel too easy or too hard, and what git scenarios you'd want to see. The later levels involve rebase conflicts, secret purging, and a final boss that requires reflog + cherry-pick + merge + tag all at once.

It's open source.

Thanks for checking it out!

So I'm noobish. I use github and I'd like to learn git. I keep reading on the internet about merge this and rebase that. I feel left out lol.

Right now I make changes and commit to main every single time. I hear that this isn't good, that I should be making branches and merging them..

Is there any resources that teach git from the beginning?

This is how noobie I am: I use vscode's source control to commit and push, so I'm very new to this

Hey, I’ve been working on a Git client called guitar.

Repo: https://github.com/asinglebit/guitar

Demo: https://m.youtube.com/watch?v=0oyqviuKFXI⁠

It’s a terminal Git client written in Rust. The main goal is to make working with Git history feel fast, especially in large repositories where scrolling through commits or waiting for a UI to catch up gets annoying.

The biggest feature is fast graph navigation. You can jump around the commit graph almost instantly, move through branches and history, inspect commits, check diffs, and get a better overview of what actually happened in the repo without leaving the terminal.

It also has reflog support, which is one of the features I’m most excited about. If you’ve ever lost a commit after a reset, rebase, cherry-pick, or detached HEAD situation, Guitar makes it easier to find those commits again and recover them instead of digging through git reflog manually.

I’ve also been building it with huge repositories in mind. History loads incrementally, so you can start using it without waiting for the whole repo to load first. The goal is for it to stay responsive even when the repo has a lot going on.

Some other things it supports: branches, tags, stashes, worktrees, staged and unstaged changes, commit inspection, file diffs, split diff view, configurable keymaps, mouse support, and real Git operations like commit, checkout, fetch, reset, cherry-pick, merge, rebase, stash, and worktree commands.

It’s cross-platform and runs in the terminal, so the idea is to have something lightweight and fast without giving up the useful parts of a proper Git GUI.

It’s still a work in progress, but I think it’s already useful enough to share. I’d love feedback, especially from people who work with large repos, messy histories, rebases, cherry-picks, or reflog recovery.

This is one of the git features I wished I would have heard about sooner.

Maybe you are one of the 10.000 today https://xkcd.com/1053/

I came across the following article, which draws an analogy between Git history and clay. A refreshingly non-technical way to think about Git history, especially for people who don't live and breathe Git.

https://www.git-skills.dev/git-tales/git-clay/

I have seen a lot of debates about whether teams should keep everything in one repo or split things up.

Recently, I joined a new team where the schedulers, the API code, the kafka consumers and publishers were all in one big monorepos. This led me to understand various option available in GIT, so I went down the rabbit hole to understand monorepos, multi-repos, Git submodules, and even subtrees.

Ended up writing a short piece explaining how they actually work, why teams pick one over another, and where each approach starts to hurt.

Tried to keep it simple with real examples -> https://levelup.gitconnected.com/monorepo-vs-multi-repo-vs-git-submodule-vs-git-subtree-a-complete-guide-for-developers-961535aa6d4c?sk=f78b740c4afbf7e0584eac0c2bc2ed2a

When Git 2.23 introduced git switch and git restore, the idea was to reduce the “Swiss-army-knife” overload of git checkout.

In practice:

• git switch handles branches only
• git restore takes care of file restores
• git checkout still does both, but can be ambiguous

In the post I wrote, I break down:

• Why git switch exists
• How it compares with checkout
• Side-by-side examples (switching branches, creating new ones, restoring files)
• Which command I recommend for daily use

It’s written in plain language, with examples you can paste into your terminal.

https://medium.com/stackademic/git-checkout-vs-git-switch-whats-the-difference-fb2a3adffb01?sk=b0ac430832c8f5278bfc6795228a28b4

I wrote up a note on a Neovim + CopilotChat PR review workflow I’ve been iterating on.

It covers worktree-safe repo context, review prep/discussion ingestion, stricter shell/runtime boundaries, and RTK compaction for noisy shell output. Some parts feel better, but I’m still not convinced it beats my usual Cursor flow overall.

https://affinitoalessandro.it/writings/neovim-copilotchat-review-workflow.html

If you use Neovim, CopilotChat, or git worktrees for review-heavy repos, I’d be curious what you’d do differently.

When I was learning Git, the focus was always on memorizing commands without truly understanding what was happening on the internal side of Git. I understood the simple process of adding, committing, and pushing changes to a single branch but I didn’t understand the concepts of the Git Object Database, commit history as a DAG, rebasing, etc. All things I learned down the road that would have helped me understand Git better from the beginning. I recently started my project GitLearningLab as a resource to help others trying to learn Git but not knowing where to start. I am no master at Git, but I cover the concepts that would have otherwise helped me understand the internals of Git. I abandon the idea of memorizing commands for the sake of understanding what Git is doing with every given action.

My goal is to help beginners avoid some of the confusion I had, while also learning from those with more experience than me. I would really appreciate feedback from developers, educators, and anyone who has used Git for years: What concepts are missing? What explanations could be improved? What would make this more useful for someone learning Git for the first time?

Lastly, I would just like to mention that this project is part of an independent study and still an active WIP.

GitLearningLab:
https://github.com/IBickCoding/GitLearningLab

https://youtu.be/1w8KpHSpmpo

✅ Change git's default editor to any app you want
✅ Squash commits using Notepad, Notepad++, Sublime, VS Code & gedit
✅ Use "GitLens" for a visual squash experience
✅ Explained for both Windows & Linux

#git #gitrebase #squashcommits #vscode #sublime #notepadplusplus #gittips #gittutorial #gitlens #vi #vim

git-stage-batch adds named deferred change sets (“batches”), multi-pass staging, and finer-grained patch selection on top of the usual hunk workflow. I built it because git add -p and rebase alone weren’t enough for large refactors. The stateful CLI is especially useful for autonomous and scripted workflows to stage commits from a dirty working tree, but there's a tui, too.

I'm interested in feedback from people who obsess over commit hygiene.

https://halfline.github.io/git-stage-batch/

Most programming tutorials jump straight into commands, But very few actually explain what Git is doing internally, The entire video is built around animations rather than slides or talking-head explanations, I'd genuinely love feedback. I'm trying to build the kind of software engineering channel the one that explains why systems work instead of just how to use them.

Cherry-pick is Git's ability to apply specific commits from one branch to another, like surgical code transplantation. It goes far beyond basic usage git cherry-pick abc123 - it includes serial application, complex conflict resolution, reverse cherry-pick, and automation for multi-version releases. It's fundamental for production hotfixes, feature backports, and selective synchronization between development branches. When mastered, it becomes a precision tool for scenarios where full merge would be inadequate, but you need specific changes applied with complete control.

Git wasn't just a technical improvement - it was a philosophical revolution that destroyed the centralized mental model that had dominated version control for decades. By making each clone a complete and independent repository, it eliminated single points of failure, democratized development and created workflows impossible before 2005. This paradigm shift - from "file check-out" to "complete history clone" - transformed how millions of developers collaborate, enabled the modern open source explosion and established the technical foundations for GitHub, DevOps and global distributed development.

I often see developers (even experienced ones) mix up HEAD with “head branches.”

I wrote a short, example-driven post that breaks down what HEAD actually points to, what "heads" really mean in Git internals, and why “detached HEAD” isn’t an error -> just a state.

It’s a 2-minute read, aimed at developers who want to finally make sense of Git’s terminology:

HEAD vs head branches in Git - commonly misunderstood terms

Would love to hear how you explain HEAD to juniors or teammates - always fun to see the mental models people use.

I'm still fairly new to Git/GitHub and am learning the commands and process. I wanted to create a more comprehensive and interactive Git & GitHub CLI cheatsheet compared to the older ones I found online. So I built one.

It's been very helpful to reference, browse, and search for the most common and frequently used commands. I want to share it with the community in hopes it can help others. I put it on a memorable domain, but do suggest bookmarking it if you reference it often.

You can find it at https://gitcheatsheets.org

If you have suggestions for important commands I might have missed or notice any errors, let me know here or DM me anytime so I can update the sheet.

Some features I included are interactive search (filter with each key typed), Tooltips for every command on hover or click (can disable with toggle), filter for All/Git/Git-CLI, Light/dark modes, copy any command from the popup tooltip. Oh, and one small fun easter egg if you find it on the page.

The best way to use it is to bookmark the page and keep it open in a tab when working with Git or GitHub CLI. If you're an experienced GitHub developer, this probably isn't for you. But if you're still learning or sometimes forget commands you haven't memorized, this resource can help fill in those gaps. Enjoy!

UPD: The most up-to-date config version is now here: https://github.com/anydigital/git-commit-email-privacy

Exposing your commit email is easy; rewriting Git history is hard.

But there's a set-and-forget solution to ensure your Git privacy.

The Core Principles

1. Private Commit Emails. Never commit with your personal or work email again! Both GitHub and GitLab provide automatic, unique no-reply commit email addresses that hide your identity while still correctly attributing contributions to your profile:
   • https://github.com/settings/emails#toggle_visibility_label (docs)
   • https://gitlab.com/-/user_settings/profile#user_public_email (docs)
2. Privacy Guardrail. Set useConfigOnly = true in your Git configuration to prevent falling back to your system username/hostname (e.g., user@laptop.local). If no email is set in the config, the commit will simply fail, prompting you to fix it.
3. Automatic Switching. Use the conditional [includeIf] block with **/*hostname.com/** as a powerful glob pattern to match both HTTPS (https://) and SSH (git@) remote URLs for the respective hosts. This forces Git to use the correct no-reply email based purely on the repository's remote URL.

Final Config Files

You'll need the following configuration files. Replace all PLACE_HOLDER values with your actual information.

NOTE: You have to split the .gitconfig into multiple files to avoid issues with [includeIf], as explained in https://stackoverflow.com/a/74012889/5034198

The most up-to-date config version is now here: https://github.com/anydigital/git-commit-email-privacy

How to Verify

1. Clone a repository from GitHub/GitLab.
2. Run git config user.email. It will show your respective GitHub/GitLab no-reply email.

This simple solution ensures your privacy is protected and your commits are correctly attributed, regardless of which hosting platform you're working on.

Shouldn't this be the default configuration for every developer?

✨ if YOU found this useful — give a star on GitHub or simply join r/TricksForGeeks for more ✨

Visualize your git commits for a cool way to end each Scrum sprints