this post was submitted on 07 Aug 2025
88 points (98.9% liked)

Programming

22170 readers
136 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

I'm wondering if you use any (graphical) clients to manage your Git, and if so, what client you use.

I myself have to use git professionally across all 3 major OS-es, and I currently use Sourcetree on Windows and macOS, and the Git tools built-in into IntelliJ on Linux.

Have given MaGit a try, but just couldn't get all the shortcuts to stick in my mind.

Interested to hear your experiences!

top 50 comments
sorted by: hot top controversial new old
[–] jerkface@lemmy.ca 1 points 3 days ago

I will install emacs on a machine just to use magit.

[–] tiredofsametab@fedia.io 1 points 4 days ago

I have tortoise git on a windows machine and GitHub desktop on a Mac. I do some things from the command line when I'm not feeling lazy.

[–] oantolin@discuss.online 2 points 5 days ago

I'm an Emacs users, so unsurprisingly I use magit, but perhaps surprisingly I use it sparingly, using Emacs's VC most of the time.

[–] koala@programming.dev 1 points 6 days ago

When I learned Git I think there were not decent tools, so I got used to the command line.

I occasionally use gitk for reviewing my commits- it's nicer to see the files modified and be able to jump back and forth, although I get I could use git log -p instead.

I'm an Emacs user, but I don't use magit (!)

I like some of the graphical tools- some colleagues use Fork and I like it... but as I've already learned the CLI, I don't see the point for me.

I could use learning some jj because it automates some of the most tedious parts of my workflow, but I'm getting too old.

[–] locuester@lemmy.zip 1 points 6 days ago

Git Graph VS Code extension

I’ve used source tree, gitkraken, etc. this simple extension is just as good. I spend most my day with it

[–] locuester@lemmy.zip 1 points 6 days ago

Git Graph VS Code extension

I’ve used source tree, gitkraken, etc. this simple extension is just as good. I spend most my day with it

[–] cbazero@programming.dev 118 points 1 week ago (4 children)

The cli because it is consistent everywhere and has all fearures

[–] killingspark@feddit.org 23 points 1 week ago* (last edited 1 week ago) (3 children)

The only thing I'm missing in the CLI is easy picking and choosing which change to include in a commit on a more fine grained basis than files. I sometimes have a changed file and the changes fix different issues and thus should get separate commits but with the CLI I can't easily select the changes to be staged. At least not AFAIK.

Edit: Richards law of posting something wrong to get fast correct answers seems to stay true, even on lemmy. Thanks for teaching me something today <3

[–] doeknius_gloek@discuss.tchncs.de 50 points 1 week ago (1 children)
[–] staircase@programming.dev 12 points 1 week ago (1 children)
[–] catalyst@lemmy.world 4 points 1 week ago

Hard agree haha, use this one constantly.

[–] The2b@lemmy.vg 6 points 1 week ago* (last edited 1 week ago) (2 children)

You can via git add -i foo.bar

I believe the only issue with that is that it can only go by hunks. If your changes are sufficiently far away, you can select them separately. But if you change one function that should be in patch a, and another function 5 lines down that should be in patch b, I think you're screwed

That being said, this is all from memory, so don't quote me on it

[–] Corngood@lemmy.ml 8 points 1 week ago

In interactive add mode you can use s to split a hunk, and e to edit it. That's usually enough for me to split things up.

[–] hallettj@leminal.space 6 points 1 week ago

I usually use git add -p to selectively stage hunks. But in git add -i I think running the patch command does the same thing to get into patch mode.

If patch mode shows you a hunk, and you only want some of the lines you can press s to split into smaller hunks. Then you'll be prompted whether to add each smaller hunk separately.

If you want to stage a change that is on the same line as a change you don't want to stage, or on an adjacent line, then you need to use e to edit the hunk. Git stages whatever changes are left when you're done editing. The file in the working tree on disk is unchanged.

load more comments (1 replies)
[–] AdamBomb@lemmy.sdf.org 8 points 1 week ago

Same, because its UX is actually really good. Years ago when I was new to git, I tried to use Sourcetree to revert a merge commit, and it would just fail. When I tried it in the CLI, it still failed, but it told me how to fix it. (I needed to specify which parent)

