Today I will teach a classmate of mine a bit about git. I searched the web for
tutorials, so I can refer to them, but hey, there are thousands out there.
So I came to the question: Which one should I link? They have things in common,
some of them are better, some or not so good. But some of them have really
different approaches on how they teach git. And that's my point: If you want to
learn git, you have to search for a tutorial which fits for you and only you. It
could absolutely be that you love the tutorial I used when I learned git, but it
could also be that you hate it.
What I would encourage you to do is searching 3 to 5 different beginner
tutorials and always reading the first two paragraphs or something. Then decide
which one you want to use.
There is no “best” tutorial for learning git. There are only ones that fit your
needs and other whichs don't. For example, for my classmate, I personally would
search some more technical examples which also covers the “how does it work
internally” part, at least at the surface. But maybe she would use a really
basic tutorial which only tells her how to get shit done... who knows?
And with this statement, I'm coming to the next point: When it comes to git, and
you want to collaborate with others (or you want to write a piece of software
and share it with others afterwards, which enables them to collaborate with
you), there is one thing: Know. Your. Shit.
You really should know how you do certain things right, so you don't break
the overall workflow of the project you contribute to. That sounds more
complicated than it actually is. You basically have to know how to fix history
if it got messed up (in manner of a lot of “Fixup abc” commits), how to update
your local copy and rebase your work onto the changes of the upstream
repository, how to do pull requests right and how to write a clean history.
Again, that sounds more complicated than it is.
If you know how to do the basic things right, you will have a less hard time
using git in collaboration with others.
For example, I have another classmate. He uses git for ... dunno... maybe 4
weeks or so. He still did not get the difference between his local copy, his
remote copy and the upstream repository. This leads him to confusion every
single time he wants to contribute. And he fucks up the history pretty often,
resulting in pull requests the maintainer of the main repository (me, actually),
rejects because there is stuff in it which does not belong there. For example
merge commits where he merged the upstream master. Or the pull requests is the
hell of an outdated one and I cannot merge it because of merge conflicts.
He doesn't know his shit, and it slows down the workflow of the whole project
sometimes (actually, just mine, but whenever I have to struggle around with his
damaged pull requests, I cannot do the actual work with the other pull
requests).
So, again: Know. Your. Shit.
And every good git tutorial should teach you these things. If it doesn't, it is
not a good one. So here goes my next advice:
If you do not understand in a git tutorial after reading it several times,
switch to another one and restart. Yes, restart. Start reading the other
tutorial right from the beginning. Why? Because:
The tutorial might has stated important things you're skipping when you
switch directly to the point you stopped in the old tutorial with.
Re-reading things you already know memorizes it.
It is like learning a song on the piano: The more often you do it, the more you
know it. But if you always play it from the start to the end, you know the start
really good (as you play this one more often if you restart after failing), and
the end not that good. That's why some people start at the end when learning a
song on the piano: The play the last line, then the 2nd last and the last, and
so on. When they made it to the very beginning, the have to re-learn the
beginning several times and afterwards, they can play the song just perfectly.
That's a really basic trick, but very effective. Sadly, this does not work when
learning something from a tutorial, because a tutorial has to be done
sequentially. But I guess you get the point.
So, let me make my points up:
Know. Your. Shit.
Learning with tutorials is good, but they have to fit your taste and need. If
you do not understand certain things after re-reading them several times, switch
to another tutorial
Extra point: Take your time. Rom was not build in one day, and
neither you have to get from beginner level to expert level in git just in one
day.
Another extra point: Tutorials are good, but sometimes it is better to
actually talk to someone (I know... yuck!)
Finally: When working on a collaborating team after you learned the basics:
Ask people about how they did things and about their tricks (short: go on
learning. Every. Single. Day).
That's it. Cheer up, you can make it!
tags: #git #tutorial