Hacker News new | ask | show | jobs
by forrestthewoods 5104 days ago
Can we please stop pretending that Git is simple and easy to learn? If that were true then there wouldn't be "Learn how to use Git in <X> minutes!" posts every other day.

The fact of the matter is that Git is incredibly powerful but also complex and hard to learn. This isn't a bash on Git at all. It's ok! Sometimes complicated things are just that, complicated.

I believe we'll have better guides and tutorials if people stop treating Git like it's easier or more simple than it actually is.

9 comments

I haven't read any books or longer tutorials on Git. I find it easy to use and if I run into trouble I just Google after help (which happens a few times a week). Throughout the day I mostly use 9 Git commands. Here are the top 9 commands I use:

    git checkout X
    git checkout -b new-branch
    git commit
    git add; git mv; git rm; 
    git pull --rebase
    git rebase origin/master
    git push origin X
I have used this for a long time without running into huge amounts of trouble (and if I need to revert back to a specific or do anything special I can always consult Google). The bottom line is: For simple cases Git is really simple to use and to learn. You don't need to become a Git master to use Git.

The problem is that people introduce the powerful features of Git that only a few percentage of people will ever use.

Everything you just said is exactly why Git is not simple and can not be learned in 15 minutes. Just by operating from the command line you've already left the realm of "simple" in my opinion. Having to learn 9 commands is not simple. Having to hit Google for help multiple times per week is not simple.

I strongly, strongly disagree with your assertion that "for simple cases Git is really simple to use and to learn". I've watched many programmers, artists, and designers who have used source control struggle with Git from day 1. I'm sorry, it's just not simple and if it were this topic wouldn't come up over and over and over.

Again, I say none of this as a slight to Git. Complicated things are complicated. That's ok, but pretending they aren't isn't helpful.

> Just by operating from the command line you've already left the realm of "simple" in my opinion.

Git is a tool for programmers. There's no excuse for a programmer to be uncomfortable with the command line.

