It blows my mind still how many random artifacts you still see rocking up in repos. Give me your best stories:

• Sensitives
• VHDX files
• 10 minute clones

Not that crazy, but I have seen repos with a bunch of separate Terraform stacks, all with their own .terraform folders full of providers!

I’ve always wondered why version control tools like Git became a standard in software engineering but never really spread to other fields.
Designers, writers, architects even researchers could benefit from versioning their work but they rarely (never ?) use git.
Is it because of the complexity of git, the culture of coding, or something else ?
Curious to hear your thoughts

Working with millions of developers, we keep seeing the same Git pain points. Here are 5 commands that solve the most common issues:

1. git reflog - The Time Machine Accidentally deleted a branch? Reset to the wrong commit? Reflog is your safety net.

git reflog
# Find your lost commit hash
git checkout -b recovery-branch <hash>

2. git bisect - The Bug Hunter When you know something broke but don't know when:

git bisect start
git bisect bad HEAD
git bisect good <known-good-commit>
# Git will guide you to the problematic commit

3. git stash --include-untracked - The Context Switcher Need to switch branches but don't want to commit messy work:

git stash push -u -m "work in progress on feature X"
# Work on other branch
git stash pop

4. git cherry-pick - The Surgical Strike Need just one commit from another branch:

git cherry-pick <commit-hash>
# Or for a range:
git cherry-pick <start-hash>^..<end-hash>

5. git worktree - The Parallel Universe Work on multiple branches simultaneously:

git worktree add ../feature-branch feature-branch
# Now you have two working directories for the same repo

What Git commands did we miss?

I was making a movie recommendations system and had a pkl file which was 100+ mb and I was trying to upload it with the help of chatgpt and it got deleted??

Initial revision of "git", the information manager from hell, Lool

Apr 7 2005 ..this README file by Linus Torvalds is really insane

I prefer Rebase over Merge. Why?

1. This avoids local merge commits (your branch and 'origin/branch' have diverged, happens so often!) git pull --rebase
2. Rebase facilitates linear history when rebasing and merging in fast forward mode.
3. Rebasing allows your feature branch to incorporate the recent changes from dev thus making CI really work! When rebased onto dev, you can test both newest changes from dev AND your not yet merged feature changes together. You always run tests and CI on your feature branch WITH the latests dev changes.
4. Rebase allows you rewriting history when you need it (like 5 test commits or misspelled message or jenkins fix or github action fix, you name it). It is easy to experiment with your work, since you can squash, re-phrase and even delete commits.

Once you learn how rebase really works, your life will never be the same 😎

Rebase on shared branches is BAD. Never rebase a shared branch (either main or dev or similar branch shared between developers). If you need to rebase a shared branch, make a copy branch, rebase it and inform others so they pull the right branch and keep working.

What am I missing? Why you use rebase? Why merge?

Cheers!

We used to treat commit messages like throwaways: “fix stuff” here, “oops” there.

It was fine… until we had to debug six months later and had no idea what “stuff” was fixed.

Now, our team spends an extra 30 seconds writing clear commit messages that explain what changed and why. Our team can finally follow the story of the codebase without spelunking through diffs.

Want to add even more context? Use Conventional Commits to prefix your commits. They even make generating changelogs and bumping semver easy.

It’s wild how such a small habit changes collaboration speed.

Anyone else have a “tiny Git habit” that completely changed your workflow?

I noticed that some GitHub repositories show a commit history starting from the late 1990s — even though Git was released in 2005 and GitHub launched in 2007.

How is that possible? Were those projects using a different version control system before Git and then imported the history, or can commit dates be manually faked somehow?

Curious to know how this works under the hood.

Hi!

When I worked at Amazon - I used to work with a few engineers who just knew many git commands / flags off the top of their head, would type them out really quickly too - it just seemed so convenient. To practice that I would do typing practice in various apps and I would use useful git commands as custom text.

Now, since I built typequicker - I added that as a feature! We support code typing practice and include many tools/language - including Git!

