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.
A simple guide for getting started with git
81–90 of 132 posts
Re: A simple guide for getting started with git
#82Earlier 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.
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
#83The 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.
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
#84I would recommend http://gitimmersion.com/
Re: A simple guide for getting started with git
#85I 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…
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
#86To 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
#87Earlier 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…
Re: A simple guide for getting started with git
#88Earlier 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…
Re: A simple guide for getting started with git
#89Re: A simple guide for getting started with git
#90Of 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.