7 ms·

Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX i

Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.

swader999 5y ago
I agree and limit Git Gui usage to read-only use, any mods to git I use command line.
- yxhuvud 5y ago
  Git Gui is a decent tool to compose commits, but for everything else I can't see myself using anything but the command line.
  - tcoff91 5y ago
    I do virtually everything with Magit. It's the best of both worlds IMO. You still need to actually understand git and its commands but it's like using the CLI with far fewer keystrokes and a better log interface than the CLI.
  - rjmunro 5y ago
    gitk (and similar) are great for browsing the history and figuring out what is going on. I couldn't live without it.
dec0dedab0de 5y ago
I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.
- tcoff91 5y ago
  even if you use the git CLI you can still set up a mergetool so that when you are resolving merge conflicts you can use something like BeyondCompare or P4Merge to handle the merge conflicts.
  - Hamuko 5y ago
    And every Xcode installation on macOS comes with FileMerge.app.
  - mixmastamyk 5y ago
    Meld
- fiddlerwoaroof 5y ago
  There’s a really easy way to check the diff before committing on the command-line: git commit -v Displays a diff at the bottom of the editor that pops up to write a commit message.
  - cerved 5y ago
    you can also set git config commit.verbose true to always have this behavior
- Ashanmaril 5y ago
  The Jetbrains IDE git GUI is by far the best git GUI I've used, I feel lost trying to use git without it. There's a user request that's been sitting around for a while to pull it out into a dedicated application, which I could personally get behind since we have one project at work that's pretty difficult to run outside of Eclipse https://youtrack.jetbrains.com/issue/IDEA-152437 https://youtrack.jetbrains.com/issue/IDEA-152437
- stevenhuang 5y ago
  What's wrong with 'git diff'? Then there's 'git add -i' to easily choose which files to add
