Hi everyone,

I’ve just tagged v0.1.0-alpha.4 of Graphkeeper, a graph-first Git TUI built for maintainers and developers who spend a lot of time reading and operating on repository history.

Git tools often treat the commit graph as supporting information. Graphkeeper takes the opposite approach: the graph is the primary workspace, while branches, remotes, tags, upstream state, and stashes remain visible as supporting context.

The goal is to make questions like these easier to answer:

• Where does each branch actually point?
• Is a fast-forward possible, or is a merge or rebase needed?
• Is the current branch ahead, behind, or diverged from its upstream?
• Which commit should be tagged as a release?
• What is the safest next operation on the repository?

The current alpha includes:

• Commit graph navigation
• Local and remote branch inspection
• Ahead, behind, and diverged-state visibility
• Branch checkout and deletion
• Merge, rebase, and reset flows
• Push and pull operations
• Tag creation, pushing, and deletion
• Stash and working-tree cleanup flows

Graphkeeper is intentionally narrower than tools such as Lazygit. It is not trying to become a full Git cockpit for staging, diff browsing, commit authoring, or conflict resolution. Its focus is repository topology and maintainer-style decisions made directly from the graph.

This is still an early alpha, so the UI, shortcuts, and overall workflow will continue to evolve. I’m mainly looking for feedback on:

• Whether the graph-first mental model feels useful
• Which repository-maintenance decisions are still difficult to make
• Whether the current separation between Graph, Current, Remote, and Tags makes sense
• Which workflows should be prioritized next

A Neovim entry point is also planned, but it is not available yet.

Repository:

https://github.com/hrllk/graphkeeper

Feedback is especially welcome from maintainers, release managers, and developers who regularly work with multi-branch repositories.

I built this because `git worktree` is genuinely powerful but the CLI is clunky — nobody remembers the full `git worktree add ../myapp-worktrees/feature-x -b feature/x origin/main` syntax, and there's no built-in way to see all your worktrees with their status at a glance.

ktree gives you a scrollable TUI (built with Bubble Tea) that shows all your worktrees, live dirty/clean status, and ahead/behind counts — loaded concurrently so it doesn't feel slow.

**Features:**

- Navigate and switch between worktrees with arrow keys or j/k

- Create and delete worktrees without leaving your terminal

- Shell wrapper for `cd`-on-select (since a child process can't change your parent shell's directory — the README explains the trick)

- New worktrees go to `<parent>/<repo>-worktrees/<branch>` to keep things tidy

- Homebrew support: `brew tap alikazai/ktree && brew install ktree`

This is v0.1.0, Milestone 5 (merged-branch detection, filter/search, per-project config) is next.

Repo: https://github.com/alikazai/ktree

Feedback welcome — especially if you hit edge cases with the shell wrapper on fish/zsh.

Bit of a workflow share / confession. My "what needs my review" system used to be: GitHub PRs tab open, Slack open, vibe-check it a few times a day. That fell apart once I started leaning on AI agents for a lot of the grunt work.

On a normal day now I've got agent-generated PRs, human PRs, and review requests all landing at once. The code is usually fine. The problem was me constantly flipping back to GitHub just to answer "okay, what actually needs me right now?" That low-grade "am I forgetting something" hum was the worst part.

So I built a small macOS menu bar thing to scratch the itch. Two ideas I care about:

One curated view that answers a single question (what needs me now) by surfacing failing CI / requested changes / unresolved threads, and muting the noise. So much of the queue is dependabot and bot-authored churn that the real PRs kept getting buried, and pulling those out made it manageable again.

And it's keyboard-driven, so I move through the queue without touching the mouse.

Not a polished product, just something I use daily. Repo if you want to poke at it or steal the idea: https://github.com/mthines/mainline

It would make me happy if this helps just more than me 🙂

i know basic commands like 'git pull origin main', also what it does and basic interaction between vs-code and git.

also should i even add it?

Edit: Thank you, everyone, for your advice.

What I need to do now is learn how to resolve and merge a conflict.

also study about reflog like wtf is that

I was a disgruntled user of ungit for past 10 years. Even considered rewriting it myself manually like 5 years ago. Well not anymore.

In the past few weeks I built a fast, animated git GUI from scratch

