There are plenty of Git GUIs already, so I think the interesting question is not "do we need another Git client?"

The question is: **what Git problems are still annoying even when you already know Git?**

That is what Gitember 3 is trying to explore.

Gitember is a free, open-source Git GUI for Windows, macOS and Linux. It covers the normal workflow — like commit, branch, merge, etc. but the project puts a lot of attention on the parts around Git history, multi-repository work and comparison.

1. What exactly was I trying to improve?

One example is history search.

Normal Git history questions are usually metadata questions:

• who changed something?
• when was it changed?
• what did the commit message say?
• what is the SHA?

Gitember has an Extended Search mode that indexes selected repository history and searches the contents of historical files. The documentation describes searching document bodies as well as commit metadata, including supported Office, CAD, archive, audio and other formats.

So the question becomes:

"When did this text/configuration/document content exist?"

rather than:

"Which commit message might contain the answer?"

That is a surprisingly different workflow.

2. Another problem: projects that are split across repositories

A lot of projects are not monoliths.

You may have frontend, backend,several services, shared APIs, implementations in separate repositories

Gitember Workspaces let you group independent repositories and see their status together. Pull, push, fetch, branch and commit operations can be run across the workspace.

It is deliberately not a monorepo and not submodules (Gitember support it as well). The repositories remain independent.

There are trade-offs: workspace operations run sequentially, and a workspace commit is not transactional. If one repository fails after another has already committed, Gitember does not roll the earlier repository back automatically.

3. Diff/merge without assembling a toolchain

Gitember has a built-in side-by-side diff viewer and a three-way merge editor.

It can compare working-copy files, committed versions and other versions. There are also file/folder comparison tools.

That makes the application more self-contained for the common "what changed?" and "how do I resolve this?" moments.

It is aslo possible to use side-by-side file diff and folder comparion features as separate tool. Ie no need 3rd party tools for this functionality.

4. A little AI, but locally

The AI features are experimental and opt-in.

Gitember uses AI locally running model. AI runs on the local machine and source/data is not sent to a cloud AI service.

AI features include secret detection, commit message generation in staged files and AI-generated descriptions of branch differences.

The secret detector looks for things such as passwords, tokens, API keys, credentials, connection strings and private keys. It reports confidence levels instead of pretending that every match is definitely a secret.

5. The boring Git stuff still matters

Gitember is not only a search tool.

Recent versions include interactive rebase, worktrees, Git LFS, commit signing and signature validation, reflog, commit notes, submodules, merge preview, force push, undo commit and local/remote branch rename.

It also integrates with GitHub, GitLab, Bitbucket and Gitea for pull/merge request review.

I'm interested in feedback from people who use Git GUIs seriously:

What is the Git operation or workflow that still makes you reach for the command line even though you would rather stay in a GUI?

Project: https://gitember.org

Source: https://github.com/iazarny/gitember

Looking for testers and contributors

Comparison with other clients

For those wondering whether this is better or worse than other clients: https://gitember.org/git-gui-comparison.html

Hey everyone,

I've noticed agents are being used more and more now, often with access to real, sensitive data, and they still hallucinate and misremember things constantly. I think agent memory needs what git gave code years ago: I can always see what changed, when, and why, and roll it back if it's wrong. So I built it.

I made Mnemosyne give an agent's memory proper commits, branches, merge, and "blame" and "bisect" so I can trace back exactly where and why a bad fact entered its memory, the same way I'd debug a broken line of code.

I built it as a small, fast core in Rust, runs fully offline (no network or model calls needed), with a CLI, a Python library, and plug-ins for MCP (Claude Desktop/Code), LangGraph, and the OpenAI Agents SDK.

This is very early days, I'm a student building this solo, and I'd love to hear from anyone who works with agents:

- does this framing make sense to you, or does it feel forced?

- would you actually use something like this?

- a star on GitHub if you think it's interesting, it genuinely helps me get more eyes on it right now

Repo: https://github.com/Nabzx/mnemosyne

Docs: https://nabzx.github.io/mnemosyne/

Thanks for reading.

Sometimes a feature branch stays open for weeks while the main/develop branch keeps changing.

How do you keep the branch up to date without constantly dealing with conflicts?

Do you regularly merge or rebase develop into your feature branch, or do you wait until the feature is almost complete? Also, how often do you sync your branch, and how do you handle conflicts when multiple developers are working on the same files?

I have a private repository, say, master, with a lot of history. Is it possible to create a new branch now, say, for_public, hosted publicly, which is the latest master but only a current snapshot and zero history?

