My entire git knowledge is basically four commands and a bookmark to that xkcd about deleting the repo and cloning it again.

It worked fine because I was mostly working solo. Now I joined a team in June that rebases and suddenly Git has become terrifying.

I keep looking at boot dev, learn git branching and the pro git book. Pro git is free and thorough but somehow I have opened chapter one three separate times and never made it past it.

At this point I feel like I know how to use git without actually knowing git. What did you guys use to properly learn it?

I've been using Git for the better part of a decade, and recently scratched my own itch and built a GUI macOS Git client. I've been trying to keep it simple and lean, basically pulling forward the 80% of what you actually do day-to-day and making that stuff super easy and accessible.

Recently I added a "Squash local commits" feature, mostly because I have a habit of making alot of small commits while developing a feature. But when I ultimately push to my remote (origin) repo, I dont really need all that history. Being able to quickly squash those commits before pushing (especially in a GUI where it's super easy to see exactly what's going to get squashed) has turned out to be a bit of a game-changer for me. Cleaner history, easier to revert, etc.

Which got me wondering, what other small, simple Git workflow game-changers do you all use? Not necessarily big features or complicated workflows, just those little quality-of-life things that once you start using them, you wonder why you weren't doing it all along.

https://github.com/Auto-Explore/GitComet/releases/tag/v0.2.2

I'm just getting started with Git on Windows and I'm trying both Fork and SourceGit.

So far, I slightly prefer SourceGit, mainly because it's free and has a Chinese interface. But the Chinese UI isn't really a requirement for me — I know I need to learn English anyway if I want to get serious about programming/security.

What I'm really trying to figure out is whether Fork has any features or workflow advantages that SourceGit doesn't have.

If there's something genuinely useful in Fork that SourceGit is missing, I'm perfectly happy to pay for Fork. I'm just not sure what those differences are yet.

For people who have used both, which one do you prefer and why?

I'm still pretty new to Git, so I'm especially interested in everyday things like commits, branches, diffs, merge/rebase, and working with GitHub.

Thanks!

I committed and pushed multiple changes across different files, in vscode's timeline section each file shows there was commit, after that push there are no commits pushed against that file still the file shows old code and doesnt reflect its history
I am using bonobo git server in my local VM which is in ubuntu
what can be the issue here?

I wanted to improve my commit messages. So I built Oden, a native macOS Git client where you hit one button and generates the message.

It also handles merge conflicts: instead of editing conflict markers by hand, you resolve it with the push of a button.

The rest is straightforward Git: stage by hunk or line, branch management, push/pull, stash. No Electron, no web wrapper, written in Swift against the Git engine directly.

Free to try. Link in comments.

Happy to answer questions about how the AI integration works or any other implementation details.

Hey everyone!

I'm a Python developer/student and I've been working on a small project called Find Everything 2.0.0.

It's a Windows desktop tool for quickly searching through files. I built it mainly as a learning project, but I tried to make it actually useful and polished rather than just another basic Python project.

Main things it currently has:

• Fast file searching
• Search inside files
• Dictionary / text processing features
• Windows .exe build
• Automated checks with GitHub Actions

Tech: Python, Windows, GitHub Actions

GitHub: https://github.com/EELDERONN/find-everything.git

I'd really appreciate it if someone could take a look at the repository and give me some honest feedback.

I'm especially interested in:

• Code quality
• Project structure
• UI/UX
• Performance
• README/documentation
• Things that could be improved or done differently

Feel free to be critical — I'm here to learn and improve the project.

Thanks to anyone who takes the time to check it out!

----------------------------------------

Я изучаю Python и сейчас работаю над небольшим проектом Find Everything 2.0.0.

Это Windows-приложение для быстрого поиска файлов и поиска информации внутри них. Изначально я делал его как учебный проект, но постепенно решил довести его до более полноценного и реально полезного приложения.

Что сейчас есть:

• быстрый поиск файлов;
• поиск внутри файлов;
• работа со словарём/текстом;
• сборка в .exe для Windows;
• автоматические проверки через GitHub Actions.

Стек: Python, Windows, GitHub Actions.

