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!

  • tiredofsametab@fedia.io
    1·
    5 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·
    6 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·
    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.zipEnglish
    1·
    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.zipEnglish
    1·
    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

    • killingspark@feddit.orgEnglish
      23·
      8 days ago

      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

      • The2b@lemmy.vgEnglish
        6·
        8 days ago

        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·
          8 days 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.spaceEnglish
          6·
          8 days 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.

    • AdamBomb@lemmy.sdf.orgEnglish
      8·
      8 days 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·
      8 days 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.

    • lobut@lemmy.ca
      5·
      8 days ago

      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.

      • slacktoid@lemmy.mlEnglish
        2·
        8 days ago

        It just works really well. I don’t mind the terminal commands but lazygit makes using git just so much nicer

    • SinTan1729@programming.devEnglish
      3·
      8 days ago

      I mostly use git from the cli, but when I want to use a frontend, I use lazygit. (I just find it easier to use TUI for some things like only committing some of the changed files, squashing, or fixup commits.)

  • BeigeAgenda@lemmy.ca
    16·
    8 days 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
  • deadcatbounce@reddthat.com
    13·
    7 days ago

    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.orgEnglish
      2·
      6 days ago

      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·
        4 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.devEnglish
    11·
    8 days 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·
    8 days ago

    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.

    • cnovel@jlai.lu
      3·
      7 days ago

      I second Fork, been using it for years and it’s fast, able to handle multiple actions at once. Can’t recommend it enough!

    • Faalangst_26@feddit.nlOP
      2·
      8 days ago

      Have to take a look at Fork (annoying name to Google I image). Sourcetree can be quite sluggish and downright annoying on macOS.

      Ditto on the CLI having its pro’s and cons

    • mesa@piefed.socialEnglish
      2·
      8 days ago

      I second sourcegit. When I need to I’ll drop into the clu. But it’s so much easier to just look at the branches in sourcegit.

      It’s like an open source gitkracken.

  • Kissaki@programming.devEnglish
    8·
    8 days ago

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

    • Creat@discuss.tchncs.de
      1·
      8 days ago

      I have a love-hate relationship with it. Due to work reasons I’m more familiar than I want to be with tortoiseSVN, and the git version is similar enough to feel at home. But that’s also it’s biggest downfall: it does a lot of things the “SVN way” despite being a git client. The workflow can be kinda made to work, but it always feels like it’s not a native git tool, because it isn’t. I would go so far as to say that it encouragedrl bad habits on git, especially for those used to tortoiseSVN.

      • Kissaki@programming.devEnglish
        1·
        7 days ago

        What do you mean in particular?

        The only thing that comes to mind for me is the “restore after commit” being a different chunk-add workflow than add --patch - but I don’t think it’s worse.