Live data from Hacker News

A simple guide for getting started with git

rogerdudler.github.com

31–40 of 132 posts

Re: A simple guide for getting started with git

#31
You should mention the "git gui" command alongside gitk. It's a really great way to see the changes in your working tree, stage files into the index, and finally commit. You can even right click on hunks in the diff and select "Stage Hunk for Commit" to stage just parts of a file. Generally I'm a command-line person but git gui is a lot easier to use than "git add -i" Also, git novices whom I know have generally reacted well to git gui.

Re: A simple guide for getting started with git

#33
The idea is nice, but the implementation is crap.

I don't use git but I'd like to. I guess I'm the target market in a sense. The key to simplifying a tutorial is removal of jargon. Just tell it like it is.

FYI: This is the line at which I closed the tab: "checkout a repository" - wtf. I don't know what a repository is and now I'm checking it out? is checkout a typo? maybe it should be check-out? either way, I have no way of knowing and confusion has set in. Unfortunately, tab is closed.

Re: A simple guide for getting started with git

#34

I don't get this. Sure, the tutorial looks very pretty, but it does not explain any concepts. "Create a new repository." What is a repository? What do I do with it? The HEAD is a tree "which points to the last commit you've made". Huh? A tree can point? The one in my garden can't. Also, what's a commit? I thought "commit" was a verb, not a noun. And so on. It's nice that people want to make something as complex as gi…

I agree with you in general, but I feel like you take a wrong perspective of it.

The author takes a top-down approach to teaching, which basically means that he thought about this tutorial from his perspective, someone that was already intimately familiar with the details. This, as you pointed out, is wrong. If this is a tutorial for beginners, you need to have some explanation of what "checking-out" means, what "trees" are, etc. If this tutorial is for advanced users, however, its too sparse to give any new information. So in the end, the tutorial is pretty, but helps neither advanced users nor beginners.

I feel like the examples you give, however, are inefficient for a guide as well -- at what point do we start making assumptions about the reader? For example, you give the example that a beginner might not understand trees, but how do we know they understand anything? Do we believe they don't know trees, but do know how to program, and if so, to what level? Do we assume they are proficient in the terminal, and can even install git if it is not already present? The problem with your approach is that it seems like there's never a point at which we stop.

When I learned a new romantic language (Spanish), we didn't start all the way at the beginning with the alphabet, nor did we try to explain conjugation, past participles. We started with simple phrases -- "Hello", "How are you", "The weather outside is nice", without a real understanding of why we said them. Then, over the years, we peel back the onions of why phrases were the way they were -- Adios (goodbye) was a combined form "A dios"--to the gods. But you shouldn't try to teach that from the onset as you'll overwhelm the learner -- you just continually add on layers until they discover themselves.

Similarly, I feel like for this scenario, a tutorial should set up a scenario that fits the commands perfectly -- don't explain why we use git commit -m, have the first user just go through a few scenarios where they just do it. Then, as they learn, build advanced git tutorials that add on layers, so suddenly they start to uncover all the nuances that git has to offer.

Now, granted, that doesn't extend itself to a "simple guide" if you will, but I feel that these iterative examples that let you think are much better.

Re: A simple guide for getting started with git

#35

Earlier quoted context omitted.

Thanks for your feedback! I completely understand your point. Maybe it would make sense to make another guide with an intro on Source Control Management systems and link it in the git guide. Currently, you need to have a little bit of knowledge on an SCM. But I will think about it.

Hmm, I'm not sure "having a little knowledge on an SCM" does the trick. Let's assume that I've used subversion for years (which surely is SCM). Therefore, for instance, I know that a repository is something on a server that can hold all relevant for my current team (we'll checkout a subdir for each of subproject). Also, I know that committing means sending a change to the server. I also know that I can lock a file an…

I don't know if they are necessarily Git specific, but probably are distributed version control system specific. For example the concept that committing would record your changes to the local repository wouldn't make any sense to a Subversion user, but would make a lot of sense to say a user of Mercurial.

Re: A simple guide for getting started with git

#36

I don't get this. Sure, the tutorial looks very pretty, but it does not explain any concepts. "Create a new repository." What is a repository? What do I do with it? The HEAD is a tree "which points to the last commit you've made". Huh? A tree can point? The one in my garden can't. Also, what's a commit? I thought "commit" was a verb, not a noun. And so on. It's nice that people want to make something as complex as gi…

If you want to learn, get that version control book by Erik Sink. And like other best things in life, it's free (including shipping).

Re: A simple guide for getting started with git

#37
post #3

Nice. I will definitely show this to people who are new to SCM. How about adding Linux install instructions? Something like, apt-get install git for Debian based distros.

pixeldude,

Incoming pull request, in case you don't see it.

https://github.com/rogerdudler/git-guide/pull/2

Re: A simple guide for getting started with git

#38

I don't get this. Sure, the tutorial looks very pretty, but it does not explain any concepts. "Create a new repository." What is a repository? What do I do with it? The HEAD is a tree "which points to the last commit you've made". Huh? A tree can point? The one in my garden can't. Also, what's a commit? I thought "commit" was a verb, not a noun. And so on. It's nice that people want to make something as complex as gi…

Presumably I know why I want to use git before I look at this guide. Also, I know what a repository is (in the English sense), but just in case, I typed define repository into google: "A place, building, or receptacle where things are or may be stored." Now "Create a new repository" really is dead simple.

The term commit and it's function are made clear in the "add and commit" section. Perhaps the order of "trees" and "add and commit" should be switched, but this hardly makes the guide unusable.

If in doubt, type the commands and see what happens. And, at the very very least, the article is titled "git - the simple guide", not "version control terminology - the simple guide".

Perhaps not everyone is the intended audience, and perhaps some people could supplement this guide with additional reading. I've never used git, and I found this guide clear and useful.

Post reply on HN