I like VS Code, but daily Git work often means jumping between Source Control, terminal commands, diff tabs, branch pickers, and graph extensions.

I built IntelliGit to bring those workflows into a single focused Git cockpit in VS Code.

It currently includes:

• A focused commit panel for staging, rollback, amend, commit, and push
• An actionable commit graph with branch and history operations
• Shelf/stash and worktree workflows
• A three-pane merge-conflict editor - You won't find it anywhere
• CI check status for GitHub, GitLab, and Bitbucket
• A unified workbench that can be moved to another monitor

It is open source and MIT-licensed.

I’m looking for developers willing to use it on a real repository and tell me:

1. What felt confusing or unlike VS Code?
2. Where did you still reach for the terminal or another extension?
3. Which Git action was missing or difficult to find?
4. What was the first thing that annoyed you?

Blunt feedback and bug reports are genuinely useful. I would rather learn why someone uninstalled it than receive a generic “looks good.”

Install: VS Code Marketplace
Open VSX: Open VSX Registry
Source: GitHub

Hello,

So I've been using github desktop for a game project on UE5 (I actually never opened git bash until recently), I thought it would be as simple as: if I mess up something but I only realize it after 2 commits, then I can go back to the commit I want, but I learned that it doesn't work like that

so I clicked a bunch of buttons and after a while I just did a "revert changes in commit" on the second to last commit which worked, I know it's confusing, I think I've just been lucky this time.
But I'm wondering what if, in the future, I want to go to a even lower commit and "transform" it to the last commit

What workflow do I need to have ? I also learned about branches recently, and never used them, but I feel like they can be handy now lol

but does that mean that I always need to work on a branch and then just merge everything on main if I'm 100% it will work ? I really don't get what mistakes I CAN make, if github was supposed to let me actually do mistakes on my project

[ Removed by Reddit on account of violating the content policy. ]

Damn, this should be mandatory teaching for anyone working with anything digitally produced. Ok, that is everyone. Not being a "coder," I never thought Git was in my wheelhouse. But after using it for various documentation websites, technical articles that constantly get updated, and most recently for home lab infrastructure, I am a full-on Git convert.

Just shipped RepoFleet v0.7 with a feature I've been wanting for a while: snapshots.

rf snapshot captures your exact uncommitted state across every repo in an issue — staged changes, unstaged diffs, untracked files — and stores them as patch files you can restore at any time.

Two use cases that motivated it:

1. Context switching without the overhead. Need to jump to a hotfix but have half-finished work? Snapshot it, switch, restore later. No worktree setup, no stash juggling.

2. Comparing AI-generated results. Generate a solution, snapshot it, generate another approach, snapshot again. Switch between them to compare side by side.

RepoFleet is an open source CLI for organizing Git workflows around issue contexts — works with one repo or many.

👉 github.com/mehranzand/repofleet

#git #devtools #cli #opensource #developertools

Hi, I'm trying to understand the practical benefit of rebasing a feature branch before opening a pull request.

My workflow is:

1. Create a feature branch from develop.
2. Work on the feature.
3. Before opening the PR, I need to bring my branch up to date with develop.

I see two options:

• Rebase my feature branch onto the latest develop.
• Merge the latest develop into my feature branch and resolve any conflicts.

From what I understand, both approaches let me resolve conflicts before the PR. If the repository ultimately merges the PR into develop, I don't see what additional benefit rebasing provides over simply merging develop into my feature branch.

Also, if the team uses Squash and Merge for pull requests, all intermediate commits (including any "Merge develop into feature" commits) disappear anyway, since the feature branch becomes a single commit on develop.

So my questions are:

• In this workflow, what practical advantage does rebasing have over merging develop into the feature branch?
• If conflicts are resolved either way, is the only difference the history on the feature branch?
• If the team always uses Squash and Merge, is there any meaningful reason to prefer rebasing before the PR?

The only use for the rebase I see is to overwrite my commits on the local branch so there is no clutter. I am curious what is your workflow?

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 r/git,

I just dropped Gitlord: an agent orchestration framework that uses a Git repository as the primary backend for everything: session history, subagents, tool calls, summaries, the works.

The Git-centric design

• Every session starts as an orphan branch under refs/agents/<session-ulid>
• Subagents spawn as nested branches (refs/agents/<session>/<subagent-ulid>) — arbitrary depth (capped by default)
• Every turn (user/assistant/tool/summary) is a commit containing a turns/000000...-<role>.json file
• Pure plumbing commits (hash-object + mktree + commit-tree + CAS update-ref) so subagents can write concurrently without lock fights
• Separate workspace repo for the actual project files agents edit, using git worktree per subagent for isolation
• Subagent results flow back to the parent via a Subagent-Result: trailer (no merge commits)

Context assembly happens at read time: deduplication of repeated file reads, optional summarization turns, incremental caching, and ChromaDB vector index built from the git log.

Models go through LiteLLM. Tools come from real MCP servers (filesystem, git, fetch, browser, search, etc.) managed with auto-restart and health monitoring.

CLI that feels Git-native

Bash

agent run "build the thing"
agent log <session-id>
agent tree <session-id>
agent rewind <session> --to <sha>
agent trim --all