The problem (for me, anyway) isn't that git basically requires a command line to do anything - the problem is that git's command line syntax is exceptionally complex. I'm used to being able to do `man foo' and get a short listing of all possible orderings of parameters and arguments that a tool will accept. git's syntax is so powerful that it isn't possible to do this - a lot of the summaries in the manpages have the dreaded one-line `command [ARGS] ... [PARAMETERS] ...' that I tend to associate with a lot of the GNU tools.

Maybe if someone added an EBNF grammar to the documentation...

I am a productive programmer and I am absolute uncomfortable with the command line. I can't count the times I have written

    svn commit -m "Finally fixed bug #123!"
...only to get some weird bizarro error because I should have used '' or escaped the !. This is usually when I am deeply focused on some programming language or bug #123.

Tower.app is the only reason I've ever touched git, and the line-by-line staging and committing is nothing I would ever bother to do with a CLI.

Well, suit yourself. It's just a tremendously useful skill to have. Makes it a bit less of a hassle to ssh into the odd server to check the logs, or dump a database, or use tools that don't have a GUI.

I mean, fundamentally, you're typing things to a computer and then the computer does what you typed. Why should that notion be uncomfortable to a programmer of all people?

Oh, I can use the terminal, I can also theoretically write PHP, and every vim user can theoretically use Eclipse. But that doesn't mean that any of us would be comfortable with it - we'd all be anxious and focused on the tool (instead of the problem at hand) not to break stuff left and right.
I think this is a general problem with people with extreme addiction to IDEs and Windows based UIs.

I've known people in my team who can't do any work on the command line comfortably. I see this problem especially among people who work on Frontend and especially Java developers.

If a certain set of tools are making you dumber by the day, know it for sure that it will be automated or you will be replaced by lesser skilled cheap labor inevitably.

> If a certain set of tools are making you dumber by the day

How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way?

> know it for sure that it will be automated or you will be replaced by lesser skilled cheap labor inevitably.

Yes, the mundane, confusing use of the git command line is here to stay and the dumb "actually design and engineer an application" world of IDEs is going to be replaced by robots. You are a fucking genius. Only on the internet can such backwards and completely worthless logic be said because if you tried to say this shit to anyone in real life you'd be laughed out of the room.

"Everything you just said is exactly why Git is not simple and can not be learned in 15 minutes. " haha agreed

"Just by operating from the command line you've already left the realm of "simple" in my opinion." It's all about the audience, people who are used to CLIs will find new CLIs that are similar to the ones they already know simple.

"I strongly, strongly disagree with your assertion that "for simple cases Git is really simple to use and to learn"

I've taught git to designers in 15 minutes and had them off and running for the next ~6 months. That said even after a few months of using it I still lack understanding of some of the core concepts.

Sorry, But how is that difficult.

Even the simplest form of source control involves checkout->change/add->commit->checkin. And this is regardless of any version control system you will ever use.

The only extra stuff there is branching and merging. And to be frank. I've never felt the individual need to do that. Its a different story if you have a big team and members working on several projects which merge at a time. Now that's difficult with any VCS, not just git.

But for individual development anybody should be able to do the checkout->add/change->commit>checkin easily.

Reading through the comments here is infuriating, and it's no wonder people don't git what the big deal is.</lame>

With git you can share you current work to any arbitrary remote branch. The implications are your half baked feature can get pushed up and your coworker can do a checkout on the new remote branch. If they have suggestions they can make a change which you can cherry-pick off their branch into your branch. Also, you can branch off your current working branch, rebase master and merge their new branch in and push that up to master when everything works as expected. Try that workflow without breaking the central repo effecting everyone else's work in SVN.

Learning everything about git is hard, but learning enough git to use personally isn't that hard.

I use git personally to keep backups of my code and deploy sites I work on. I dont' work with other developers so my knowledge of git is workable, but probably super small.

Git gets complicated (but probably extremely useful) when working with bigger groups and tons of commits, branches and merges.

I feel like there's not much point in any sort of VCS lesson if it doesn't go over the more complex areas though. For example, reverting commits and resetting to earlier points in history are pretty essential actions, but both have their subtleties in Git (e.g why reverting a merge is hard, what 'reset' vs 'checkout' do) that will bite you if you don't know what you're doing. And everyone's fucked up via git rebase at least once.

If you never need to merge, revert, or in general use any of the aspects of Git that make it special then it's totally reasonable to use something simpler like built-in OS versioning or a conceptually simpler VCS like SVN. But I guess there's no reason why Github would sponsor that, right?

Sorry, maybe I've just been using Git for long enough not to remember the pain, but can you explain "why reverting a merge is hard"?

Yeah, the Git command `revert` has a bunch of kind of esoteric flags, but once you understand that it can stomp on your working dir and/or your index, it's not that hard to use. I don't know what about reverting to a point prior to a merge would be difficult, unless you are in the middle of a merge at the time. Again, sounds like most trouble is caused by not understanding how to use what is a relatively powerful piece of software.

No one is stopping you from using the built-in OS versioning, SVN or Dropbox. IMO that would be a nightmare for anything beyond the most simple cases.

Reverting a merge with git revert is not hard but it is dangerous since if you want to merge the same branch later it will not merge the commit in the merged branch at the time of the reverted merge. You have to remember to revert the revert before attempting to merge again.
I disagree, I use the very basics of Git for my very small one man projects and was very happy about it! But it just so happened that some have grown to two or three man projects that benefited greatly of actually having a distributed system already setup, this wouldn't have happened if I would have been using the wrong tools! Git is quite easy to use a at a basic level and you know it will scale just as much as you probably need, I have no idea which of my projects will grow and how big, but I do know that using the right tools from the very beginning will not come back to bite me later!
Pro Git does a really good job of explaining everything you need to know about git without trying to do it really quickly.

After reading it, I have a much better understand of git, and can work myself (and others) out of pretty much any oh-my-god-I-destroyed-everything problem I run across. You haven't broken stuff for real until you need to use git reflog.

Link to book, free to read online: http://git-scm.com/book/

I'm with you. Git is powerful but in terms of user interface it's a complete train wreck. It doesn't need more guides or tutorials as much as it needs a sane command line and help messages. There's space for a Git fork, or a higher level "porcelain", as Linus himself calls it.
I used to be like you. I didn't understand git and had no real reason to - I was used to using things like TFS and Vault just fine at work. Then a friend of mine got a job with Github and I suddenly had a reason to care about git. Once I had a reason to learn I found it much easier to understand and use, and now I've even started using tfs-git at work for fun.

So if you find git is hard or confusing just become friends with someone at github. ;)

There are a lot of cases even on bigger SW projects when for some roles(designers, tech writers) just basic git skills would save a lot of nerves to developers.

Designers can fix small things, like images, tweak html a bit etc. They dont need to know how to create/merge new branches etc..

I dont see that Git is trying to pretend that its simple but i can see how that interactive tutorial can be incredible useful to a lot of people.

its great that Git wants to explain what it got to offer to me, but why on step #7 it is mandatory to create a new account??

this killed entire positive experience, in my view.

Github wants to explain what Git has to offer you. I assume they want to see you as a potential customer, and if nothing else it gives you a real live low-risk git repository to play with after you're done with the tutorial.
Complex is not the same as complicated. Git is complex, but not complicated.
Git makes me think of Go (the board game), Rule 30 and Rule 110 cellular automata and Conway's Game of Life: a few simple defining rules that can be explain in a minute, but incredibly rich behavior follows.
Git is a very simple and powerful system covered by a hideous and complicated CLI. The simplicity is simply hidden.
Your comment reminded me of http://news.ycombinator.com/item?id=4201044 (I posted it after reading your comment), that impishly hints at what you say.