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 73 comments

sorted by: hot top controversial new old
[–] 27 points 1 year ago (4 children)
  • [–] 114 points 1 year ago (3 children)

    The cli because it is consistent everywhere and has all fearures

  • source
  • hideshow 3 child comments
  • [–] 8 points 1 year 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.

  • source
  • parent
  • [–] 16 points 1 year 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
  • source
  • [–] 15 points 1 year ago (1 child)
  • [–] 12 points 1 year ago* (2 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.

  • source
  • hideshow 2 child comments
  • [–] 2 points 1 year ago (1 child)

    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)

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 year ago* (last edited 1 year 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.

  • source
  • parent
  • [–] 8 points 1 year 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.

  • source
  • hideshow 4 child comments
  • [–] 8 points 1 year ago* (last edited 1 year ago) (1 child)

    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.)

  • source
  • hideshow 1 child comment
  • [–] 7 points 1 year 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.

  • source
  • [–] 7 points 1 year ago (1 child)

    Is Vscode a git client?

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

  • source
  • hideshow 1 child comment
  • [–] 7 points 1 year ago

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

  • source
  • [–] 6 points 1 year ago

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

  • source
  • [–] 6 points 1 year 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.

  • source
  • hideshow 6 child comments
  • [–] 3 points 1 year ago (1 child)

    I love Fork, bought the license to support the developer.

    The only thing I don’t like is that there is no Linux version, asked the dev and he told me that the issue with Linux is that there are different distros with different GUI libraries so it would require multiple versions for Linux.

    A bit saddened it I completely understand.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 1 year ago

    I paid for it too!

    It's the first piece of shareware I actually went out of my way to pay for because it was so good that I’d be genuinely pissed off if it died. I'd probably end up switching to pijul or something else for my projects if it ever did.


    I've seen a bunch of people messing the windows version running in linux in the fork forums, so it may be coming in an unsupported capacity.

  • source
  • parent
  • [–] 1 point 1 year ago (2 children)

    In case you're interested, git add <files> -p allows you to do this on the command line. I use it daily.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 year ago

    I still don't think it's nearly as convenient as being able to just see the changes side by side and click the one you want (or both). You can even easily modify the final outcome in the 3rd preview panel, in case you need to do a quick fix after a conflict resolution.

  • source
  • parent
  • Yeah, I use it when ssh'd into a server, but it's just so awkward to use.

    Sometimes it just really doesn't want to separate a hunk. Other times you want to stage all lines except one, and you have to do a million splits just to target the lines you want to keep.

    It'd be far easier if you could just select the lines you want to affect. It's literally the first feature shown in lazygit's readme. I think half the reason that people use lazygit is that partial commits are so awkward to perform in most other clients.

    Luckily Fork does it as well as lazygit

  • source
  • parent
  • [–] 11 points 1 year 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.

  • source
  • [–] 5 points 1 year 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.

  • source
  • [–] 4 points 1 year ago

    GitKraken ❤️

    If not present, vscode + gitlens

  • source
  • [–] 3 points 1 year ago* (1 child)
  • [–] 2 points 1 year ago

    This is very satisfying to use and is a nice companion to the command line - I particularly use it to stage only certain lines and files from the changes.

    I tried lazygit first, but there was a consistent lag that was probably only ¼ second but it ruined the experience for me.

  • source
  • parent
  • [–] 2 points 1 year ago (2 children)

    Git Extensions.

    It's what they used at my job when I started, it does the job, and I've gotten used to it. 🤷‍♂️

  • source
  • hideshow 2 child comments
  • [–] 3 points 1 year ago (1 child)

    I personally prefer lazygit nowadays, but when it comes to GUI clients on Windows then Git Extensions is definitely a very good pick.

    I particularly like that it doesn't hide that it's just executing git commands under the hood and its focus on the history graph. Those two things really helped understand how git actually works and why I'm still recommending it.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 1 year ago

    Yeah, maybe it's because I learned git from the graph, but I find it really helpful when figuring out why a certain piece of code ended up looking like it does (the ability to see the changes made in every commit and open versions of the files at any point in history without checking out the commit is also very useful).

    And yeah, if you need or want the command line it always lets you open a git prompt for you to do whatever you want, which is nice.

    Also, again maybe because it's what I've gotten used to, but I find the way it handles merge or rebase conflicts more useable (or rather less unusable) than any other I've tried...

  • source
  • parent
  • [–] 3 points 1 year ago

    Lazy git most of the time, sourcegit for heavy duty stuff.

  • source
  • [–] 3 points 1 year ago

    lazygit & gitsigns.nvim

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

  • source
  • [–] 3 points 1 year ago

    sourcegit, fork

  • source
  • [–] 3 points 1 year ago (1 child)

    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.

  • source
  • hideshow 1 child comment
  • [–] 3 points 1 year 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

  • source
  • [–] 2 points 1 year ago

    I use Sourcetree for routine stuff, though I occasionally have to hit the command line when shit gets real.

  • source
  • [–] 2 points 1 year ago

    Vscode with the Git Graph extension.

  • source
  • [–] 2 points 1 year ago

    Mostly vscode, and GitHub desktop for projects that I don’t use vscode for. I want to learn how to use the CLI, I just didn’t get around to it yet.

  • source
  • [–] 2 points 1 year ago

    Vscode and gitlens for routine stuff, and then just CLI when push comes to shove and I need some more advanced feature.

  • source
  • [–] 2 points 1 year 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.

  • source
  • [–] 2 points 1 year ago

    Whatever's built into pycharm or vscode for looking at diffs. Command line for push pull squash etc

  • source
  • [–] 2 points 1 year ago

    I use VSCode and SourceGit. SourceGit is similar to Fork (which I've used before), but it's FOSS and cross-platform (Windows/macOS/Linux).

  • source
  • [–] 2 points 1 year ago (1 child)

    i loved fork on windows but i'm too lazy to set up wine to try and get it to work now i just use git cola and the cli.

  • source
  • hideshow 1 child comment
  • [–] 2 points 1 year ago*

    cli and meld for mergetool

  • source
  • [–] 2 points 1 year ago

    I use GitHub Desktop on Mac and PC. It works fine with local repos, too.

  • source
  • [–] 1 point 1 year ago

    Tried idea community edition, honestly not bad, like vs code slightly more even tho with an extension or two you can make how they function very similar. Wanted to use idea because it matched the gtk theme, but if I was gonna use an extension for vs code like navigation might as well use vs code. Both easy to use with git as a dabbler.

  • source
  • [–] 1 point 1 year ago*

    For professional use I’ve heard good things about SmartGit, unfortunately my work refused to buy me a license and the trial period wasn’t long enough for me to really form an opinion.

    Work suggests to use SourceTree but it is way too sluggish.

    These days I use git CLI for most things, and VSCode to review changes and submit PRs. Of course this also assumes you use a decent shell with git support, like Oh-My-Posh or similar, so it is always clear what you are working on.

  • source
  • [–] 1 point 1 year 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.

  • source
  • I made some automation in python for common git tasks and use the cli otherwise. I tried a couple like sourcetree and the built in automation for VS but they're either slow or lack features i'd like.

  • source
  • [–] 1 point 1 year ago

    Mainly the official git CLI for controlling branches and sub modules, and sometimes the GitHub CLI if quickly checking out a pull request from a forked repo.

    Also use the source control tab in VSCode rather often, as it's really convenient to review and stage individual line changes from its diff view, and writing commit messages with a spell check extension.

    If it's a big diff or merge conflict, I'll break out the big guns like Meld, which has better visualizations for comparing file trees and directories.

    About a decade ago, I used to use SmartGit, then tried GitKraken when that came around, but never really use much of the bells and whistles and wasn't keen on subscription pricing. Especially as the UX for GitHub and other code hosting platforms online have matured.

  • source
  • [–] 1 point 1 year ago (2 children)

    CLI for me. I do use the GitLens plugin in vs code but only so I can see commit info inline. I never commit anything from vs code.

    I like Kaleidoscope (v3) for diffs but not for merging. I could probably use any graphical difftool for this purpose but it’s what I’m used to.

  • source
  • hideshow 2 child comments
  • [–] 1 point 1 year 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.

  • source
  • [–] 1 point 1 year ago

    Github desktop, despite the name it's just a git client. Absolutely clownish that there's no official Linux support (there's a fork which works perfectly). I use it to interact with self-hosted gitea, codeberg and github, pretty happy with it, I'm Aldo testing git butler

  • source
  • [–] 1 point 1 year ago

    vscode with edamagit and the cli

  • source
  • [–] 1 point 1 year ago

    Lazygit and magit

  • source
  • [–] 1 point 1 year 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

  • source
  • [–] 1 point 1 year ago

    LazyGit and GitKraken. I try to use LazyGit as much as possible, but a few things are easier for me in GitKraken (as I'm more used to it).

  • source