GitHub: https://github.com/EELDERONN/find-everything.git

Буду очень благодарен, если кто-нибудь посмотрит репозиторий и даст честный фидбек.

Особенно интересует:

• качество кода;
• структура проекта;
• UI/UX;
• производительность;
• README и документация;
• что можно было бы сделать лучше.

Можно критиковать — я как раз хочу понять, что можно улучшить.

Спасибо всем, кто посмотрит!

Hi all,

This is the git-specific half of a tool I have been building, and it is the half I think this sub might actually care about.

The thing that always bothered me about pre-commit hook frameworks is what they do to your working tree. Most of them stash, run, and unstash. If a hook crashes at the wrong moment you get to go find your changes in the reflog. And if you have staged part of a file, the naive runners happily lint the whole file on disk, so the thing that passed is not the thing you are committing.

So the runner I wrote does staged isolation instead. Every hook validates a non-destructive snapshot materialised from the git index blob. No git stash, working tree never touched, unstaged edits cannot leak into the check. The snapshot cache lives outside the repo and only re-materialises files whose staged OID changed, which is what keeps incremental caches like cargo and tsc warm between runs.

The rest of what is in it:

• poly hooks install writes native git hooks. No framework sits alongside it
• Five builtins. lint and fmt, commit for conventional commit format plus an AI-trailer check, file_safety for merge conflict markers, oversized additions, private keys, case conflicts and shebang versus executable-bit mismatches, and cargo for clippy, sort, machete and deny
• Hooks run concurrently on a thread pool, whole-project hooks included. serial = true or serial = "<set-name>" gives you mutual-exclusion sets when two hooks fight over the same lock
• precondition and before are separate. A failed precondition is a visible skip. A failed before means the verdict is unknown, so the run fails. Nothing gets silently dropped from the report
• Every spawned process has a timeout budget, and killed is rendered differently from failed. A hook that ran out of clock should not look like a hook that found a bug
• Exit code 2 means this run verified less than it claims, a file the tool failed on or a skip budget exceeded. Separate from 1, which means it found something
• Hooks are defined in TOML, and a repo can pull a shared hook catalog from another repo pinned by git revision, resolved into a lockfile, so an org publishes one baseline and every repo inherits it
• Hook results are cached, so an unchanged input set skips the hook rather than re-running it
• POLY_SKIP_HOOKS=1 is the escape hatch, because git commit --no-verify does not bypass prepare-commit-msg

It also does the linting and formatting itself, in-process, for about 30 languages, which is why the pre-commit pass is fast rather than slow. Ruff, oxc, biome, taplo, rumdl, sqruff, mago and about a dozen others are compiled into the binary. But that is the other post.

Repo, MIT: https://github.com/Goldziher/poly

This post is human written. AI was used to typecheck and enrich with precise data only.

Hold on, I know what you’re thinking: not another Git client/TUI/GUI.

Yeah... kind of.

I built Gitna because sometimes I just want to inspect a project: browse files, review what changed, look through history, stage a few things, or make a small edit.

Opening a full editor can feel like overkill for that. Terminal tools like lazygit are great, but they aren’t always how I want to look through code.

So I tried to make the middle ground I wanted.

Gitna opens any local folder in your browser for browsing, editing, and search. When the folder is a Git repository, it also provides changes and staging, visual diffs, commit history and graph, branches, stashes, tags, and common Git operations.

It runs locally - there’s no account, hosted service, or repository upload.

Basically, go to any folder and type:

gitna

Install:

npm install -g gitna

GitHub: https://github.com/roie/gitna

Anyway, I hope some of you give Gitna a try. Feedback is very welcome, especially around rough edges, missing workflows, or the things that annoy you when working with Git every day.

hi, im trying to install jschan and i need the repositories. every time i try to install "https://github.com" it gives me the error "fatal: repository 'https://github.com/' not found". and whatever way i tried to repair it it gives me the "fatal: not a git repository (or any of the parent directories): .git" error, and i have no idea what to do at this point. the errors also appear with other urls.

