Use git from the command line (not a GUI)

http://blog.jenius.me/post/19143824330/git-from-the-command-line-or-gui

by jenius • 14 years ago

20 39 14 years ago

blog.jenius.me

dmeagor• 14 years ago

Utter crap. We used git from the command line for about a month and its a total pain. How these command line fanatics think its easier to manually pull and merge the latest version from the repository, add 10 files then commit and push is easier than clicking 'pull' and then 'commit with push' using something like smartgit is beyond me. My guess is they just used the GUI that comes with git, concluded it was rubbish (which it is), gave up and used the command line with all the silly switches you're supposed to memorize.

My advice, if you're the sort of person that uses vim then stick with the command line. Otherwise download a GUI and spend the time learning something useful instead.

roopeshv2• 14 years ago

I agree with you.

reply to op: A gui which covers 80% cases is way better than doing everything from command line, saves a lot of cognitive overload. If it's one of those 20% cases, ya, please you can fall back to command line. No, guis are not developed for those 20% percent cases; even if they did, they usually are painful like commandline as well.

MatthewPhillips• 14 years ago

GUIs are for abstracting details the user doesn't need to know about.

I would argue that revision control is too important to try and hide the details from its users. I imagine that a GUI that only accounts for best-case-scenarios and 90% tasks is a great way to shoot yourself in the foot when your repo gets into a dangerous state.

jwhite3• 14 years ago

Agreed. Every time git comes up on HN there seem to be a lot of people making arguments that boil down to "I don't want to know the details of my revision control tool's user interface", and it really puzzles me. All software development is aimed at the production and maintenance of source code, and revision control is how you manage and understand its evolution through time. Aren't hackers meant to be curious about everything? Aren't hackers meant to be experts in computing tools? Why wouldn't hackers want to know the intimate details of one of their most important tools?

jenius12• 14 years ago

If you don't know how to use the command line, that's fine, but I'm going to go out on a limb and say that most developers here do, and it's not because they are all dumb. The overwhelming point of my article is that you should be learning how to use the command line, as it is an indispensable tool for developers. If you don't agree with that, argue with me on that point. And if you want to argue with me on that point, learn to use command line well first, make a balanced assessment, then come back and argue it.

tzs• 14 years ago

> Git is all about collaborating and sharing source code, and collaborating is all about working with other developers. Every developer I know or has ever known uses git from the command line, so if you are working with them it will be easier to work together when you are both doing things the same way

I don't understand. If I and someone else are collaborating, wouldn't we each be working in our own repository, and then pushing and pulling either between the repositories, or through a third repository?

How does the interface one of uses to our repository affect the work of the other in his repository?

lnguyen2• 14 years ago

It doesn't affect how you use git for moving files/versions around. What it does affect is how you communicate with one another. You both are seeing the same thing and aren't wasting time trying to explain how to get the same info in the different tool.

jenius12• 14 years ago

Wow! Did not expect this to be upvoted, or all the hate that came out of this. Allow me to respond:

I have never collaborated that way, when I work with other devs (which I do full time), we make a project repo and push and pull to that repo. If we are working on specific features, we use branches. I have never heard of or seen the multiple repo approach, so I can't comment on that.

When I work with other people, we often come over to each others' computers to talk something out, take a look at a merge conflict, or debug things. When this is the case, it's a lot easier when the people that are working together have similar setups or use similar tools - this way it's easy to sit down at their computer and take a look at things.

philwelch2• 14 years ago

> we make a project repo and push and pull to that repo

Do you make commits directly to the remote repo, or do you have local repos that you push and pull to the remote from?

lnguyen2• 14 years ago

You're already working in the multiple repository approach (project and local). It's (almost) impossible not to with git.

leoedin• 14 years ago

I think maybe you're confusing terminology. I'd imagine that tzs is referring to the fact that git is a distributed revision control system. Each user (should) have their own local repository. Users commit, branch etc their local repository, and then push to a central repository. You can (and many people do) use git without ever having a central repository to push or pull from.

By definition collaborative git is always multiple repo (unless you're doing something weird like all using the same working directory in a network share, but that'd defeat most of the purpose of git and be a terrible idea). You work on your own repo, and then push changes when you're done.