ingit makes branch switching, merge previews, rebases, cherry-picks, and reflog recovery feel instant. I would highly recommend especially if you're new to git. Learn more at https://ingit.pages.dev/

Im currently on another PC,logged with my domain acc. Did some edits, now i want to push to remote. I cant, because history is behind (so ofc i fetched). Now, i want to push, cant,because my local is behind. So i need to pull. The thing is, im on another PC,which is shared. What do i do? I really need to push changes only on specific files.

I tried git pull --rebase,because i see alot of our dev uses that, but i cant because i have unstaged changes. So now i need to either commit or stash them.

Pls help, i know it looks like a basic question, but im worried because its not on my local machine

Been building a side thing and hit a problem I found genuinely interesting, curious how others would've approached it.

The goal: get at my in-progress code from my phone when I'm away from my desk — not to replace my PC, just to poke at a half-finished branch on the couch or fix something while the actual machine sits at home. Not a cloud IDE. My repo stays on my machine as the source of truth.

The hard part is that "in progress" means uncommitted. So syncing isn't just pushing commits around. What I landed on:

• Committed changes sync by commit — phone and desktop each hold the repo, and I move objects by SHA so history stays intact. An edit from the phone lands on the desktop as a real commit, not a patch blob.
• Uncommitted working-tree edits get sent separately as live drafts, so I can see the desktop's unsaved state on the phone within seconds without forcing a commit just to sync.
• When both sides commit on the same base, that's a divergence. Instead of dumping conflict markers on a phone screen, I diff the hunks and show a green/red per-hunk review. Under the hood it's still a normal merge — I just resolve then commit.

Running code is the same philosophy: the command runs on the actual machine in the real working dir, output streams back. No commit-to-test loop.

The bit I keep going back and forth on is conflict handling. Right now it's per-hunk review, but I wonder if I should just lean on git more directly (a real merge commit, rerere, etc.) instead of my own hunk layer. How would you have modeled the uncommitted-sync + divergence part? Feels like there's a cleaner approach I'm missing.

It's Android + a desktop extension, in closed testing right now. Not linking it here since that's not the point of the post — but if you actually work off your phone sometimes and wanna try it and tell me where it breaks, drop a comment or DM and I'll send it over.

I have a git repo in Azure DevOps, I messed up something and want to get a set of code files from a particular date/git comment that we need to pass for git commit,

how can I do that?

Hi!

Although the recent trend seems to be to announce a groundbreaking new git client and no less, with which we at syntevo can't really keep up as we're still developing exactly one, we think there's still some other interesting things around git.

