Two things about git
I'm becoming one of the people at my company that people come to when
they want help with git, so I've been thinking a lot about what to
tell people about it. It's always tempting to dive into the technical
details, but I think the first and most important things to explain
about it are:
Git has a very simple and powerful underlying model. Atop this
model is piled an immense trashheap of confusing, overlapping,
inconsistent commands. If you try to just learn what commands to
run in what order, your life will be miserable, because none of the
commands make sense. Learning the underlying model has a much
better payoff because it is much easier to understand what is
really going on underneath than to try to infer it, Sherlock-Holmes
style, from the top.
One of Git's principal design criteria is that it should be very
difficult to lose work. Everything is kept, even if it can
sometimes be hard to find. If you lose something, don't panic.
There's a good chance that you can find someone who will be able to
hunt it down again. And if you make a mistake, it is almost always
possible to put things back exactly the way they were, and you can
find someone who can show you how to do it.
One exception is changes that haven't been committed. These are not
yet under Git's control, so it can't help you with them. Commit
early and often.
[ Addendum 20160415: I wrote a detailed account of a time I recovered
lost files. ]
[ Addendum 20160505: I don't know why I didn't mention it before, but
if you want to learn Git's underlying model, you should read Git from
the Bottom Up
(which is what worked for me) or Git from the Inside
Out
which is better illustrated. ]
[Other articles in category /prog]
permanent link
|