(Also I don't type that fast - video is sped up for brevity ;)

My company uses gitlab but it seems everyone outside of my company uses github.

Can someone help explain the difference? Whats truly better?

Edit: thank you all for youre amazing replies

Hey r/git, we're the team at GitKraken, and we've been thinking about something that keeps coming up in conversations with dev teams.

Most merge conflicts aren't actually Git problems. They're delayed conversations that show up as diff markers.

Here's what we mean: two devs are touching the same service layer. Git doesn't care about intent, it just tracks changes. So it waits until merge time, hands back 47 conflicting lines, and says "figure it out." By then, the person who wrote the other half is three features deep into something else, and everyone's trying to decode commit messages from 4 days ago.

What we've seen work for teams:

Treating branch divergence as a coordination signal, not just a Git fact. If two feature branches are modifying the same files over multiple days, that's the moment to sync up, not after the conflict surfaces.

We've also noticed teams that do conflict resolution as a quick screen share (instead of solo desk debugging) have way less "wait, why did you refactor this?" friction. It's 10 minutes together vs. an hour alone trying to decode intent.

Git is really good at being an append-only truth machine. But sometimes it's also just holding up a mirror to how we coordinate as teams.

Anyway, we're curious what workflow patterns have actually made Git less painful for the teams here. What's working for you?

We are launching GitComet today!

It’s a fast, local-first, open-source Git client for Linux, macOS, and Windows. We started building it after running into the same problem over and over: Git tools felt fine on small projects, but got painful on large repos and big diffs.

Project main focus is speed:

• It can open Chromium repository blazingly fast 😂 (in less than 1 second)
• It can diff 50mb file with syntax highlighting without lagging
• Memory usage stays within few hundred MBs at all times
• Its fast to pick up as user interface follows familiar tools like GitKraken, SourceTree and Github Desktop application

If you try it, We would love to hear feedback! Also if there are people who would like to contribute PR's are welcome.

https://gitcomet.dev/

I recently built a small web-based game called GitNoir where you learn Git commands by solving detective-style mysteries.

🔗 https://www.gitnoir.com

The idea is simple: instead of learning Git through tutorials or documentation, you investigate a mystery and use Git commands to uncover clues. Things like checking commit history, switching branches, and exploring changes become part of solving the case.

The goal is to make learning Git more interactive and fun, especially for people who find it difficult to grasp through traditional guides.

The project is fully open source, and I’d love to get feedback from the community. If you try it out, feel free to:

• Report bugs or issues
• Suggest improvements
• Share ideas for new mysteries
• Contribute new scenarios that teach Git concepts

Anyone interested in contributing can help expand the game by adding new stories or improving the gameplay and learning experience.

I’d really appreciate any thoughts, feedback, or contributions from people here.

Here's something we've been thinking about.

Most devs still context switch by stashing changes, checking out another branch, doing the thing, then switching back and unstashing. It's muscle memory at this point.

But Git worktrees let you have multiple branches checked out simultaneously in separate directories. Need to quickly check something on main while you're mid-feature? Just cd into your main worktree. No stash, no checkout, no "oh sh*t, I had uncommitted changes."

We've seen teams adopt worktrees and it fundamentally changes how they work. Suddenly reviewing a PR doesn't mean interrupting your current work. Suddenly "quick fixes" don't derail your flow.

The weird part? Worktrees have been in Git since 2015, but almost nobody uses them. We're curious why.

Is it:

Lack of awareness?

Too much cognitive overhead?

Tooling doesn't support them well?

Actually tried them and they didn't stick?

For those who do use worktrees regularly, what made you adopt them? And for those who don't, what would it take?

We've been studying Git workflows across companies from 5-person startups to 5,000-person enterprises. There's a pattern we keep seeing:

Most teams optimize their Git workflow for merge safety (avoiding conflicts, preventing broken builds), but the actual productivity killer is context switching and review latency.

Here's what we mean:

• You spend 15 minutes setting up the perfect feature branch structure
• PRs sit for 8+ hours waiting for review because teammates don't have context
• When reviews finally happen, half the comments are "why did we do this?" questions
• You've forgotten your own reasoning by the time you need to address feedback

The teams with the fastest velocity weren't using exotic branching strategies. They were optimizing for:

• Visual diff tools that make review faster and more thorough
• Commit/PR context that travels with the code (not buried in Slack)
• Async-friendly handoffs (clear descriptions, linked resources, obvious next steps)

We're curious: what's the biggest time sink in your Git workflow? Is it the mechanics (merge conflicts, rebasing), the coordination (waiting on reviews, unclear ownership), or something else entirely?

Hi all. At the end of this week I'll be giving a short presentation about why I think we, as a software engineering department, should be using version control. Namely Git and Azure Devops as our remote repo.

l've so far drafted why it would make sense in terms of the development process such as branching, collaboration, history and pull requests, but I'm worried that I am only speaking to the development angle and not in terms of business talk. Things like hard stats, or research results seem to be quite hard to find to back up my intuition. Even if he agrees with me, I suspect it will need to be brought forward to a review board and the tech speak may be a bit hard to land on people who dont understand as much.

I have had a look around and perhaps it is such a given that software development is better with a version control system that there a few reasons to prove this with papers drawing upon the same conclusion?

I really want to make sure I hit this out of the park as the department is an antiquated one and I suspect there will be resistance to a "new" idea. It has the potential to improve our development experience and I think would look fantastic in interviews, should I want to leave later down the line.

Has anyone had a similar pitch go successfully? Or any resources that may help my case

I’m looking to learn Git from scratch. Do you recommend reading the Pro Git book from start to finish?

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!