4 ms·

Use git from the command line (not a GUI)

20 points by jenius 15y ago

dmeagor 15y 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.
- roopeshv 15y 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 15y 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.
  - jwhite 15y 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?
- jenius 15y 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 15y 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?
- lnguyen 15y 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.
  - deleted 15y ago
    [deleted]
- jenius 15y 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.
  - philwelch 15y 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?
samarudge 15y 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.
- jwhite 15y 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.
  - jenius 15y 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.
    - jwhite 15y ago
      I think it's REALLY important for devs to learn the command line too. But not everyone on the project who needs to interact with revision control is necessarily a developer. They may not have the background and skills to come to grips with the command line.
    - samarudge 15y ago
      If someone is joining a company to work full time, I can see how teaching them to use the tools "correctly" is good, and new skills are always a plus, but I frequently work on projects with freelancers whom I will only speak to for 4/6/8 weeks then they'll move on, particularly with javascript/frontend devs and designers it's tough enough to get them to use version tracking correctly with something 'point-and-click' (GitHub for Mac etc.), if I told them they had to learn how to use the command line too, they'd ether tell me to go away or increase their fee. People /should/ know how to use the command line, even if they prefer to use other tools daily, but often it's not practical to force people to use it.
zyang 15y ago
Github for Mac is definitely not the "best git app ever created".
- RandallBrown 15y 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.
- jenius 15y 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?
  - paxswill 15y 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/ http://gitx.laullon.com/
roopeshv 15y 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
- jenius 15y 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 15y 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.
- jenius 15y 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!
  - paxswill 15y 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).
    - jenius 15y ago
      Fair enough. I'm going to check out the two you mentioned and give them a shot when staging/committing, and see how I like it. I assume they will slow me down since I commit very atomically almost automatically, but it's more than worth trying. Thanks for the input!
rcthompson 15y 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 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 15y 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."]
sthatipamala 15y 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.
- jenius 15y 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.
  - sthatipamala 15y ago
    What GUIs are you basing your article on?
    - jenius 15y ago
      Mostly github for mac, with a sprinkling of other random ones I have tried. Since I can already smell followups saying "you have to try every single one before you write an article like this!!1!", let me counter by saying exactly what I said above: It doesn't matter really which GUI we're talking about. You should learn command line git anyway. That was the point of this article.
      - 15y ago
roryokane 15y 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/ 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.
- jenius 15y 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.

20 points by jenius 15y 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.

roopeshv 15y 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 15y 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.
- jwhite 15y 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?
jenius 15y 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 15y 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?

lnguyen 15y 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.
- deleted 15y ago
  [deleted]
jenius 15y 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.
- philwelch 15y 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?

samarudge 15y 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.

jwhite 15y 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.
- jenius 15y 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.
  - jwhite 15y ago
    I think it's REALLY important for devs to learn the command line too. But not everyone on the project who needs to interact with revision control is necessarily a developer. They may not have the background and skills to come to grips with the command line.
  - samarudge 15y ago
    If someone is joining a company to work full time, I can see how teaching them to use the tools "correctly" is good, and new skills are always a plus, but I frequently work on projects with freelancers whom I will only speak to for 4/6/8 weeks then they'll move on, particularly with javascript/frontend devs and designers it's tough enough to get them to use version tracking correctly with something 'point-and-click' (GitHub for Mac etc.), if I told them they had to learn how to use the command line too, they'd ether tell me to go away or increase their fee. People /should/ know how to use the command line, even if they prefer to use other tools daily, but often it's not practical to force people to use it.

zyang 15y ago

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

RandallBrown 15y 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.
jenius 15y 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?
- paxswill 15y 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/ http://gitx.laullon.com/

roopeshv 15y 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

jenius 15y 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 15y 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.

jenius 15y 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!
- paxswill 15y 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).
  - jenius 15y ago
    Fair enough. I'm going to check out the two you mentioned and give them a shot when staging/committing, and see how I like it. I assume they will slow me down since I commit very atomically almost automatically, but it's more than worth trying. Thanks for the input!

rcthompson 15y 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 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 15y 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."]

sthatipamala 15y 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.

jenius 15y 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.
- sthatipamala 15y ago
  What GUIs are you basing your article on?
  - jenius 15y ago
    Mostly github for mac, with a sprinkling of other random ones I have tried. Since I can already smell followups saying "you have to try every single one before you write an article like this!!1!", let me counter by saying exactly what I said above: It doesn't matter really which GUI we're talking about. You should learn command line git anyway. That was the point of this article.
    - 15y ago

roryokane 15y 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/ 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.

jenius 15y 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.