I wish git (and mercurial for that matter) could properly backup large files. I have some sql files > 100MB that I can't check into source control.
A simple guide for getting started with git
61–70 of 132 posts
Re: A simple guide for getting started with git
#62The 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…
Really? You don't know what a repository is? Or are you just being hypothetically ignorant? I believe that somebody googling git usage is going to be a little bit conversant in the topic of version control.
Well, we use Git at my work, and I have a vague idea of what a repository is... But not really.
I also have to say this:
> I believe that somebody googling git usage is going to be a little bit conversant in the topic of version control.
So you seriously believe somebody trying to learn about version control will already know about version control?
Re: A simple guide for getting started with git
#63Having used SVN, and in the process of starting a new job where they use GIT, this actually helped quite a bit. It was quite timely for me.
Re: A simple guide for getting started with git
#64Earlier quoted context omitted.
Really? You don't know what a repository is? Or are you just being hypothetically ignorant? I believe that somebody googling git usage is going to be a little bit conversant in the topic of version control.
Well, we use Git at my work, and I have a vague idea of what a repository is... But not really. I also have to say this: > I believe that somebody googling git usage is going to be a little bit conversant in the topic of version control. So you seriously believe somebody trying to learn about version control will already know about version control?
Well, you proved me wrong, but a few minutes ago I did believe someone googling about git would know something about version control.
For the same reason that I believe someone googling about haskell or erlang probably knows something about programming.
Re: A simple guide for getting started with git
#65Earlier quoted context omitted.
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…
Yes, you might be right on this. I will think about it. If you have links where something like this can be found, i would appreciate it. Thanks!
Hi, shameless plug but I've found people enjoyed these two guides on traditional version control and distributed version control:
http://betterexplained.com/articles/a-visual-guide-to-versio...
http://betterexplained.com/articles/intro-to-distributed-ver...
One technique I use is trying to explain the underlying concepts using analogies to what people already know. Most people are familiar with using "Save as..." to create MyResumeOct2010.doc, MyResumeFinal_v1.doc, MyResumeFinal_REALLY.doc, etc. Version control is like a beefed up, automatic "Save as...". You can jump to any version without a mess of different files.
Distributed version control lets you "peel off" individual changes and send them to anyone. If you are making a shopping list with 3 people, you can "peel off" the items that Alice, Bob and Charlie added and put them on your own list.
Once the concepts are clear, you can give them proper names (diffs, revisions, commits, etc.) and things start to click. Anyway, that's what I've found helpful, good luck!
Re: A simple guide for getting started with git
#66The 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…
Really? You don't know what a repository is? Or are you just being hypothetically ignorant? I believe that somebody googling git usage is going to be a little bit conversant in the topic of version control.
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.
Re: A simple guide for getting started with git
#67"There's just one thing, Dude. Do you have to use so many cuss words?" -- Big Lebowski
Joking aside, there is really no need to ruin a great guide by swearing in the subtitle.
I'm not sure I'll ever understand why developers think they need to swear in articles. In this instance, is it because the author is writing in nerd (addressing a seemingly technical concept) and needs to show his article has some universal accessibility by using one of the most understood terms for excrement in the subtitle?
I mean, I'm glad he warned me there is no deep poop in the subtitle because I won't read ANYTHING that has deep doo-doo in it.
Show some maturity: s/shit/stuff (that'd be Sed for replace the word 'shit' with the word 'stuff')
Re: A simple guide for getting started with git
#68Earlier quoted context omitted.
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…
> 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 open up a terminal, type out a path, then try to remember some archaic command syntax.
As I say, lots of programmers claim to be more productive from the command line than they are in a visual interface. It doesn't make much sense to try to dispute that, but I still find it quite baffling.
Re: A simple guide for getting started with git
#69I think git is not easy to use, and the proof of that is that at least once a month there is a "how to use git" tutorial on the front-page of HN.
I'm not saying git is a totally bad system, but I disagree with people who think git is easy to use.
You don't see thousands of tutorials on the web, and tutorials hitting the HN frontpage on "How to use Subversion", "My personal Subversion workflow", "My .bashrc file containing my aliases for Subversion". I assert the reason is, that they are not necessary (and not, for example, that nobody uses Subversion, or nobody who reads HN uses Subversion.)
Re: A simple guide for getting started with git
#70Why not just download Eric Sink's "Version Control by Example" ? http://www.ericsink.com/vcbe/
The book is free or can be purchased and explains both git and Mercurial with similar examples. We use it at our office to get novices up to speed on source control.