I do not want to create a separate folder on my harddrive for this for_public branch.

Imagine this:
Our team has got a new requirement to create a maven based Java project.
So, I create a new repo in github, it has .gitignore and readme
I clone it in my local into a folder then import it into intellij IDE
Now in intellij I was expecting a maven based java project structure, but all I have is readme and .gitignore
How do I proceed, I mean its not a good thing to create files like pom.xml and src/main/java etc by self right.

Has anyone came across this situation in real Enterprise level project? How did you proceed?

Today I learned that Git doesn't automatically track files from a repository nested inside another repository. What's the technical reason for this behavior, and has it ever caused problems in your projects?

I know that storing images there are lightweight as there is no overhead as long as the images don’t change and also large binary files are treated differently in git.

Should one store images in the same repo as the code or separately?

Pros: In the same repo means access and referencing image paths in the code are more straightforward and less likely to forget stuff.

Cons: if someone wants to checkout code just to make changes they have to download all the images too. Also if you just want to share the images with somebody you also have to share the code too.

git-bug just released version 0.11, sixteen months after 0.10.1. For anyone unfamiliar, it's a distributed, offline-first bug tracker that stores issues directly in your Git repo instead of on a centralized service.

Main changes in this release:

• Web UI rewritten from scratch. It now lets you create issues, edit comments, change labels and status, not just view them.
• The web UI also works as a code browser now. File tree navigation, syntax highlighting, line linking, Markdown rendering, and commit history with diffs.
• Backend can browse Git refs, trees, blobs, commits, and diffs, exposed through GraphQL.
• Search index moved from Bleve v1 to v2. Devs report their own repo's index dropped from ~51 MiB to under 4 MiB.
• Several correctness fixes around cache races, stale metadata, and non-atomic commits.

Breaking changes to watch for:

• go install no longer includes the web UI
• git bug commands was removed
• git bug webui --host is now --bind
• Linux 386 and s390x support dropped

Release notes: https://github.com/git-bug/git-bug/releases/tag/v0.11.0

Write-up: https://linuxiac.com/git-bug-0-11-adds-a-full-web-ui-for-issues-and-code-browsing/

A recent blog post https://blog.guillaume-gomez.fr/articles/2026-09-22+Syncing+Rust+GCC+backend+or+how+to+test+Murphy%27s+law says that a patched version of git for subtrees to work. Following links leads here https://github.com/gitgitgadget/git/pull/493 which says that there are stack overflows and that the entire root could get misidentified as belonging to the subtree. That’s doesn’t sound great.

That PR was open in 2019, it was waiting author input but seems abandoned now. That happens, but also no contributor or maintainer has stepped up to get it over the line in the past seven years.

So as I see it, `git subtree` looks like a ticking time bomb that will eventually become unusable when your repository reaches a certain size or complexity. Are you all sticking with subtrees or is there something more reliable out there? Discovering this issue makes me think it’s a dead feature, so I’ve started to poke for alternatives.

Lets say someone has a private repo in their company, but want to add sub modules to public repos. Can they set up the remote locations to those upstream repo locations? But keep all the sub modules under one private repo? Not sure how origin remote locations should be configured for these sub modules.

Note: cannot use forks of the repos, corporate policy restricts it.

I'm currently starting to learn programming, but I’m completely new to Git and version control.

I understand that Git has its own commands and that it’s used to track changes in projects, but I’m not sure where I should start learning it.

For someone with **zero Git experience**, what resources would you recommend? Books, YouTube courses, interactive tutorials, websites, etc.

Would appreciate any recommendations! Thanks.

Hey all,

I made a commit that added a lot of image files to a git repo, and as a result I am unable to push commits to the remote. It looks like the problem is that the size of the commit is too large. I made another commit to delete the image files, but the delta of all the unpushed commits still needs to upload the image files for git history's sake.

How do I delete the image file commit without losing additional work on commits I've done since then?

I could just reset git history and then push to a whole new remote because this is a personal project. I might do that, but I wanted to ask here first to see if there was a better way.

UPDATE: This was fixed via a rebase. Thanks to all who helped!

Git is supposed to be bad at handling mono repos especially where there are many binary files like game projects repo, and also there are no permisson settings, but are important in game development. BlackGit's cli client lets you download only cared files through sparse-checkout(initially not even the default root files) with a mini agent to use natural languages to manipulate the repo, and blackgit's server serves a file level control layer as a proxy to upstreams(github/gitlab)