That, plus it’s scriptable, plus I’m in the terminal a lot anyway. I’ll also use the IDE git client sometimes if that’s where I am at the moment.

[–] pinball_wizard@lemmy.zip 6 points 1 week ago* (last edited 1 week ago)

CLI first here too, for the same reason.

I'm not above using an editor plugin if it's simple and reliable and right there waiting, like VSCodium.

load more comments (1 replies)
[–] slacktoid@lemmy.ml 25 points 1 week ago (3 children)
[–] lobut@lemmy.ca 5 points 1 week ago (1 children)

It's what I use when I need a bit of a UI for some things. I use the terminal mostly but Lazygit is great.

load more comments (1 replies)
load more comments (2 replies)
[–] BeigeAgenda@lemmy.ca 16 points 1 week ago

I mostly use git from the console.

  • git with a bunch of aliases for common operations and making the log pretty.
  • gitk when I need a UI to browse the history
  • kdiff3 as mergetool
[–] omgitsaheadcrab@sh.itjust.works 14 points 1 week ago (2 children)
[–] TheAgeOfSuperboredom@lemmy.ca 10 points 1 week ago

Magit is fantastic!!

[–] littleomid@feddit.org 3 points 1 week ago

Same. Magit 99% of the time and CLI for the one percent where I need to run an obscure command. Magit is genuinely one of the best things in Emacs besides org mode.

[–] deadcatbounce@reddthat.com 13 points 1 week ago* (last edited 1 week ago) (1 children)

Off topic: day-after-day with these kinds of posts and especially the replies, I need Reddit less and less. That's a very good thing.

[–] TehPers@beehaw.org 2 points 5 days ago (1 children)

Sorry, guess the replies are too tame. Let me help you with that.

Anything more than the git CLI is a joke. Real developers should know how to raw-dog that thing. If you're not octopus merging your rebased branches to deploy to prod, you're just not a real developer.

(I use gitui)

[–] deadcatbounce@reddthat.com 1 points 3 days ago* (last edited 3 days ago)

Fair comment.

IANA developer at all. Mostly just keeping records of my dotfiles and odd bits I have playing with., and the experiments I try to run using branches. Sometimes I need a visual representation of the commits and hashes to make it easier to understand what I'm doing.

git is my only nemesis.

[–] bignose@programming.dev 11 points 1 week ago

Magit is what allowed me to finally commit to switching to Git full time.

It's such an excellent front-end for Git that I've known numerous workmates learn Emacs just to use Magit.

[–] zarlin@lemmy.dbzer0.com 8 points 1 week ago* (last edited 1 week ago) (4 children)

Fork on windows, SourceGit on Linux, both have a similar UI layout to SourceTree, but are much faster/snappier.

I really like having a clear overview of the commit history, branches and current local state. I haven't figured out yet how to get such an "at a glance" overview in the CLI.

For advanced stuff the CLI is still very convenient.

load more comments (4 replies)
[–] Kissaki@programming.dev 8 points 1 week ago* (last edited 1 week ago) (3 children)

TortoiseGit.

Through settings, I move the Show Log to the top context menu level, and it's my entry point to every Git operation.

I see a history tree to see and immediately understand commit and branch relationships and states. I can commit, show changes, diff, rebase interactive or not, push, fetch, switch, create branches and tags, squash and split commits, commit chunk-wise through "restet after commit", … And everything from a repo overview.

/edit: To add; other clients I tried never reached what I want from a UI/GUI, never reached TortoiseGit. Including IDE integrations where I'm already in the IDE; I prefer the separate better TortoiseGit.

GitButler is interesting for it's different approach, but when I tried it out the git auth didn't remember my key password. (Since trying out jj I found out it may have been due to disabled OpenSSH Service.)

load more comments (3 replies)
[–] spartanatreyu@programming.dev 7 points 1 week ago* (last edited 1 week ago) (6 children)

Fork !!!

It's hands down the best git client.

It's free as in: sublime text or winzip where they ask you once a month if you want to pay for it but you can just select: I'm still trying it out, and it gets out of your way.

  • It's got a well designed tree graph like in GitKraken except it doesn't lag
  • It's interactive rebasing is as smooth as JJ / LazyGit, so you can edit/rename/reorder your commits except you don't have to have to remember CLI flags since it has its own UI
  • It's lets you commit individual lines by selecting them instead of adding/removing whole hunks like Sourcetree except it isn't filled with paper cuts where a feature breaks in an annoying way for 2 years and you have to do extra steps to keep using it how you want.