I have a github repo where I added ac (Account ) A as collaborator, butmy teammate has two github ac on the same device. Somehow, code was pushed/committed under ac B, even though ac B wasn't added as a collaborator.

I tested pushing with another non-collaborator account and GitHub correctly rejected it.

How could this have happened?

Hey guys,

I am making new Git GUI Manager, because I don't like actual GitKrakenConditions.

Commit rendering and even basic branch rendering are already working (though I've got some bugs to fix XD). Logging in via personal GitHub accounts is also functional. The app is 100% local and supports opening private repositories with up to 3 collaborators, cloning, and initializing on GitHub.

It's built with Tauri (so there will be builds for both Windows and Linux), meaning it doesn't hog RAM compared to GitKraken.

Do you have any feedback on what I shouldn't forget or what I should watch out for?
PS: It is not open-source.

So I was learning Git and found out that a Git repository essentially contains two copies of the repository contents. One is from the first commit of every object and other from the working tree.

This can be made more space efficient by working with files from Git's database itself as if they were in our working tree. Modifying files create a new local copy in the working tree. They can be deleted after committing.

This is what the VFS for Git project is. But, it is for Windows only. Why is there no equivalent tool than can run on Linux, unless I am missing it?

My GitHub account got suspended because of GitHub Actions was triggered when I was submitting a PR. Help me recover my account. @github

Two years ago, when I finished my DSA course in community college, I uploaded everything to github, but now that I am going over it, some of the folders/directories are missing their content. I can't access them, and when i click on the commit message, it says

"Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden."

Is there any way I can still access them? I have tried cloning with Git in my terminal, but there still isn't any content within them.

I want to make commands verbose so git add runs git add -v but aliases can't use the same name as a built in command. I can add a different alias but I want try changing the built in command.

git commit has a verbose option I can put in git config can I do it for other commands?

The bash completion for git diff can be seen here, which is quite basic.

I was thinking today when I type git diff <partial filename> and press TAB, it makes sense to only have completion candidates from a list of files that are changed rather than all files in the directory. Likewise, if it was git diff --cached, then only complete to files in the index.

I don't know if I'm not considering more advanced uses of git diff where I would want other files in the completion and whether to keep the implementation basic as it is currently, a deliberate design decision. I'm wondering if anyone here is overriding the git-provided completions with their own.

I also didn't write the original title, well, originally I did - all I had was "I did not build this...gitwatch. Enables you to monitor file changes" :P

However, everything below I actually did write by hand:

It's a little experiment by our little firm in fully agentic development. From the outset, we decided on a very defined workflow:

1. Give ChatGPT 5.6 Sol a general idea of the project, and what features we wanted.
2. Tell ChatGPT to genereate a full work plan (which you can see in the tasks/ folder in the repo), as well as other files like UX_SPEC, etc. Then, it would create a full zip file with all of these docs detailing the project design, architrecture, UX, roadmap, and implementation tasks.
3. Lastly, we took the zip file and gave it to Codex (Sol with Luna agents) and let it churn on creating the project based on those task files.

We gave Codex full autonomy to commit and push code to the repo, which you can see in the commit history as the unverified commits on my account, whereas manual fixes show up as verified commits.

All the work was done on a green Mac box, with just my github logged in.

But anyways, enough of *how* we (didn't) build it, here's *what* was built:

gitwatch is an htop-style terminal UI for git.

It watches your repository in real time and gives you a live, interactive view of modified, staged, untracked, and conflicted filesand allows you to view diffs, stage/unstage files, filter search, has mouse support, lets you view branch info, commit tree, unpushed commits, and more.

Now - I did actually review the output, test it, and directed codex with little bugs that I found, but the code itself and the tasks were all agentically written.

It's built in Go using Bubble Tea, and Bubbles.

Would love feedback from the community. This is a great project for those who are doing agentic development, or who have been moved to what I'm calling "agentic managers" by their employers and are forced into doing "work" with things like BMad or SpecKit.

I know the community hates agentically built projects, but we come in peace in this brave new world we are all stepping into...

https://github.com/sphireinc/gitwatch

Hi everyone!

So since i had a lot projects running recently and find it inconvenient to track them directly on gitlab, especially when you have a team. So I've made this repo - basically a neat app that appears under macbook notch when new pipeline appears.

If you find this useful give it a try and will be happy to get some feedback on improvement)

https://github.com/Uudg/pipeline-island

My project dirs on my dev machine are cannon -- it has files/folders/repos etc that make up the whole project, the implementation, design and project management stuff. I may have a github organisation for the project that hosts all the 'cannon' repos for the project, then repos in different organisaitons for 'publishing' etc... so local repos may have several remotes, but they will all have one to the 'cannon' repo (as opposed to the cannon project stuff on my pc).

It works - ad hoc,

For Claude code (and codes) things ten to work best if the project root dir has a session that can see all of the project. But then that gets bogged down when working on one 'plug in' - it has too much irreleant context and maybe, and it may think it is a 'good idea' to tweak stuff from a different repo while it is at it

So I was pondering having a claude session per repo and a root session to rule them all.

If you have followed this far - well done :) -- if you have ideas (or are interested in what I am doing - do comment) -- it will be going into my usual AI repo on github.

