17 ms·
The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check
by rjmunro 6y ago
The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour)
Resisting GUI's is not a good idea. The trick to learning is to always have `gitk --all` or a similar viewer open in another window.
Also instead of `git add` / `git commmit`, use `git gui`, but for most other things stick to the CLI.
Having said that use a GUI, github desktop is terrible. It tries to make things easier and as a result takes you away from git's standard terminology, so it's impossible to understand what it does.
Something I found teaching other people is it helps a lot if you haven't learnt SVN before.
- protonfish 6y agoI think that's unfair because I don't see that git even has a UI - it's designed to be a command-line API. The thousands of terrible GUIs out there are so bad that using the command line directly is still the best UI. (I think GitHub has done a great job managing remote repos - I am only talking about local tools.)
- skohan 6y agoA CLI is a UI, it's just a textual one
- specialist 6y agoYup. Every interface is a user interface.
- skohan 6y ago> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get the result I want.
- willis936 6y agoHow is this not a shortcoming of the GUI implementation? What could a CLI do that a GUI could not?
- necheffa 6y agoAutomation for starters.
- toopok4k3 6y agoNothing has stopped anyone from creating this perfect GUI(or better CLI) for Git that a lot of people seem to be missing. "Show me the code". Or in this case show me the GUI. Maybe the problem is just actually hard and the Git we have is the best current solution.
- dmitriid 6y ago> "Show me the code". Or in this case show me the GUI. Easy: https://gitup.co https://gitup.co It makes things that are hard or cumbersome in the CLI easy and convenient. Things I always do because I'm no longer afraid of mistakes: - split commits at random points - move commits up or down the branch - squash commits up or down the branch - edit commit messages Less often: - cherry pick against current branch - delete branches (local and remote) There are signinficantly more operations hidden there behind convenient shortcuts, but I don't ever (or very rarely) need them because it makes fixing mistakes so easy. And the only reason for advanced git usage I've seen is fixing mistakes.
- x87678r 6y agoWait what? How come nobody told me about gitk.
- me_me_me 6y agoI am sorry and happy for you. gitk is like an anchor for me to understand where I stand in given repo. Make sure to set default view to display all branches and mark branch sides.
- baq 6y agolet me tell you about gitk --all PS. git gui allows you to stage changes line-by-line, not just by hunk
- deleted 6y ago[deleted]
- edflsafoiewq 6y agocheckout -b seems more logical to me, but not even close to 1000x more logical. Whether it should go on branch or checkout is just an opinion. You're blowing some tiny disagreement up to ridiculous levels.
- the_af 6y agoOn aggregate, a large collection of individually tiny annoyances can add up to a tool that's confusing to use.
- AshamedCaptain 6y agoI actually dislike Git profusely but these arguments are very, very poor. git checkout --branch vs git branch --chekout ? Depending on how the wind blows I could see myself leaning on one or the other. WHO CARES? This is not even a paper-cut level of annoyance.
- petepete 6y agoThese days you can use `switch -c` instead. Switch makes so much more sense to me. https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch
- mmm_grayons 6y agoThis clearly isn't a popular opinion, but I may as well add it here: I like git. It's not that bad and not that hard to use. Occasionally I have to look up how to do something, usually involving git-filter-branch. But that's no surprise, because what I'm trying to do is usually inherently complex. I don't think a different interface would solve that. For most other stuff, git is simple and easy to use. It was a bit slow to learn, but most really good tools are (e.g. vim).
- swiley 6y ago> Resisting GUI's is not a good idea I would completely disagree with this, anything that adds layers between you and git creates more opportunities for misunderstanding and corner cases. Resisting a feature branch/merge workflow is what's a bad idea.
- HelloNurse 6y agoFor Git clients in particular, there's the issue of GUI applications that think their mostly ad hoc, incomplete configuration should prevail over standard Git configuration (e.g. GitAhead is unable to use authentication tokens on Windows) or that their "opinionated" behaviour is good for everyone (e.g. try to modify a tag with SourceTree).
- dkdk8283 6y agoWhen I first started writing software I would often rewrite third party libraries I didn’t understand to reduce complexity. After growing up and becoming wiser I came to understand I did this all because I didn’t invest the time to learn how these complex things worked. It also made me feel smart to write more code. Big mistake. I can’t help but think a little bit of this pattern rears it’s head as the motivation for things like git GUIs. There will be a maintenance burden and no matter how careful you are there will be bugs. I write scripts for complex but infrequently used operations and drop them in ~/bin
- circularfoyers 6y agoI still agree with your sentiment but wouldn't have writing more code still made you a better programmer when you were presumably still learning?
- dkdk8283 6y agoOf course. You must be allowed to fail. Times have changed, and I can’t imagine what it’s like to be a new developer now. Perhaps the drive to be social and show off your work is the part I can’t understand.
- dboreham 6y agoIt's not just the UX. It's the concepts the user has to understand in order to use git (without shooting their feet off or consulting a guru frequently).
- pugworthy 6y agoIf you use UX purely from the concept of User Experience, then failing to understanding the concept of something is a failure of UX. That said, sometimes when you are frustrated by having to add special cases to your code, it's not your fault, it's because you're modelling a badly designed system in the first place.
- studius 6y ago> Resisting GUI's is not a good idea. Explain why. Within our lifetimes, an interaction most users have with a computer could be just thinking about something to cause an action. I don't want to have to see a GUI in my brain to do that. Similarly, not everyone likes having to use what is traditionally called a GUI. For git, I prefer the CLI, though I use some helpers for completion, I have some scripts I wrote to show remote and local branches with their authors in different states of merge, etc. My guess is that in your GUI, you don't have that level of customization, and probably didn't even think it was an option. That's the problem with GUIs for me.
- matz1 6y ago>Similarly, not everyone likes having to use what is traditionally called a GUI Thats why, not everyone prefer CLI, if you are the one who learn better with GUI then resisting GUI's is not a good idea
- ivanhoe 6y agoI don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when you've just started using it. That's where GUI tools come useful, as people are generally less scared of GUI tools - they make you feel there's less of chance of making a mistake because you put the trust in the tool to stop them doing something obviously stupid. However IME that trust is not really deserved as most of the GUI tools will just as happily let you mess up your repository...
- mumblemumble 6y agoI suspect that the underlying model wouldn't be so scary, either, if the UI had not done such a stellar job of obfuscating it.
- wpietri 6y agoI think more than one thing can be a problem. The CLI is confusing and the model is complicated. This means people can get themselves into weird, hard-to-debug situations. Or end up copy-pasting incantations in hopes of fixing problems, but instead might lose their work.
- RichardCA 6y agoI've never seen a scenario that resulted in a developer losing work. You can always retrieve things out of the commit history, even in pathological situations.
- wpietri 6y agoI have lost work. A colleague force-pushed something because he thought he understood Git well enough to get away with it.
- 6y ago
- ufo 6y agoFor recent versions of git I'd suggest using "git switch" and "git restore" instead of git checkout. It avoids much of the confusion from the checkout command, which does very different things depending on what flags you pass it. That said, this is only one git command. The rest still has plenty of room for confusion.
- gen220 6y agoYes! It must have been somewhat controversial to add more “porcelain”, but I’ve loved the recent changes. Restore is a great name. They’ve also added some guiding comments to various commands (like rebase) that make the CLI more user friendly. I think checkout was the worst offender, because of how necessary it’s use was for most workflows. Branch could probably use some pruning, too.
- robotnikman 6y agoI agree with the SVN part. I learned how to use SVN before git and it helped me with learning how it worked.
- Tokkemon 6y agoThis is why I use Git Kraken. It abstracts away all the nonsense and gives me a lovely interface to work with my repos in a user-friendly way.
- StillBored 6y agoKraken is the first UI that I've found that makes editing commit messages on previous commits easy. I spend an inordinate amount of time moving hunks between commits/etc in order to present a "clean" git log for a couple opensource projects i work on that have OCD maintainers. Avoiding the rebase/edit/ammend/etc cycle is a huge time saver. What I really want it to do is be able to select a random hunk and move it as well...
- BalinKing 6y agoI was on the GK team a few years ago, so I'm obviously biased, but I believe that GK—specifically the design of graph[0]—helped me a lot to level up my git-fu. [0] which was created before my time at Axosoft, so I'm not that biased :-P
- brynjolf 6y agoClosed source so it is a no go for any serious projects sadly.
- koverda 6y agoGitKraken is the best git GUI I've had the pleasure of using.
- bmitc 6y ago> The underlying technology of git is great I disagree. It is quite slow and makes the wrong assumption that everything should be text.
- zeroimpl 6y agoHow so? git handles binary files at least as well as any other VCS from what I’ve seen.
- anuila 6y agoI disagree on GitHub Desktop. The whole point of the UI is so that your workflow is simplified without having to understand the exact inner workings of it all. GHDesktop’s simplicity means that most of time I don’t have to call 4 commands to just check out a new repository or PR because one click runs all those 4 commands and more. As simple as it is, lately I rarely have to use the CLI (which however I still use because I rebase and fixup) The fact that “takes you away from the terminology” sounds like people complaining that Windows 95 users don’t know what MKDIR means: That’s the whole point of UIs.
- lstodd 6y agoSo you're fine with not understanding what are you doing. This sounds ominious.
- deleted 6y ago[deleted]
- balabaster 6y agoThe biggest hurdle I had to learning Git, if truth be told, was my own aversion to doing anything that wasn't easy. It seemed difficult, so I dug my heels in and say "No! I don't wanna! It seems like friction and that's too hard." The fact is, once I got over myself and sucked it up and got my head around it, it really only took 2 days of effort to grok what I was doing and now it's easy. So biggest advice I can offer is this: Get over it and get on with it. It seems like a pain in the ass now, trust me I know, but you'll thank yourself for making the effort in the long run.
- crispyambulance 6y agoWe have no choice but to "get over it and get on with it". But it DID NOT have to be that way, and that's what makes many people keep their resentment. It's like a kind of "hazing" experience. Thankfully there are tools that make it less horrible. Git Tower and Visual Studio integration come to mind as examples. It's sad, however, that there's not been an overhaul of the git commandline into something coherent and usable.
- balabaster 6y agoUgh... the visual studio integration is HOOOOOORRRRRIBLE. I hated it. It didn't do anything to make my life easier. You know what made it bearable? SourceTree, and I tried GitKraken way back when it was first launched in beta, it seemed like it was on the right track but lacked too many of the features at that time. I would highly recommend SourceTree though.
- crispyambulance 6y agoFWIW, the latest git integration in visual studio seems to be better.
- u801e 6y ago> The underlying technology of git is great, but the UX is terrible. I think it really comes down to a difference in philosophy in terms of learning how to use tools. In the past, one had to read the documentation to figure out how to use a tool. So, for instance, running git --help or git branch --help would give the information needed. Now having a what's considered an intuitive interface is expected, which is why many people have problems using tools where the documentation is there, but people don't want to take the time to read it.
- atoav 6y agoI get what you are saying, and this makes sense, if you are in a situation where the problem your tool solves is so special and the target audience of your tool so involved that it makes sense to do things differently than the rest of the world. This is rarely the case. Sometimes at the end you get nothing but a wet handshake. Think about vim: it is cryptic, does everything different than everything else out there , but it gives you something in return. If you make your tool less inutive, but give users nothing in return, you are doing it wrong. If the interface of your tool does it one way in this corner and another way in that corner — so if you are inconsistent without good reason — you are doing it wrong. Interfaces are about clear communication. Interfaces are the difference between a rugged 50k$ Arri Alexa cinema camera and a 200$ camcorder: the more Alexa has physical buttons and knobs for important things precisely in the locations where they should be, precisely behaving in the way they are expected. The cheap camcorder has buttons, encoders and levers sprinkled over it seemingly random. The interface of a tool is good when it can be used intuitively even under stress, in bad weather and on drugs. This is ehat we all should aim for imo: tools that are more powerful/expressive AND more intuitive at the same time. I like reading manuals, but not for things that could have been totally obvious if somebody spent a split second thinking about how to communicate it clearly.
- u801e 6y ago> Think about vim: it is cryptic, does everything different than everything else out there , but it gives you something in return. The same could be said about git. For example, branching and merging is far better with it compared to previous VCS systems like SVN or CVS. And, like git, one had to read the documentation of those systems to have a good understanding about how to use them. > I like reading manuals, but not for things that could have been totally obvious if somebody spent a split second thinking about how to communicate it clearly. But should everything be totally obvious? For example, I doubt someone who hasn't read the documentation at some point could write a simple hello world program in most programming languages without making an error.
- potta_coffee 6y agoI've tried GUI interfaces to git before and I just haven't been satisfied by any of them. They seem to work right until I need to do something out of the norm. I did find git a huge PITA when getting started though but now that I have some muscle memory, I won't be trying anything new any time soon.
- koverda 6y agoAs far as GUIs go, I've tried quite a few and have settled on GitKraken. It's head and shoulders above the rest.
- weaksauce 6y agoI wish it wasn't coupled so tightly to emacs but magit is a phenomenal gui for git even for the more advanced use cases. if you know vim then spacemacs wraps it up in a more palatable package.
- jnurmine 6y agoI don't think Git has a "terrible UX". It really is no less worse or better than any random CLI program. But yeah, I fear people have issues with Git because unfortunately they reflect upon their experiences with other SCMs (like Clearcase, SVN, RCS/CVS, whatever) and think the same terminology and concepts apply in Git and then it goes wrong. Git is not really rocket science to use. People who find Git difficult or nonsensical should spend 4+4 hours of their weekend playing with Git while reading Pro Git. It's available for free at https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2. Specifically, read chapters 2, 3, 5, and parts of 7. You should intentionally skip chapter 10, more than likely you don't need it. Keep Pro Git handy and come back when you've a specific need.