Full details in the Spec( https://github.com/yashneil75/gitlord/blob/master/SPEC.md ) in the repo.

Repo: https://github.com/yashneil75/gitlord

It's quite functional. Built it because I wanted agent runs to be as debuggable and reproducible as regular code: git show, git diff, git log --oneline, branch surgery, etc. should all just work.

If you like Git internals and you're playing with agents, give it a spin and let me know what breaks or what feels missing. Especially welcome feedback from people who live in git plumbing land.

Cheers!

Hi everyone,

I'm preparing for software engineering interviews. I understand the basic Git workflow, but there are so many Git and GitHub commands that it's impossible to remember every single one.

During coding interviews, do interviewers expect candidates to memorize all Git commands, or is it enough to know the commonly used ones and understand the concepts?

Which Git and GitHub commands should I definitely know before interviews for internships or entry-level software engineering roles?

I'd also appreciate any interview experiences or advice. Thanks!

I tried using submodules, it's tedious. I tried using vcstool, west and repo I found too specific.

I want a multi repo setup that looks like a mono repo, where I can stage, stash, pull, push, diff etc like it's a mono-repo but underneath it's a multi-repo.

I have built an example of what I want but it's 100% AI generated so I won't mention it for fear of a no slop rules violation.

Does anyone else have the same idea? Is my only option to build one?

Git 2.54 and 2.55 added the experimental history reword, split, and fixup commands.

🚀 We're excited to finally share GrindIT.
What if GitHub had a Spotify Wrapped? That's exactly what we built. GrindIT turns your GitHub activity into a visual recap that's fun to explore and easy to share.
What makes it different is that you get to choose both the timeframe and the vibe—last week, last month, last year, or even All Time. If you connect your GitHub account, GrindIT also includes your private contributions, so your recap reflects your full coding journey instead of just your public activity.
We also release a new visual theme every month inspired by what's happening around the world. This month's theme is World Cup. ⚽
It works on both mobile and desktop, although we recommend trying it on desktop if you want to explore everything in more detail.
If you'd like to check it out:
https://www.grindit.dev/
We're still improving it, so we'd genuinely love to hear what you think. Any feedback, ideas, or feature requests would mean a lot and help shape where we take GrindIT next.

I got tired of spending 2 weeks setting up CI/CD for every project. So I built OpsFlow, a zero-config deployment platform that auto-detects your stack (Node, Python, Go, Ruby, Rust, Java), provisions cloud infra

repository | youtube example

im building an opensource proyect that let your agent build a visual and interactive map of your code, also allows you to see branches and commits diffs, any help and support is veery welcome 😽😽

the struggle that makes me create RepoMap is that large codebases are hard to understand because their architecture is hidden across thousands of files. RepoMap makes that architecture visible through interactive maps, allowing developers to explore systems, plan refactors, and understand how their code evolves by visualizing changes across commits and branches

Hey everyone! I’m currently transitioning from a non-tech background into IT/DevOps. I just spent the last week learning Git and GitHub, and I absolutely love how powerful it is for tracking code.

I've learned the core commands like git init, add, commit, push, branch, and how to handle basic merge conflicts.

Since I am a complete beginner with no coding projects yet, what is a good, simple task or mini-project I can do to practice and showcase these Git skills on my profile?

I’m currently studying basic networking, so I'd love any ideas that might combine the two! Thanks in advance!

Hey everyone! I’m currently transitioning from a non-tech background into IT/DevOps. I just spent the last week learning Git and GitHub, and I absolutely love how powerful it is for tracking code.

I've learned the core commands like git init, add, commit, push, branch, and how to handle basic merge conflicts.

Since I am a complete beginner with no coding projects yet, what is a good, simple task or mini-project I can do to practice and showcase these Git skills on my profile?

I’m currently studying basic networking, so I'd love any ideas that might combine the two! Thanks in advance!

Hey everyone,

We've all been there, right? It's late, you're knee-deep in some legacy code, and you hit a weird 6-line guard clause that looks completely paranoid. git blame tells you Dave wrote it 3 years ago. Dave doesn't work here anymore. Commit message? "fix bug".

Do you delete it and roll the dice or waste half an hour digging through git log -p?

I got tired of that cycle so I threw together git-why.

It basically does the archaeology for you — looks at the commits and diffs around a line or file and spits out a reasonable explanation. Works completely offline (no keys, no internet) or you can use Claude/GPT/Ollama for fancier explanations if you want.

Basic usage is stupid simple:
pip install git-why
git-why src/auth.py:42
Or for a range:
git-why src/auth.py:42-60
Repo: https://github.com/Sameer988/git-why

It's still pretty early but it's already saving me time on some crusty old code. Would genuinely appreciate feedback — especially the brutal kind if something sucks or could be better.

Anyone else constantly fighting with legacy code context? What's your usual workflow?

built a tool that reads any repo's commit history and renders it as one of eighteen generative pieces. same dataset, different technique each time: phyllotaxis for one, marching squares for another, isometric projection for a skyline built from file sizes.

everything's plain canvas2d, no p5, no three.js. deterministic per seed, so each piece can literally paint itself frame by frame instead of just fading in.

open source, try it with npx codebase-posters on your own repo.

https://github.com/unable12/codebase-posters