How can I learn Git by doing it visually??

How can I learn Git by doing it visually??

Spent enough time cleaning up repos where .gitignore was an afterthought that I put together the patterns I actually reuse across projects.

The ones that catch OS cruft, IDE junk, build artifacts, and secrets before they get committed, not after.

A few that trip people up:

• Ignoring a file doesn't untrack it if it's already committed. you still need git rm --cached
• Negation patterns (!important.log) only work if the parent directory isn't already ignored
• Global gitignore (core.excludesFile) vs per-repo. Most people only set up one

Wrote up the fuller list with explanations here if useful: https://levelup.gitconnected.com/gitignore-patterns-every-developer-should-have-in-their-toolkit-c5458f076ca2?sk=b1fd0885e817c58dbfb69440a7769feb

Curious what patterns other people follow

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?

Hi, What i want to do. Remove all files 100MB or higher in a bitbucket repository and migrate it to githubEnterprise. ( With as little downtime as possible) Excuse me if i misspeak and say something not technically accurate. I'm not a git wizard but have read some of the manual + using ai which has mostly been worthless...The idea is here though.

what have i been doing:

1. Git clone --mirror <repository>
2. git filter repo git filter-repo --strip-blobs-bigger-than 99M
3. git push --force --set-upstream origin master
4. git push --tags --force ((( i was wondering if this would leave some tags out that were rewritten but it appears thar it doesn't)))

(I cannot do a git push --mirror as i get a bunch of pre receive hook errors. ( set up by the company)

Now here is where i get stuck. When the IT team uses gh -bbsgh2 to migrate the repo they were getting errors on large obejects. These large objects are referenced in refs/pull-requests/xx/. I have quadruple checked that the large objects are only pointed at from these pull request refs that show up in a mirror clone. As i understand it....even if i rewrite the pull requests i cannot push changes to those refs on repository. (This is a bitbucket rule). If they cut out the pullrequest refs during the migration the pull requests are not migrated at all. We cannot see any notes/comments/etc. Its like they don't exist. ( i was kind of presuming that gh-bbsgh2 used some api sht that grabbed the pull requests not by the actual refs ) I tested migrating a repo with open and closed pull requests which never had large objects and it appears to migrate. The team has a couple thousand pull requests that we want to save the information on and bring to the new repo plus maybe another 1000 that don't reference large files. What can i do about this?

i had an idea to rename the edited no large file refs/pull-requests/xx/ to something like refs/actually-a-pull-request/xx/ and push those to the repo. i guess i don't see a way for gh -bbsgh2 to migrate that as a pull request. Maybe i need to grab the refs and rename again while gh -bbsgh2 is running. I remember reading something about it but i cant find it now....and anyhow it seems kind of like letting in more points of failure in the process and kind of hacky

Thanks for looking at this. :)

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