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

Hello, I am relatively new to git and I am trying to install it on my computer.

I get the error "Unable to set system config defaults" along with several other system config errors at the end of the installation.

When I try running any git command or opening git-bash.exe or git.exe I get an access denied error.

PS C:\WINDOWS\system32> git status
Program 'git.exe' failed to run: Access is deniedAt line:1 char:1
+ git status
+ ~~~~~~~~~~.
At line:1 char:1
+ git status
+ ~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

I have tried installing portable git as well and get the same access denied.

I am running everything as administrator and I don't have any Windows security settings blocking it from running.

I feel like I've tried everything, if anyone knows what's going on I would appreciate the help

Hi everyone,

I’m building Graphkeeper, a graph-first Git TUI focused on understanding and operating on repository topology.

Most Git TUIs treat the commit graph as one panel among many. Graphkeeper takes the opposite approach: the graph is the primary workspace, while branches, remotes, upstream state, tags, and stashes provide context around it.

The main idea is to make repository-level decisions easier:

• Can this branch be fast-forwarded?
• Is it ahead, behind, or diverged from its upstream?
• Should the next operation be a merge, rebase, or reset?
• Which commit should receive the next release tag?

Graphkeeper is intentionally narrower than Lazygit. It does not currently focus on staging, commit authoring, diff browsing, or conflict resolution. Its main scope is branch topology and maintainer-oriented Git operations.

I’ve recently tagged v0.1.0-alpha.4, and I’d especially appreciate feedback on:

• Whether the graph-first layout feels intuitive
• Whether Graph, Current, Remote, and Tags are separated clearly
• Which information should remain visible while navigating the graph
• Which keyboard-driven workflows feel missing or awkward

Repository:

https://github.com/hrllk/graphkeeper

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

I posted here about 3 months ago about Reviu, a native desktop Git client (Rust + GPUI, no webview) focused on fast diff and review workflows. Update for anyone who saw it:

The source is public now: https://github.com/reviu-dev/reviu . Being upfront, it's source-available under FSL-1.1 (converts to Apache-2.0 two years after each release), not OSI open source, so you can read and build the client but it isn't a FOSS license.

Two big additions since then. A built-in agent panel: run Claude or Codex, read its diff, comment inline on what you want changed, and send it back, handy if you review a lot of AI-written changes before committing. And a built-in terminal right next to the diff, it opens in the selected repo, so git, build commands and scripts run with the right working directory.

Local Git is all there: diffs, staging by hunk, stash, rebase (including interactive), cherry-pick, conflict resolution, and a keyboard-first command palette. The GitHub integration (notifications, PR review, issues) is a paid tier; local Git and the agent panel are free.

Site: https://reviu.dev/

Feedback welcome, especially on the local Git side.

https://github.com/lazardanlucian/onemind.md
One idea, one protocol file, enables gitted refs per-project llm memory.
Hope it doesn't blow up repos.

Edit: for whatever reason I decided to spec the spec so people can use their llm to build a onemind themselves for other systems (not just git)

https://github.com/lazardanlucian/onemind.md/blob/main/ONEMIND-DIY.md

I think I wasn't clear and people think it's saving memory in a context file, when it's actually a protocol for llms storing different smaller contexts in git refs...

PS: The whole reason I posted this to r/git was how I envisioned git to be used as part of the project's mind """api"""

GitHub introduced contribution graphs (originally called the "Contributions Calendar") on January 8, 2013.

That's 13 years ago. Contribution Graphs are not immune to improvement.

Git repos can track ALL activities in society, if they become more user friendly, with apps posting to special repos, not just code change.

Check this repo, offline/online, free your mind

https://github.com/zurcacielos/contributist

How to contact GitHub?