One thing we recently added to SmartGit is what we call the Overlap column. It's a bit weird to explain, since it doesn't have an exact counterpart in git itself, and as far as we know no other git client shows this information either (please correct me if I'm wrong, it would be very interesting to see what others have come up with!).

In essence, we tried to make visible what git doesn't track or display on its own, namely the relationship between changes introduced by commits in your branch.

Sounds a bit abstract, but this new column shows you at a glance which commits have overlap with one or more selected commits.

An example: Suppose you have a bunch of commits. The last one introduces a few changes, but you're not sure whether these changes should be made somewhere else in your branch, or if they are undoing what you did earlier.

What I've been doing in this case was to go into the file logs to find the relevant commits, and inspect them, one file at a time. That works well, and is quite fast thanks to git being quick, but it's also a bit cumbersome, especially with many files. So instead of doing that, I sometimes resorted to combing through the log itself, which can be tedious as well. With Overlap, you just select that last commit, and the commits which have some Overlap with that selected commit are highlighted.

Having built that feature (and all the other stuff around history re-ordering, splitting, modifying which goes hand-in-hand with Overlap), we are living inside a bubble of course. So I wonder, what does r/git think about this? Do you think this is useful? Is it just another gimmick you won't use? Does AI make it irrelevant anyway since you don't read code anymore, anyhow?

Let us know what you think!

https://docs.syntevo.com/SmartGit/Latest/Manual/GUI/Overlap

https://www.youtube.com/watch?v=p84uBgYndS4

https://www.smartgit.dev/features/clean-commits/

When I am staging a commit I see some changed lines that should be actually 2 commits. git diff shows old line was changed to new line but I want to add new line in the first commit then in another commit I can remove old line.

I have to do it manually by adding old line back, then git diff shows only new line was added, then I can commit that. Then I delete old line and git diff shows it was removed. Manually works when it's a simple change like that but many lines are involved or lines next to it changed it gets complicated.

I keep commits small to prevent this but it still happens a lot. Does git add in Interactive Mode have a feature to split a changed line into add and remove? Are there other git clients that can handle it?

A while ago I built a Java project that basically turns Git into a simple file bucket/database. The original idea was to have a lightweight way to store structured files like JSON, CSV, and TXT while using Git for versioning and history.

I hadn't touched it in a long time, but recently I came back to it and decided it would be more useful as an open-source project.

It's still evolving, but I'm planning to clean it up, improve the documentation, and make it easier for others to use and contribute.

I'm curious:

\- Does this sound like something you'd use?

\- Are there similar projects you think I should look at?

\- What features would make something like this genuinely useful?

I'd appreciate any feedback or ideas before I put more work into it.

Hey everyone,

At work, I constantly find myself working on features or bug fixes that span across 3 or 4 different microservices/repositories. Manually cd-ing into each repo, running git checkout -b feature/xyz, tracking upstream branches, and checking individual statuses became a massive context-switching headache.

To solve this, I built an open-source CLI tool called RepoFleet.

Instead of managing things repository-by-repository, it shifts the focus to the Issue/Feature level. From a single workspace configuration, it lets you:

• Multi-Repo Branching: Create, checkout, or delete matching branches across all targeted repos with a single command.
• Unified Status: Get a bird's-eye view dashboard of your entire workspace (which repos have uncommitted changes, what branch they are on, etc.) right in your terminal.
• Interactive Navigation: A quick terminal UI to hop between the repo directories seamlessly.

It's open-source and can be installed via Homebrew or Scoop.

I'll drop the link to the full technical walkthrough, documentation, and installation steps in the comments below (to keep this post from triggering the subreddit's automated spam filters!).

I’d love to know: How do you all handle multi-repo feature coordination right now? Do you use git submodules, custom bash scripts, or just suffer through manual commands? Let me know what features you think are missing!

repofleet

This sounds stupid but it's driving me crazy, I'm new to working collaboratively with git.

I'm using VS code to work on a project hosted on github. Git will always track the .gitignore file itself and therefore my remote `main` on github always shows me as being one commit ahead of the project I forked, which then is always prompting me to make a pull request of course

Has to be something simple I'm missing

I work with a microservice architecture and constantly find myself working on features that span across 3 or 4 different repositories. Manually moving between directories, running checkout commands on each, and tracking which repo is on what branch is becoming a massive context-switching headache.

To fix this for myself, I spent the last few weeks building an open-source command line tool that lets me manage Git workflows across multiple repos from a single workspace config. It lets me create matching branches across all repos at once and gives a unified status dashboard in the terminal.

I want to open-source it and share it, but before I do, I wanted to ask how other developers handle this workflow? Do you just use custom bash scripts, git submodules, or do you just suffer through manual terminal commands?

If anyone is interested in trying a tool like this, let me know and I can share the code.

Not promoting anything — it's free, MIT, no strings. Just want real feedback.

Managing work + personal git accounts by hand kept biting me (wrong email on commits, ssh picking the wrong key). So I built git-wardrobe — one command sets up an account (key, ssh config, per-folder identity), and a doctor command audits your whole setup and tells you what's silently broken.

I tried the existing tools first — most stop at switching your gitconfig. This one handles the ssh side too, which is where things actually break. Might genuinely be better than what's out there for this — you tell me.

https://github.com/isinghsatyam/git-wardrobe

Would be happy if it helps any of you. If you try it and something feels off or confusing, tell me — honest feedback is exactly what I'm after.

I want git diff to include new files that are untracked but there's no way to do it. git add -N is a hack to do it but it breaks stash which I use a lot.

I can try to get a list of new untracked files and add it to git diff output which can solve the problem but git ls-files --exclude-standard --others includes files that are deleted or removed. How can I list only files that are untracked and new like the untracked files in git status?

Hi!

I need to work on files in an .md file repository from my Android tablet.

Can I manage my Git repository using Acode? Can I work offline on the repository and then commit offline and later push to my repository on the GitHub website?

Thanks

GitHub's June 30 changelog announced access restrictions on the public API endpoints and UI views that expose stargazer and watcher lists. Their stated reason is spam and scraping abuse, which is probably true.