tzs is right in that what tool I use to manage my local repo is irrelevant to the operation of the repository. Git doesn't mind what tool I used. When it does matter how you're committing is if you're discussing doing things in git - it can cause confusion when someone's trying to find a GUI menu to do something.

The remote server argument's also valid, and probably the best reason to encourage people to use the command line. I've never found a git gui that was better than the command line, and the command line is the de-facto subject of tutorials. I agree with your overall theme of "use the command line".

samarudge2• 14 years ago

I've worked with numerous UI designers/frontend devs who have never used the command line (purely because they've never needed to). The learning curve of git is steep enough without having to teach them the command line.

jwhite3• 14 years ago

Good point. Unfortunately statements like "you should probably use whatever tool is best given your skill level and the nature of the task at hand" isn't quite as catchy in a blog compared to a one-sided, opinionated, do-it-my-way prescription.

jenius12• 14 years ago

I still totally disagree with both of these comments, although I read them a couple of times and tried to shake my "this is my opinion" view. I think it's REALLY important for devs to learn command line.

The only situation in which I could claim to agree with this is if there is a super hard core and time intensive task where there is no room for learning at all, and all that matters is that a product gets out as fast as humanly possible. If that's your situation and you can't handle command line, so be it go for a GUI. But if your free time I still think you should be practicing command line.

zyang• 14 years ago

Github for Mac is definitely not the "best git app ever created".

RandallBrown• 14 years ago

What I like about github for mac is that it isn't a mapping of command line parameters to buttons. It allows you to do things simply and efficiently. It doesn't always work so well, and you sacrifice a little bit of power though.

jenius12• 14 years ago

To be fair that was an unreasonable statement and I was stating my opinion as fact. I should have said "in my opinion the best git app out there".

As far as I see it, it's the most accessible and well designed, which is the entire purpose of building a gui over something - to make it more accessible and easy to handle. But what is the best one in your opinion?

paxswill2• 14 years ago

I prefer GitX (one of the later forks, German Laullon's fork [0]). The more recent ones need some performance work, but the committing interface is pretty easy to use and presents the information in an accessible manner. It also integrates slightly with the command line.

[0] http://gitx.laullon.com/

roopeshv2• 14 years ago

I stopped at you should learn vim. Just saying, please don't suggest that we take your preferences as the necessity. There are really great programmers who can do better with GUI

jenius12• 14 years ago

I don't think it's a highly debated point that it's important to have a knowledge of vim. I didn't say you'd better be using it for all your coding (and I don't in fact), but it since a huge percentage of developers use it and it's installed by default on unix, I would say it's important to have a knowledge of.

I also didn't say that I am a great programmer, that every great programmer has to do these things, or that you have to do them. This is a push in the right direction for people learning to be developers, and I still think it's important to at least know the basics of vim, enough to get around.

jamesjyu• 14 years ago

This is absolutely wrong. There are times where using a GUI like gitx helps with visualizing exactly what is staged and what isn't. I am willing to bet that I can more quickly and selectively stage pieces of each file in a large commit much faster in gitx than you using the command line.

Bottom line: use the tool that makes sense. Don't be overly pedantic.

jenius12• 14 years ago

I dont make commits that large or complex, and if you were to ask my opinion I would say you shouldn't be. I don't write 3 pages the save my word document, I save almost every couple sentences. This makes life easier for me as far as keeping track of things.

Of course to each his own, and everyone has their own style - I'm trying to suggest a best approach for learning developers. Would you suggest that learning devs use gitx? If so, I'd love to see an article about it!

paxswill2• 14 years ago

I agree that ideally commits are atomic, but I'm not as disciplined as I should be and sometimes I end up with changes that really should be more than one commit. I can split them up from within git's CLI with `git add -p`, but this can be cumbersome. GitX lets me quickly choose which chunks and/or lines I want to commit, and exactly what is staged. There's also a commit message box right there, so I usually end up committing right there.

