In the introductory video for Getting Git I talk about using Git from the command line instead of through a GUI. I label GUIs as evil wizards and s...
For further actions, you may consider blocking this person and/or reporting abuse
FWIW I started out with SourceTree, which I enjoyed a lot and let me get to know Git in a surrounding I was familiar with (meaning GUI). After switching to Linux and being at a loss of a good GUI client, I went to the command line. That was much easier than expected, because I already knew what I wanted to do, so I only had to learn one new thing (commands) instead of two (commands and Git).
It often pays off to sooner or later go down to the bare metal, especially for tools you use a lot. But I disagree with the general idea that this is always better for everyone. Getting started on a high level of abstraction and moving your way down the stack over time and when needed is a valid approach IMHO. (Same can be said for IDEs, for example.)
I came here to say the same thing :D
For me I always felt (and still feel about Github) like I'm never quite sure what I'm about to do, but at the same time that also applies to my ability to un-do anything the GUI does by accident.
I thought Git was hard until I used it on the command-line, since then it's the only thing I use for Git. The text-based interface is very flexible, and since working with it goes a little slower (you have to enter commands individually) it seems to reduce errors and make solving errors that happen easier. With a GUI for Git it's too easy to do 5 or 10 wrong things at once :/
I dont agree with you, Iam used the command line 5 years but switched to smartgit 1 year ago. To understand git you should not use a gui, but if you already did there is no reason to do it not. Iam just to lazy to do all the things that does smartgit for me by hand.
We might be closer than you think. Your statement of:
Is in perfect agreement with my points.
I would argue the exact opposite. The commands are not the important part of git -- the understanding of how the tree is shaped and how the child/parent relationship works is. That is a lot easier understood visually than textually.
If you are simply memorizing commands, you're not utilizing git to its potential.
You're extrapolating too far. The commands are indeed not the important part of Git, understanding how Git works is important. We're in perfect agreement.
This article suggests a GUI may abstract this and deprive someone just starting out with Git the chance to learn as much as they may from the command line.
There may be some availability bias here since you're already comfortable from Git. I also have a firm grasp on Git and use a GUI for some of the more visual aspects of Git (tree differences, code review, etc). Nothing wrong with that.
In the end, if the only way you know Git is by pressing some buttons in a GUI, then you don't really know Git. I encourage those to try and use the command line to drive their understanding of Git.
I would be curious to see some evidence that implies people who use the command line understand git more than those who use GUI. I think this a bad assumption.
One of the problem with Git (to be fair, it is a common problem to many matters in the programming world, since we all are so smart and all are so right all the time... but I feel this is even stronger when it gets to Git), is that it allows to do many things in many different ways, none of which are right nor wrong.
And since GUIs basically offer a layer over git, the GUI-user is bound to the said GUI's biases. One has to live with the way the GUI-maker feels Git.
Some GUIs try to make a smooth transition by using language from the SVN world and the illusion one is working under the SVN paradigms... but then; what does it mean when in such a GUI there is an "update" button? does it pull? does it fetch? or does it stash->pull->pop(merge) to keep it more SVNy ?
What does the checkout button do? why is it asking me for an URL when I want to switch branches? oh; I must use the dropdown down there ... you don't change branches with buttons...
Anyway, none the the mentioned examples are completely wrong when you know what you are doing and the problem is that GUIs tend to be used by newcomers.
Indeed strangely enough, GUIs might be more suited towards Git gurus who know all about it ... but then again, the said gurus are likely to prefer command line to have all the switches even the most obscure ones.
The only in-between solution might be a GUI that generates git commands on-the-fly and always offers the possibility to view what one is about to run and the possibility to modify it (a bit like SQL developer is doing when creating Oracle users or creating tables through wizard).
My GUI has a button at the top that lets you open a command line. If it's easier to do something in command line, the button's always right there for you. In no way am I "bound" to the GUI. I very rarely find myself using it except for running cleanup aliases though.
I think newbies should use a GUI instead of a command line. A GUI is much more discoverable, and the command line just encourages XKCD 1597 style uses.
Let's say A and B are new to git, and discovered they had one change that should have been on their last commit. Now, seasoned git users would be saying that
git commit --amendis the obvious answer, and they're right. However, A and B just recently switched from Subversion, so they don't know that Git has an amend function.A is using the command line, so they just make another commit using the same
git add . && git commit && git pushspell they've been reciting. Why would they read the docs when they think they know the solution already?B is using a GUI, and notices that on the commit dialog there's a checkbox that says "amend last commit". The feature is right there discoverable and not hidden among the infinite possibilities of flags.
Now I do argue that a better shell can change a lot of this. Perhaps when you start typing
git commit, it pops up a list of available, or at least commonly used, flags, akin to an IDE.I'm confident that I understand git better than most people and I highly suggest people use a GUI instead of command line. Git is visual. You simply can't work efficiently from the command line. If you doubt that, we should do a comparison sometime.
Bold statement. How did you come to reach your confident understand of Git?
I should rephrase: You simply can't work AS efficiently from the command line than from a good GUI. By nature, git is visual because it's a tree structure. And I came to that conclusion by comparing my workflow with other peoples' workflows.
C'mon, you know there are so many better ways to make the same point.
What an insightful contribute… Allow me to contribute by reporting your comment.
Challenging my self into using the command line actually forced me to understand git better.
When using a GUI, you can always blame your problems on it, but not when you're using the command line, you're accountable for every command you write, and that makes the difference.
It appears that the author found a lot of traction about this topic, but automatically disregards other people's reasons for using GUIs and the advantages that come with it.
I, for one, started by purely using GUI. At that period, my usage of Git was basic, and GUI was perfect for this. Eventually, as my understanding of Git improved, I got to the comfort level where I can utilize command line to do more advanced manipulation. GUI is not sufficient anymore.
I still use GUI, though. For me, not an absolute exclusive keyboard user, it is much more easier to execute
git guiand use my mouse to see all the changes that are pending to be committed. If you like to use several keyboard commands to do the same, you can have it your way, sure.But don't tell me I should not use GUI because it is evil. That's one of the sillier statements I've read.
Calling yourself a master of git does not improve your picture either.
As the author, I'm curious where you read the statement you "should not use GUI because it is evil".
I stuck to a Git GUI for a number of years, but recently switched over to the command line, and I gotta tell you, I wish I'd done it sooner.
I was able to get things done in the GUI (SourceTree, GitKraken, and others,) but I had constant merge conflicts, and otherwise got myself into difficult corners, over and over and over again.
Moving to the command line allowed me to understand what I was doing to a far greater extent, and it was actually surprisingly easy.
Anyway, I'm glad I took that step. I haven't boxed myself into one of those nasty Git corners since I gave up the GUI habit.
I'm youngest developer on our team and to be honest, never tried anything but GUI for git till last year.
I decided to actually KNOW what am I doing ... so, switched to Linux and started doing it by command line.
Heck, now they all come to me when they have problem using git
We use Git at work. We used to always have weird merge situations, gibberish commit trees, lots of conflicts, and I had to troubleshoot someone in the team at least thrice per week.
Until the day I read this guide. I understood what branches really are, what these strange “HEAD”, “origin/feature/mystuff” were, and why some people in our team were actually merging their work with out-of-date head references without knowing it.
Of course a good GUI can show how to solve your issue. It’s what I used for troubleshooting and fixing stuff easily. It just doesn’t explain it, and since we learned how Git actually works without blindly relying on GUI buttons, our issues magically disappeared, as well as the need to troubleshoot.
Initially, I found that having a GUI allowed me to become more confident with the basic Git workflow, even after reading through the basic functions of the CLI and having a fair amount of experience utilizing other command-line tools. Though, after using Git for a few years now I can't even remember the last time I used a GUI.
Nevertheless, I agree that learning Git using a GUI, with no knowledge of the CLI could definitely lead to issues and hinder productivity down the line.
What about when you need agility? I understand your point, but if you aren't capable to do things faster then you loose opportunities. Some times you need allies to reach your goals. GUI clients may be good tools for improve your process.
I'd use the analogy of learning photography: you start with a manual analog camera, shooting black & white, and once you've grasped the theory, you upgrade to colour and eventually digital. Those little burn and dodge tools in Photoshop make a lot more sense when you've actually burned or dodged with your hand or a stick in a darkroom.
I used git for years in the command line, and once some nice GUIs came out, it was like a breath of fresh air. Being able to visualise trees, changes, and diffs is a huge boon to many developers I know. But, as with photography, it's important to understand the underlying theory behind each button you press.
Should a knowledgable developer stick to CLI-only git? Not in my opinion. Should you start there? Absolutely.
I think this idea can be married to the IDE vs non-IDE "debate" very well. Understanding every tool you use at a fundamental level is a high aspiration and something that will make you a very powerful developer. Not understanding the tool (or what the tool helps with) completely, where you cannot function well without it, is not a situation where you should be ashamed or an feel like an impostor developer. Nor should it be dictated that using without understanding it fully is doing anything by "coincidence." That's absurd. Use the tools you can use to get your desired end-product. If you can't get the desired end-product with your tools and current knowledge, then it's time to invest a bit more in your knowledge.
The GUI version of Git abstracts away a lot of finer details that, frankly, most of us don't know, don't care to know, and don't need to know. Not saying that a broader understanding isn't useful, but it's not required. Understanding Git enough to use it at the command-line level is just one of the next steps you can take in expanding your craft. For some, it might not matter as you will never manage your own version control, while others it will be essential.
I agree. I use Tower on occasion to look at file diffs or clean up branches, but I use the git CLI (and some custom aliases/bash functions) to manage projects/files.
I find this is a lot easier, and when there's an error, I don't get a cryptic popup from a GUI that's playing telephone with the actual commands and responses it runs; I get hands-on, first-hand messages from the source.
Though this comfort comes from a few years' time working from the Terminal; if we were talking about the file system– CLI vs GUI– I would go with CLI as well.
I'm using both my IDE (where I can see what commands it executes for each GUI action/shortcut I use) and for some things like interactive rebase/squashing I'm using command line.
If you have a GUI you understand and like you are still not bound to it.
I am using VS 2017 Team Explorer for staging, committing and syncing. For the detailed and complex things TortoiseGit, no problems here. Its just a huge time saver and using a GUI does not mean a lack of understanding.
And im a frequent linux user who really likes consoles to work.
What about this tool, which simplifies opening repo in browser from terminal?
github.com/plutov/o
I like
git openbetter - github.com/paulirish/git-openIt's good! But
otool works for different git hostings :)So does
git open.I deleted my previous comment, but since a cache is keeping it around, I should apologize for making a point that I missed when originally reading your article!
Whoops, sorry about that. Will fix. 😳
No problem :)
I think it's a case (and there are many others) of there being great value in learning the basics and understanding them before taking the short cut.
Anyone know the git cmd that shows me the three most recent other branches I have edits on?
git branch --sort=-committerdateI agree if you don't understand what is happening behind the scenes, then you'll easily get lost and confused. I mean I like hooking Git up to my text editor or IDE, but I always start with the CLI