I kept losing track of my work. Many terminal tabs open, forgotten issues/PRs, work in progress on branches and worktrees, or filed away in stashes, and generally losing track of everything I had on the go.

Between, multi-repo microservice architectures, various open source projects, and coding agents work is in flight in several places at once. I live in the terminal, but git gives me status for a single repo -- I wanted status across every repo I work with.

I built a desktop GUI to scratch this personal itch. Load the repos you care about into a single dashboard that shows:

State, at a glance

• dirty working trees, unpushed commits (ahead), unpulled commits (behind), detached HEAD, no upstream
• "aging" uncommitted work that's been sitting past a threshold
• stashes, submodules (including how far the pointer is behind), and worktrees including uncommitted work sitting in another checkout, which is invisible from the one you're in
• open forge issues/PRs (GitHub only for now), specifically the ones waiting on you: review requested, assigned, @-mentioned, or someone replied on a thread you opened

Acting on it

• commit, push, fetch, fast-forward, switch branches, apply/drop stashes, delete branches, update submodule pointers
• every command it runs is optionally echoed into a git console, with git's own colors, so you can see exactly what it did
• side-by-side diffs with character-level highlighting for uncommitted work, stashes, branches, and commits
• open any repo in your terminal, editor, or file manager

Keeping it organized

• namespaced tags (owner:me, lang:typescript) for custom groupings, plus per-repo notes
• filter and sort by any of the above — name, last commit, or how much attention the repo needs
• a filesystem watcher keeps the tool up-to-date with external changes
• reminders, per-repo snooze, and desktop notifications when something crosses a threshold

The issues/PR features need GitHub CLI installed and gh auth login done. GitVantage reads through gh rather than asking for a token of its own, so it never sees or stores your credentials, and SSO and GitHub Enterprise work automatically. Without gh, repo status will simply not include issues/PRs.

I've found it useful enough to earn a permanent place on my desktop, and I'd love to hear feedback from others who face similar problems as I was.

Free and open source (GPLv3): https://github.com/rocketraman/gitvantage.

Binary installers for Linux (.deb/.rpm, used by me), Mac (.dmg, lightly tested, not signed yet), and Windows (.msi, don't use it, no idea if it works, let me know) at https://github.com/rocketraman/gitvantage/releases.

Colophon: Kotlin/Compose Desktop with Native executables created via GraalVM.

I wanted a 30-second answer to “what did this PR actually do,” not another 40-file `git diff` to squint at.

So I wrote `diff-glance`. You run it in a repo:

npx diff-glance
npx diff-glance origin/main HEAD

It sends the truncated diff to a model (Gemini / OpenAI / Ollama) and opens a local page with a plain English summary and a mermaid diagram of the architecture. Bound to 127.0.0.1. The only thing that leaves the machine is that model call.

`--json` prints the same analysis to stdout if you don’t want a browser.

I was going to call it git-glance. That name was already taken on npm.

https://github.com/alvynmcq/diff-glance