What I do agree wholeheartedly with is using the Git CLI for tree operations. Knowing what you're doing with `git pull`, or knowing when to rebase as opposed to a merge is incredibly useful when using git, and ultimately makes your usage of git more effective.

In short, I advocate using some sort of interface (GitX, fugitive.vim) for staging, and possible committing, but the git CLI should be used for almost everything else (except submodules, which seem to require an unholy mix of git and normal file operations).

rcthompson• 14 years ago

I use a Git GUI (Magit) and I compromise nothing on power. The only time I ever need to run git from the command line is to use a nice utility called "git-forest" (from here: http://dev.medozas.de/gitweb.cgi?p=hxtools;a=summary ), and the only reason for that is that it uses ANSI color codes to make things readable, so it requires an actual terminal.

amirmc• 14 years ago

"and you will have no idea what’s happening because [the applications] push all the logic behind the curtain"

This is why I decided to use git from the command line. I can't hope to understand everything git can/cannot do if I stick to a GUI interface. Sure, this means I have to spend more time googling but from my point of view, it's worth it (it's revision control so it's the last place I want surprises).

That said, I don't find the article's other points particularly compelling. The very last sentence seems to undermine the rest of the article [paraphrasing: "You should always use git from the command line! Heck, I'll even help you with it! But only if you've googled first."]

sthatipamala3• 14 years ago

It honestly depends on the Git GUI. Sourcetree has actually helped me use Git properly. It has stashing, rebasing and all the "advanced" features. It makes selective staging a breeze because that is an inherently visual task. I also use the branch history diagram to visualize a commit's ancestry. These two features alone have made my commits more atomic and made me more confident in using advanced branching strategies.

On the other hand, the Github for Mac app is harmful because it hides almost all of git's features and replaces them with an SVN-like workflow. This lowers the barrier to entry and simplifies the common case, but if you're not going to Git like a DVCS then just don't use a DVCS.

My take: Git's power is not in its CLI tools. It is in its unique model of trees of commits/refs, and the concept of working tree+index+history. Good GUIs make you comfortable with this model. Bad GUIs hide it from you.

jenius12• 14 years ago

I can agree with this. I haven't used sourcetree, so my post was inherently biased in the respect. If it does have all the advanced features, that's awesome.

I still stand by my point though - you should know how to use git from command line. If you know it well and you want to try something else, go for it. But I think it's a very bad idea to learn only a gui and not be proficient with command line git.

sthatipamala3• 14 years ago

What GUIs are you basing your article on?

roryokane• 14 years ago

I actually learned Git only with the help of GUI. Beforehand, I read a bunch of tutorials, but I just couldn't figure out the process of using Git, and how to use it in my everyday workflow. Then I used Tower (http://www.git-tower.com/) when it was in beta, and everything became so much clearer.

The GUI made everything intuitive by leading me through common tasks, instead of forcing me to memorize what is related to what. It showed file diffs on a bottom pane when I click on them, revealing that what Git cares about are changes to files. It showed a commit message draft on the right, indicating that what I am always working towards is a commit. The tabs clearly divided the workflow into two rough modes: making changes and examining history. These visual cues helped me understand the concepts within Git. Tower is also faster at staging only certain lines of a change, letting me use the mouse to point to those lines rather than going through the git add -i workflow of "split this hunk, split it again, yes stage that one, no don't stage that one", etc.

Now that I understand Git's concepts, I can use and have used Git on the command-line, but for now I use the GUI whenever possible. I still don't feel confident enough in my knowledge of all of Git's details, such as the commands to resolve merge conflicts, so the GUI's continued guidance is reassuring. Perhaps after I've used it actively for a few more months, a workflow like jenius describes at the end, using custom aliases for commands I use often, will be better for me.

jenius12• 14 years ago

This is interesting to hear - thanks for posting. I've taught a number of people to use git and got them to the point where they are moving quite quickly through command line aliases within a very short time. But I can see how if you are totally on your own it could work to approach this way.

I would still advocate moving as hard towards cli as you can though. Having someone on deck to help you out if you're confused is key - it seems like you are using the gui for that instead of an actual person right now, which is interesting.

Use git from the command line (not a GUI)

Related Stories