And one killer feature that I haven't seen any other git clients handle: allowing me to stage only one side of the diff. As in: if I change a line (so it shows up as one removed line and one new line in git), I can decide to add the new line change while still keeping the old line.

So changing this:

doThing(1);

into this:

doThing(2);

Shows up in git as:

- doThing(1);
+ doThing(2);

But if I still want to keep doThing(1);, I don't have to go back into my code to retype doThing(1);, or do any manual copy-pasting. I can just highlight and add only doThing(2); to the staging area and discard the change to doThing(1);.

So now the code exists as:

doThing(1);
doThing(2);

Now with a one-liner example like this, we could always re-enter the code again. But for larger code changes? It's far easier to just highlight the code in the diff and say: yes to this and no to the other stuff.

And when you get used to it, it makes it really easy to split what would be large git commits into smaller related changes keeping your git history clean and easy to understand.

load more comments (6 replies)
[–] lightnsfw@reddthat.com 7 points 1 week ago (1 children)

Is Vscode a git client?

No one take from me though idk what I'm doing when it comes to programming stuff.

load more comments (1 replies)
[–] somegeek@programming.dev 7 points 1 week ago

Lazygit. Used gitui for a long while but lazygit has vim key bindings which is much nicer and it also seems much more stable.

[–] whotookkarl@lemmy.dbzer0.com 7 points 1 week ago

CLI with some aliases for viewing commit history and branching, or less frequently an IDE plugin

[–] HaraldvonBlauzahn@feddit.org 6 points 1 week ago* (last edited 1 week ago)

I used a lot of Magit at work (it's good), as well as jujutsu and command line. Also, gitk for browsing history.

Currently I use jujutsu at home for leisure stuff and command line + git gui at work. For some workplaces, more powerful tools are just overkill.

[–] h4x0r@lemmy.dbzer0.com 6 points 1 week ago

I use plain old git for the same reasons already mentioned, but magit is the gold standard.

[–] hallettj@leminal.space 5 points 1 week ago* (last edited 1 week ago)

Fugitive, the vim / neovim plugin. It does everything the CLI does, but uses vim interfaces very effectively to enhance the experience. For example it's quite good for selectively staging changes from a file. I also like the option to open a buffer with the version of a file from any specified commit.

I also tried neogit which aims to port magit to neovim. I didn't like it as much. Partly because as far as I could tell at the time it lacked features compared to fugitive. But also because it seemed to want me to do everything through UIs in its own custom windows. Fugitive is integrated more thoroughly into vim via command mode, and special buffers.

[–] bananabread@lemmy.zip 4 points 1 week ago

GitKraken ❤️

If not present, vscode + gitlens

[–] roadrunner_ex@lemmy.ca 4 points 1 week ago* (last edited 1 week ago)

I'm a big fan of tig for visualizing the graph and looking over history (then I don't need to leave the terminal, and it's snappier, in my experience, than most full-GUI programs like Sourcetree), but for actual Git commands, I like the CLI

[–] Starfighter@discuss.tchncs.de 4 points 1 week ago* (last edited 1 week ago) (1 children)
load more comments (1 replies)
[–] Anafabula@discuss.tchncs.de 3 points 1 week ago

lazygit & gitsigns.nvim

Do Jujutsu & jjui count? The backend is still git.

[–] kewjo@lemmy.world 3 points 1 week ago* (last edited 1 week ago) (1 children)

cli and meld for mergetool

[–] HaraldvonBlauzahn@feddit.org 3 points 1 week ago

Yeah, meld is nice.

[–] setsubyou@lemmy.world 3 points 1 week ago (1 children)

I mostly use the cli, but also Sublime Merge. It makes some things really convenient (like committing only some lines in a changed file), and looking at diffs is snappy too.

[–] tribut@infosec.pub 3 points 1 week ago* (last edited 1 week ago)

Just fyi, you can add only a few lines of a changed file on the cli too using git add -p

[–] ALERT@sh.itjust.works 3 points 1 week ago

sourcegit, fork

load more comments
view more: next ›