Live data from Hacker News

A simple guide for getting started with git

rogerdudler.github.com

81–90 of 132 posts

Re: A simple guide for getting started with git

#81

It so happens that I started using git just 2 days ago. Reading the git help was pretty useful, but I didn't want to spend a week reading pro git(the ebook). This tutorial is pretty useful to get someone quickly up and running, and certainly a better alternative than spending my time learning git (not that I won't study the details as I go along) rather than the actual project.

I would advice you to read "Pro Git".

Re: A simple guide for getting started with git

#82
post #66

Earlier quoted context omitted.

Really. For me a repository is somewhere I might leave something...storage...like dropbox maybe? I don't know what it means in the github jargon sense. I have no idea what version control is specifically, but again, I guess it is v1.0 v2.0 etc.

It is very much like dropbox, in that a repository is a special purpose folder that the git application can run against. One difference is that you can have multiple of these folders, not only on your local machine but also on remote servers.

So let me see if I get this right.

A repository is like a slave folder to a master folder, when the master folder is updated (the github folder) the contents are automatically copied to all repositories. In this way, it saves from having to update all folders manually and keeps everything in one place, with only one thing needing changes, which then propogate automatically to where they are needed?

Any idea what version control is?

Re: A simple guide for getting started with git

#83

The giant font doesn't make it any easier to understand. Stuff like 'your local repository consists of three "trees" maintained by git' only makes sense to people who already know how git works.

Exactly. You can use a big happy font, but when step 2 tells me to create a "repository" and I'm already stuck.... well, that's a problem.

A repository for what? Is this a folder on my computer somewhere? Should I be moving code into this folder? No idea.

In order to make this tutorial helpful, why not take a simple project and get it working under Git?

For example, let's say right now I have a folder that consists of a single source code file like testapp.php, a README.txt, and then a content folder with some images in it. How can I take this mini project and start using Git to manage my code?

I'm seriously that "beginner" when it comes to Git. I do not understand it at all. Maybe I'm not your audience. This tutorial was FAR from simple IMO.

Re: A simple guide for getting started with git

#84
It is neither helpful to an expert, nor to a beginner. A beginner will have no clue what the article is talking, like tree etc. An expert cannot really use this as a quick reference or something. Looks flashy, but is it anything more?

I would recommend http://gitimmersion.com/

Re: A simple guide for getting started with git

#85

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…

Indeed. I've been using source control of various flavors for 15 years now, and that "Trees" section is completely unparseable by me. Why are there 3 of them? Why do I care that there are 3 of them? What do I use them for? If I don't use them all directly, why are we talking about them? Further, why are we talking in terms of the actual command-line commands? Surely a version control system as popular as this has too…

> Further, why are we talking in terms of the actual command-line commands? (...) I'd much prefer you tell me the name of the popular Windows/Mac client and walk me through the workflow I'll actually use on a day-to-day basis.

To be perfectly clear, the command line tools ARE the popular client. The only widely used GUI I'm aware of is the one specific to Github. There are others but they generally expect you to be familiar with the command line workflow. Perhaps this is because Git is easily integrated into IDEs in a way that makes sense for that particular IDE; perhaps it's because the command line interface is actually very good, with features like spelling suggestions (if you've mistyped a command name) and autocompletion scripts (sort of like IntelliSense).

By the way, I can't speak for Windows users but the overwhelming majority of Mac and Linux developers are well aware that their shiny GUIs are thin layers over the gross 70s Unix parts underneath. In this world there's no stigma concerning beards or the 70s, and your dismissal of the command line comes across as backwards and absurd. It's a bit like badmouthing non-Hollywood filmmakers because a lot of them work in foreign languages and you "don't want to read some German thing for four hours" when you go to the movies.

Re: A simple guide for getting started with git

#86
Make a tutorial that follows the workflow of a bad developer, and you can get a lot of people on board. Show us how to undo terrible mistakes. Show us how to work with other bad developers and working with their terrible mistakes.

To get people on board with Git, you gotta show that anyone can use it, efficiently. That's how you get the most number of people to adopt - when they can easily see themselves using and trusting Git.

Re: A simple guide for getting started with git

#87
post #60

Earlier quoted context omitted.

> I don't have to actually type commands into a command prompt like some bearded guy from the '70s Really? I mean, really?

Absolutely. I am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I think visually, so looking at a visual interface such as Windows Explorer is several orders of magnitude more productive than fiddling around with cd/ls to give me a picture of what's going on. Once I find what I'm looking for, I'd much prefer to right click on it and get on with my day than…

I don't think it's a matter of programmers being productive per se. The greatest benefits of command line are the ability to easily store, share and reproduce actions. It's just text. You don't need screenshots to explain something, and everything is scriptable.

Re: A simple guide for getting started with git

#88
post #60

Earlier quoted context omitted.

> I don't have to actually type commands into a command prompt like some bearded guy from the '70s Really? I mean, really?

Absolutely. I am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I think visually, so looking at a visual interface such as Windows Explorer is several orders of magnitude more productive than fiddling around with cd/ls to give me a picture of what's going on. Once I find what I'm looking for, I'd much prefer to right click on it and get on with my day than…

Note that source control in particular is particularly amenable to the command line, since the output of source control commands is blobs of text that refers to text files on disk; grepping around in it and wanting to access, process, or modify those files by name is a common operation.

Re: A simple guide for getting started with git

#90
I think this guide needs some general explanation of what git is, and what the thinking behind it is (like here: http://progit.org/book/ch1-3.html).

Of course you can get started with this guide, but you have no clue what you are doing. It's learning by following the recipe versus learning by understanding.

Post reply on HN