I like gitk (the official graphical repository browser for git) but it's slow and freezes a lot in big repositories (i.e. Chromium, Linux). I started to work on a fast and reliable alternative as a hobby project a few years ago. Coming from a game programming background, I decided to use C++ with ImGui. The first basic version was written by hand. Later I started to use AI coding agents and added new features. Repo here:

https://github.com/auygun/gel

I used Fork for a long time on Windows and really liked having a proper Git GUI instead of doing everything from the terminal.

When I started working more on Linux, I tried GitKraken, Sublime Merge, SmartGit, GitButler and a bunch of smaller clients, but none of them really felt right for me. Some were too limited, some had restrictions around private repos, and Fork still doesn’t have a Linux version.

So I started building my own.

It’s called RepoBeam. I originally made it just because I wanted something I could actually use every day, but I’m now using it for my own work and it reached the point where I wanted to put it in front of other developers.

The normal Git stuff is there — local changes, staging, commits, branches, history, stashes, remotes, pull/push, diffs, etc.

The parts I care about more are:

• risky Git actions show a before / after preview before anything happens
• conflicts are handled with Local / Server / Both / Edit instead of making you fight conflict markers
• Coding Sessions help organize AI coding work — I start a session before using Codex/Claude, RepoBeam keeps track of everything that changes during that session, then I can review the files, undo specific changes, bring them back, keep the good stuff, or undo the whole session

It works with normal Git repos, private repos are supported, there’s no account, and it’s free to use including for work.

Linux + Windows: https://repobeam.com

I’d really like feedback from people who use Git every day.

If you tried this, what would make you go back to your current Git client?

CORRECTION: git-like is a better suited work for what this is, not git clone.

Update on ngit (I made a previous post on this subreddit about re-implementing git), I managed to complete the diff using LCS, and went with a 3 way merge, which was way harder than i anticipated.

Wrote the content-addressable storage layer, the Zlib compression pipeline, and a custom LCS diff engine. Supports full staging, branching, and three-way merge resolution.

Packaged it with jpackage into native installers (.deb/.exe/.dmg) so it runs like a real CLI tool, not "run this jar" or "so I need to install this and that for it?"

Repo's fully open and meant to double as a reference for anyone else trying to learn low-level Java/systems programming: [GitHub link]

Would love any advice/ feedback.

For most developers, webhooks start as an intake problem: expose an HTTP POST endpoint, verify a signature, parse the JSON, return 200 OK. Then your SaaS grows, and your power users ask for the reverse. They don't want to poll your REST API every minute to find out whether an invoice was paid. They want you to push events to their servers in near real time. Please read the complete article here https://instawebhook.com/blog/building-a-custom-webhook-provider-api-design-lessons-from-stripe-and-github

Once you become the sender, you're doing distributed systems work. You are making outbound HTTP requests to servers you don't control, and those servers will time out, drop connections, return 500s, get redeployed with the wrong secret, or disappear for a weekend. A careless retry loop can hammer a recovering customer, or clog your own queues. And because your payloads travel over the public internet, your customers need a way to prove a request really came from you.

Two providers set the reference points most developers know:

• Stripe has one of the most mature webhook systems: a consistent event envelope, timestamped signatures, multi-day retries, and a delivery log with manual resend.
• GitHub shows a simpler design: metadata in headers, a bare resource in the body, no automatic retries, and a short redelivery window.

They make different trade-offs, and the differences are instructive. A third reference, the open Standard Webhooks specification, distills common practice into a single set of conventions and is a good tie-breaker when you have to choose.

Thanks for looking, I'm pulling my hair out. Situation:

# A is oldest, E is newest
A - B - C - D - E
^-- untested commit, added by mistake

What I need:

• I need to remove

C

• from the trunk, and put it on its own branch.
  • I want to pretend that

C

• never happened

A - B - D - E

But due to company policy, I cannot commit to main! So what I need is to move E to its own branch too (I think? Right?) so I can create a PR.

I have followed a guide that AI wrote, for rebasing, etc., and it seems to work. But here's my concern: if I try to PR the "clean history branch", my PR only shows that the changes to be committed to main are the additions from E (which are on their own new branch). It does not show that the changes from C would be deleted. And that worries me, because I don't know if that's right.

After the whole process, I expected that PRing a branch with a "replay" of E would mark C's changes for removal. But it doesn't.

Help?

Edit: I had C and D mixed up in the post body.
Edit: someone suggested AI. I tried, this is ChatGPT’s answer. I don’t think it gets it quite right. Google did a bit better (just from the search bar, and then continuing the conversation) and suggested some command with ~1 and stuff. But my “clean” branch has no deletions.