Use git from the command line (not a GUI)(blog.jenius.me)
blog.jenius.me
Use git from the command line (not a GUI)
http://blog.jenius.me/post/19143824330/git-from-the-command-line-or-gui
41 comments
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]
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.
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.
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".
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".
You're already working in the multiple repository approach (project and local). It's (almost) impossible not to with git.
> 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?
Do you make commits directly to the remote repo, or do you have local repos that you push and pull to the remote from?
Direct commits to github repo. We usually have a master and develop branch as well as smaller branches for separate features if needed. These are not massive enterprise scale projects, and usually there are 2 to 4 devs working on it at once, for perspective.
Edit: Sorry apparently this wasn't clear. I make commits to a local repo and push to github. The local and github repos are rarely out of sync.
Edit: Sorry apparently this wasn't clear. I make commits to a local repo and push to github. The local and github repos are rarely out of sync.
It is not, to my knowledge, possible to commit directly to github. You can create a commit locally and push it to github, sure, but that is not the same thing.
What commands do you use to accomplish this?
What commands do you use to accomplish this?
Quick clarification - I misunderstood the original argument here. Yes there are local repos and a github repo, absolutely. I almost ignore the local one because it only exists (for me) in order to be pushed up to github.
This is correct. The repo doesn't care what the individual users are using, and it can't tell. On the flip side, this was never something I disagreed with. I was saying that I often work with other devs in person and we will frequently go over to each others' computer to talk something out, debug something, etc. In this aspect, it's easier to use similar tools.
If you always work in complete isolation, disregard this part of the article. I just assumed that most people don't.
This is correct. The repo doesn't care what the individual users are using, and it can't tell. On the flip side, this was never something I disagreed with. I was saying that I often work with other devs in person and we will frequently go over to each others' computer to talk something out, debug something, etc. In this aspect, it's easier to use similar tools.
If you always work in complete isolation, disregard this part of the article. I just assumed that most people don't.
So you never "git clone" to your local machines? You don't "git push" and "git pull"? I've never heard of anyone using Git that way.
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.
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.
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.
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.
What GUIs are you basing your article on?
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.
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.
>Since I can already smell followups saying "you have to try every single one before you write an article like this!!1!"
Nope, not planning on doing so. I just wanted a context in which to evaluate your stance.
HN is weird in that people only up vote opinionated articles but then berate you in the comments for being "biased". Good on you for contributing your opinion. =]
Nope, not planning on doing so. I just wanted a context in which to evaluate your stance.
HN is weird in that people only up vote opinionated articles but then berate you in the comments for being "biased". Good on you for contributing your opinion. =]
[deleted]
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.
Bottom line: use the tool that makes sense. Don't be overly pedantic.
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!
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!
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).
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).
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!
"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."]
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."]
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.
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.
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.
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.
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.
Github for Mac is definitely not the "best git app ever created".
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?
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?
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/
[0] http://gitx.laullon.com/
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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?