This is a writeup of a talk I gave in December for my previous employer. It's long so I'm publishing it in several parts:
- Part I (you are here):
- Part II: (coming later)
- More coming later still:
- Branches are fictitious
- Committing partial changes
- Push and fetch; tracking branches
- Aliases and custom commands
How to approach Git; general strategy
Git has an elegant and powerful underlying model based on a few simple concepts:
- Commits are immutable snapshots of the repository
- Branches are named sequences of commits
- Every object has a unique ID, derived from its content
Built atop this elegant system is a flaming trash pile.
The command set wasn't always well thought out, and then over the years it grew by accretion, with new stuff piled on top of old stuff that couldn't be changed because Backward Compatibility. The commands are non-orthogonal and when two commands perform the same task they often have inconsistent options or are described with different terminology. Even when the individual commands don't conflict with one another, they are often badly-designed and confusing. The documentation is often very poorly written.
What this means
With a lot of software, you can opt to use it at a surface level without understanding it at a deeper level:
“I don't need to
know how it works.
I just want to know which commands to run.”
This is often an effective strategy, but
with Git, this does not work.
You can't “just know which commands to run” because the commands do not make sense!
To work effectively with Git, you must have a model of what the repository is like, so that you can formulate questions like “is the repo on this state or that state?” and “the repo is in this state, how do I get it into that state?”. At that point you look around for a command that answers your question, and there are probably several ways to do what you want.
But if you try to understand the commands without the model, you will suffer, because the commands do not make sense.
Just a few examples:
git-resetdoes up to three different things, depending on flags
The opposite of
If you try to understand the commands without a clear idea of the model, you'll be perpetually confused about what is happening and why, and you won't know what questions to ask to find out what is going on.
When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively.
The magic key that rescued me was
Git From the Bottom Up explains the model. I read it. After that I wept no more. I understood what was going on. I knew how to try things out and how to interpret what I saw. Even when I got a surprise, I had a model to fit it into.
That's the best advice I have. Read Wiegley's explanation. Set aside time to go over it carefully and try out his examples. It fixed me.
If I were going to tell every programmer just one thing about Git, that would be it.
The rest of this series is all downhill from here.
But if I were going to tell everyone just one more thing, it would be:
It is very hard to
permanently lose work.
If something seems to have gone wrong, don't panic.
Remain calm and ask an expert.