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!

  • oantolin@discuss.online
    0·
    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.

  • deadcatbounce@reddthat.com
    0·
    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
      0·
      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)

  • Timberfang@pawb.socialEnglish
    0·
    7 days 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).

  • catalyst@lemmy.world
    0·
    8 days ago

    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.

  • Kissaki@programming.devEnglish
    0·
    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.

    • Creat@discuss.tchncs.de
      0·
      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.

    • Mr. Satan@lemmy.zip
      0·
      6 days ago

      I second this, although I’m mostly alone with git extensions in my workplace.

      I migrated to from sourcetree some years ago. At the time we had some big generated API client classes (imagine ~60k lines of code). They needed to be regenerated whenever we made changes and the diff on sourcetree was shitting the bed every time I needed to stage the damn files. It was just way too lagy, so I got fed up and moved.

      On my personal machine I prefer lazygit or just plain CLI.

    • NekuSoul@lemmy.nekusoul.de
      0·
      8 days ago

      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.

      • leftzero@lemmy.dbzer0.com
        0·
        8 days 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…

  • roadrunner_ex@lemmy.caEnglish
    0·
    8 days 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

  • setsubyou@lemmy.world
    0·
    8 days ago

    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
      0·
      8 days ago

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

    • Deebster@infosec.pub
      0·
      8 days 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.

  • Zarlin@lemmy.dbzer0.com
    0·
    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
      0·
      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
      0·
      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
      0·
      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.

    • pinball_wizard@lemmy.zip
      0·
      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 VDCodium.

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

    • killingspark@feddit.orgEnglish
      0·
      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.

      • The2b@lemmy.vgEnglish
        0·
        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
          0·
          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
          0·
          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.