

Use git from the command line (not a GUI) - jenius
http://blog.jenius.me/post/19143824330/git-from-the-command-line-or-gui

======
tzs
> 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?

~~~
jenius
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
> 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?

~~~
jenius
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.

~~~
fr0sty
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?

------
sthatipamala
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
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
What GUIs are you basing your article on?

~~~
jenius
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.

~~~
sthatipamala
>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. =]

------
jamesjyu
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
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
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
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!

------
amirmc
_"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."]

------
roryokane
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.

~~~
jenius
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.

------
rcthompson
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.

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

~~~
jenius
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
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/>

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

~~~
samarudge
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.

------
roopeshv
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
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.

------
dmeagor
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.

~~~
MatthewPhillips
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
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?