gitgitgit 5y ago
I use Git via the GitHub Desktop client (https://desktop.github.com https://desktop.github.com) and find it _very easy_ to use Git without issue by following a simple rule: don't be clever. I have branches, I commit, I squash merge via a Pull Request. No rebasing, no moving commits around. There might be workflows where rebasing etc. are important and certainly in those cases, using a GUI is probably not a great idea -- but it's certainly possible to use a GUI without issue if you keep your workflow simple.
- phkahler 5y ago
  I squash locally, but learning to do that required learning vim. Fortunately vimtutor. Then my distro changed the default text editor launched from git... fortunately I knew enough to get by with that one - which might be emacs but I haven't verified. Git is really weird but useful.
  - sethd 5y ago
    Git will use whatever editor you have defined in $EDITOR. You can also define this specifically for Git via global config (~/.gitconfig) if you don't want it to use your session's $EDITOR variable: [core] editor = vim
  - gbear0 5y ago
    The default editor is usually configurable (of course you'd have to learn all the different contexts you can do this from first to know this is a thing ... discoverability is hard). For example in ubuntu you can do sudo update-alternatives --config editor Some programs will use the environment variable $EDITOR, so you can add this to your shell startup configs export EDITOR=vi Or specifically for git cli you can run git config --global core.editor vi
an_opabinia 5y ago
Not a single person I’ve met using git in the last decade has thrived using a UI for it.
- animal_spirits 5y ago
  I've said this in other threads but I'll proselytize here as well. I really started to grok git after using the lazygit terminal UI. I think it's really handy to see what the current "state" of git is in and how to browse it easily. Would continue to recommend. https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit
- oblio 5y ago
  That's a failing of Git. TortoiseSVN brought source control to millions of people. A good tool should be fully embeddable in a UI, 15 years after its launch.
  - approxim8ion 5y ago
    We still use tortoiseSVN at work. It's crude but shockingly simple to use. Moving to git would be a significant expense just to train people not to break things and to get them used to CLI.
    - somethingor 5y ago
      TortoiseGit exists too and is fantastic IMO: https://tortoisegit.org/ https://tortoisegit.org/
      - pjmlp 5y ago
        Indeed, it makes using git so much less painfull. There are days where I daydream of Clearcase when dealing with git.
        atulatul 5y ago
        Early in my career- when I got evil twin error- I was conditioned not to daydream of clearcase ever. :)
zubspace 5y ago
I'm a huge fan of git fork [1] on windows (or mac). Looks good, never failed me and does everything I need (branching, rebasing, merging, squashing, cherry picking, blaming and it can even show lost commits with reflog). And it performs really well (in contrary to sourcetree). [1] https://git-fork.com/ https://git-fork.com/
- dividedbyzero 5y ago
  This looks neat! And a one-time purchase, too.
overgard 5y ago
I find GUI's to be very helpful; most of my commits happen through VSCode's commit panel. For my home Unity3D project I use sourcetree because my commits unfortunately end up being to a lot of unrelated files (blame unity), and having a UI to stage them saves a lot of typing. I avoid anything like rebasing (never got the point of that), but I use branches liberally. I find with this setup, I only need to use a handful of command line options, and I haven't screwed up a local repository in a long time.
- muststopmyths 5y ago
  If you are on Windows, Visual Studio's GUI is actually quite good for staging, merging and diffing. I tend to use it for most of those simpler kinds of things while still doing commits, rebase etc. from the command line. Same for VSCode on non-Windows. I only mention this because I came to hate Sourcetree in its newer iterations on Windows so much that I tried out Visual Studio's support and was pleasantly surprised.
smilekzs 5y ago
I disagree. First of all, a well-designed Git GUI (examples below) exposes the git's underlying data model to you; in contrast, the CLI obscures it until something breaks and you're forced into it without context. Git operates on a graph and there is simply no way around it. The more you're exposed to the graph, the better you can mentally model it and ask it to do the right things. While there are many half-baked Electron-based UIs that only unnecessarily complicates things, there are good ones too: On Windows (and Linux thru Mono), I use GitExtensions. The visualizations are sane and discover-friendly. It will tell you what to expect. When I work on C++ projects, the one built into CLion (JetBrains family; as mentioned by a sibling comment) is very good on its own. What impresses me the most is that has good visual support of a patch-oriented workflow. You can work with multiple "changelists" offline, shuffle individual changes around, seamlessly convert between changelists and patch files, and (most importantly) still work nice with the vanilla git model as the "actual history". It also works transparently with conceptually monorepo projects that have multiple physical repos, allowing you to do simultaneous commits. I feel VSCode, GitHub client, Kraken, and several other Electron-based stuff, are too focused on the "polish" than substance, or are too opinionated to be used across repos I don't own.
- deleted 5y ago
  [deleted]
- cerved 5y ago
  The CLI doesn't obscure as much as presupposes that you understand internal workings of git. All GUIs are not created equal. The JetBRains GUIs are pretty good. Others try and impose git "their way" and just invite creating a mess.
- jonnycomputer 5y ago
  So back when I was learning git, I was very shy about using any GUI because I was afraid that it would make learning how git works that much harder. I think that I somehow felt that the CLI was more fundamental, in some way. But I think you are right, and I was wrong. A better interface that puts the graph front and center would have led me to learn it so much faster, especially when it also exposes the command line equivalents, as magit does (or so I've heard).
woah 5y ago
Sorry, I'm trying to get work done, not memorize an obscure set of incantations like some kind of D&D wizard. If the repo gets messed up, I delete it and reclone.
- cerved 5y ago
  It's a handful of commands, very well documented with tons of SO questions that is one search away if you can figure it out yourself. It's something I use all day, every day. I'd say it's worthwhile to learn if your daily job involves working under source control
  - tailspin2019 5y ago
    Yes I agree. If you’re going to use git (whether by choice or force) it is 100% worth learning the small set of commands required to undo a screwup without needing to reclone. Recloning to me is a bit like tearing your house down and rebuilding it just because you painted your living room the wrong colour (in most cases!)
    - cerved 5y ago
      at least if you are a carpenter
- Shacklz 5y ago
  I really understand your sentiment, and I've been there for long enough myself - but once you have a somewhat decent understanding about gits internal data model, the commands that allow you to clean up pretty much any mess (reset & reflog probably being the most prominent ones) start to somewhat make sense. If you had previous exposure to anything computer-science, it very likely won't take more than a few hours until the puzzle pieces start to come together. And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development.
  - pjmlp 5y ago
    > And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development. Unfortunely.
PufPufPuf 5y ago
Funnily, I use a GUI almost exclusively to resolve mess-ups: Ungit is a great tool to understand the current state of the repository and fix it.

swader999 5y ago

I agree and limit Git Gui usage to read-only use, any mods to git I use command line.

yxhuvud 5y ago
Git Gui is a decent tool to compose commits, but for everything else I can't see myself using anything but the command line.
- tcoff91 5y ago
  I do virtually everything with Magit. It's the best of both worlds IMO. You still need to actually understand git and its commands but it's like using the CLI with far fewer keystrokes and a better log interface than the CLI.
- rjmunro 5y ago
  gitk (and similar) are great for browsing the history and figuring out what is going on. I couldn't live without it.

dec0dedab0de 5y ago

I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.

tcoff91 5y ago
even if you use the git CLI you can still set up a mergetool so that when you are resolving merge conflicts you can use something like BeyondCompare or P4Merge to handle the merge conflicts.
- Hamuko 5y ago
  And every Xcode installation on macOS comes with FileMerge.app.
- mixmastamyk 5y ago
  Meld
fiddlerwoaroof 5y ago
There’s a really easy way to check the diff before committing on the command-line: git commit -v Displays a diff at the bottom of the editor that pops up to write a commit message.
- cerved 5y ago
  you can also set git config commit.verbose true to always have this behavior
Ashanmaril 5y ago
The Jetbrains IDE git GUI is by far the best git GUI I've used, I feel lost trying to use git without it. There's a user request that's been sitting around for a while to pull it out into a dedicated application, which I could personally get behind since we have one project at work that's pretty difficult to run outside of Eclipse https://youtrack.jetbrains.com/issue/IDEA-152437 https://youtrack.jetbrains.com/issue/IDEA-152437
stevenhuang 5y ago
What's wrong with 'git diff'? Then there's 'git add -i' to easily choose which files to add

gitgitgit 5y ago

I use Git via the GitHub Desktop client (https://desktop.github.com https://desktop.github.com) and find it _very easy_ to use Git without issue by following a simple rule: don't be clever. I have branches, I commit, I squash merge via a Pull Request. No rebasing, no moving commits around. There might be workflows where rebasing etc. are important and certainly in those cases, using a GUI is probably not a great idea -- but it's certainly possible to use a GUI without issue if you keep your workflow simple.

phkahler 5y ago
I squash locally, but learning to do that required learning vim. Fortunately vimtutor. Then my distro changed the default text editor launched from git... fortunately I knew enough to get by with that one - which might be emacs but I haven't verified. Git is really weird but useful.
- sethd 5y ago
  Git will use whatever editor you have defined in $EDITOR. You can also define this specifically for Git via global config (~/.gitconfig) if you don't want it to use your session's $EDITOR variable: [core] editor = vim
- gbear0 5y ago
  The default editor is usually configurable (of course you'd have to learn all the different contexts you can do this from first to know this is a thing ... discoverability is hard). For example in ubuntu you can do sudo update-alternatives --config editor Some programs will use the environment variable $EDITOR, so you can add this to your shell startup configs export EDITOR=vi Or specifically for git cli you can run git config --global core.editor vi

an_opabinia 5y ago

Not a single person I’ve met using git in the last decade has thrived using a UI for it.

animal_spirits 5y ago
I've said this in other threads but I'll proselytize here as well. I really started to grok git after using the lazygit terminal UI. I think it's really handy to see what the current "state" of git is in and how to browse it easily. Would continue to recommend. https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit
oblio 5y ago
That's a failing of Git. TortoiseSVN brought source control to millions of people. A good tool should be fully embeddable in a UI, 15 years after its launch.
- approxim8ion 5y ago
  We still use tortoiseSVN at work. It's crude but shockingly simple to use. Moving to git would be a significant expense just to train people not to break things and to get them used to CLI.
  - somethingor 5y ago
    TortoiseGit exists too and is fantastic IMO: https://tortoisegit.org/ https://tortoisegit.org/
    - pjmlp 5y ago
      Indeed, it makes using git so much less painfull. There are days where I daydream of Clearcase when dealing with git.
      - atulatul 5y ago
        Early in my career- when I got evil twin error- I was conditioned not to daydream of clearcase ever. :)

zubspace 5y ago

I'm a huge fan of git fork [1] on windows (or mac). Looks good, never failed me and does everything I need (branching, rebasing, merging, squashing, cherry picking, blaming and it can even show lost commits with reflog). And it performs really well (in contrary to sourcetree). [1] https://git-fork.com/ https://git-fork.com/

dividedbyzero 5y ago
This looks neat! And a one-time purchase, too.

overgard 5y ago

I find GUI's to be very helpful; most of my commits happen through VSCode's commit panel. For my home Unity3D project I use sourcetree because my commits unfortunately end up being to a lot of unrelated files (blame unity), and having a UI to stage them saves a lot of typing. I avoid anything like rebasing (never got the point of that), but I use branches liberally. I find with this setup, I only need to use a handful of command line options, and I haven't screwed up a local repository in a long time.

muststopmyths 5y ago
If you are on Windows, Visual Studio's GUI is actually quite good for staging, merging and diffing. I tend to use it for most of those simpler kinds of things while still doing commits, rebase etc. from the command line. Same for VSCode on non-Windows. I only mention this because I came to hate Sourcetree in its newer iterations on Windows so much that I tried out Visual Studio's support and was pleasantly surprised.

smilekzs 5y ago

I disagree. First of all, a well-designed Git GUI (examples below) exposes the git's underlying data model to you; in contrast, the CLI obscures it until something breaks and you're forced into it without context. Git operates on a graph and there is simply no way around it. The more you're exposed to the graph, the better you can mentally model it and ask it to do the right things. While there are many half-baked Electron-based UIs that only unnecessarily complicates things, there are good ones too: On Windows (and Linux thru Mono), I use GitExtensions. The visualizations are sane and discover-friendly. It will tell you what to expect. When I work on C++ projects, the one built into CLion (JetBrains family; as mentioned by a sibling comment) is very good on its own. What impresses me the most is that has good visual support of a patch-oriented workflow. You can work with multiple "changelists" offline, shuffle individual changes around, seamlessly convert between changelists and patch files, and (most importantly) still work nice with the vanilla git model as the "actual history". It also works transparently with conceptually monorepo projects that have multiple physical repos, allowing you to do simultaneous commits. I feel VSCode, GitHub client, Kraken, and several other Electron-based stuff, are too focused on the "polish" than substance, or are too opinionated to be used across repos I don't own.

deleted 5y ago
[deleted]
cerved 5y ago
The CLI doesn't obscure as much as presupposes that you understand internal workings of git. All GUIs are not created equal. The JetBRains GUIs are pretty good. Others try and impose git "their way" and just invite creating a mess.
jonnycomputer 5y ago
So back when I was learning git, I was very shy about using any GUI because I was afraid that it would make learning how git works that much harder. I think that I somehow felt that the CLI was more fundamental, in some way. But I think you are right, and I was wrong. A better interface that puts the graph front and center would have led me to learn it so much faster, especially when it also exposes the command line equivalents, as magit does (or so I've heard).

woah 5y ago

Sorry, I'm trying to get work done, not memorize an obscure set of incantations like some kind of D&D wizard. If the repo gets messed up, I delete it and reclone.

cerved 5y ago
It's a handful of commands, very well documented with tons of SO questions that is one search away if you can figure it out yourself. It's something I use all day, every day. I'd say it's worthwhile to learn if your daily job involves working under source control
- tailspin2019 5y ago
  Yes I agree. If you’re going to use git (whether by choice or force) it is 100% worth learning the small set of commands required to undo a screwup without needing to reclone. Recloning to me is a bit like tearing your house down and rebuilding it just because you painted your living room the wrong colour (in most cases!)
  - cerved 5y ago
    at least if you are a carpenter
Shacklz 5y ago
I really understand your sentiment, and I've been there for long enough myself - but once you have a somewhat decent understanding about gits internal data model, the commands that allow you to clean up pretty much any mess (reset & reflog probably being the most prominent ones) start to somewhat make sense. If you had previous exposure to anything computer-science, it very likely won't take more than a few hours until the puzzle pieces start to come together. And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development.
- pjmlp 5y ago
  > And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development. Unfortunely.

PufPufPuf 5y ago

Funnily, I use a GUI almost exclusively to resolve mess-ups: Ungit is a great tool to understand the current state of the repository and fix it.