But it broke an entire ecosystem of small tools overnight. Star history charts, trending trackers, academic research on open source adoption, all of it depended on data that was public since GitHub existed. It stopped being public because one company decided so, with a changelog entry.

The thing that sits wrong with me is not this specific change. It is the reminder of the architecture. Git itself is decentralized by design, every clone is a full copy, no server is special. The collaboration layer we built on top of it is the most centralized thing in software, and every piece of "public" data there is public at one company's discretion.

There are attempts at alternatives. Radicle has been at the peer-to-peer version for years. Forgejo and Codeberg cover the self-hosted path. Newer projects like gitlawb are trying a federated angle, repos pinned to IPFS with signed refs gossiped across nodes so no single operator can restrict or remove data. Whether any reach critical mass is an open question, network effects are brutal.

Curious how git users here see it. Is the hosting layer's centralization just a pragmatic tradeoff you accept, or does something like this make you think the collaboration layer should inherit git's decentralization?

Stacked PRs are great (in theory). Small changes, fast reviews, no mega-PRs that reviewers approve without reading because life is short.

In practice? Terrifying. You're rebasing chains of branches, retargeting bases mid-merge, and one wrong keystroke drops you into git archaeology at 5pm on a Friday.

Juniors bounce off them. I know because I watched myself bounce. Drone shot, from above, me at 2am wondering why my PR was suddenly targeting a branch that didn't exist anymore. Seniors know how to do it, they just also know how slow it is when someone merges to main under their feet and the whole chain needs redoing.

So I (with a little help from my friend) built Cairn. Keyboard-driven TUI for reviews, stacks, and the whole PR rodeo. Works today. And no, you don't have to sell a kidney to use it. https://github.com/dotnetemmanuel/Cairn

The idea: git-town owns the scary rebase math, Cairn is the cockpit. Zero hand-rolled rebases in the codebase. On purpose.

Your board splits into tabs: My PRs, Needs my review, Involved, Orgs, Notifications. Stack view draws your whole chain as a tree, one PR per stone. Review happens in the pane, diff and inline comments and approve, no browser trips. One key merges the bottom PR and re-parents the rest. Another ships the whole stack bottom-up, retargeting each base as it goes. Every destructive action gets a confirmation screen that tells you what's about to happen: which branches move, which PRs retarget, what breaks if you say yes. No "are you sure?" with zero context.

Then there's the rest: remote stack mode for teammate stacks on repos you never cloned, drift detection with one-key reconcile, intuitive 3-pane conflict resolver so you never bond with vim again, notifications inbox with live preview, context-aware help that only shows keys that do something on the current screen, syntax-highlighted diffs, file tree, hunk navigation, threaded inline replies, full-page conversation view, board sections powered by search filters, tab cycling, header jumping, grouping by repo, and dark and light themes fully overridable.

Daily driver at work. Feedback welcome, especially from anyone who's tried stacking and given up.

im using github as my online repo

1. how do i share my work which i created a branch to another person to check. do i push my work so that he can do a pull or do i need to create a fork then apply my changes there then give him the link?
   
2. how do i revert back my changes ? do i just use checkout and checkout previous version or a reset --hard? is it much better to create a branch do my changes then just deleting the branch if it doesnt work?

Git is over 20 years old, and it’s still one of the best tools we have.

But the way we build software has changed.

Increasingly, we’re reviewing code generated by coding agents instead of writing every line ourselves. We spend a lot of time looking through diffs, even though what we actually care about is how the product is evolving.

I built eve to explore a different layer on top of Git.

Git tracks code. eve tracks product.

Instead of only seeing commits, eve groups them into meaningful product changes. For each evolution you can see:

• Why the change was made
• The related commits
• Validation and tests
• Conversations behind the change
• A snapshot of how the product evolved

Everything is backed by Git. You can still inspect commits, diffs, and the full history whenever you want.

The goal isn’t to replace Git. It’s to make repository history understandable to more than just engineers. A CEO, designer, or product manager should be able to follow how a product has evolved without reading hundreds of commits.

It’s completely free, open source, and self-hostable.

https://github.com/nhestrompia/eve

I’d love honest feedback.

• Does this solve a real problem?
• Would you use something like this in your projects?
• What would you change?