My Humble Beginnings
When I first started using Git, I was really paranoid about losing code. The only VCS I'd used before that was Subversion, where branching is this arcane thing that causes all kinds of trouble. So I didn't have a lot of practice with merging -- let alone rebasing, which everyone said was really dangerous. (Remember LSD and chainsaws?)
So, before I tried something I was a little uncertain about, I would back up the entire directory.
$ cd ..
$ cp -r work backup_work
$ cd work
Then I'd do the merge, or rebase, or whatever it was that I thought was tricky. If it looked like it worked, I'd continue on; if not, I'd delete the working directory, rename the old one, and try something else.
I don't have records, but I'm pretty sure I did this for at least my first year of working with Git.
When I finally realized that references make commits reachable, I (a) felt very dumb for all those times I backed up the repository, and (b) developed a much faster strategy for getting my repository back to a known state.
- About This Site
- Git Makes More Sense When You Understand X
- Example 1: Kent Beck
- Example 2: Git for Ages 4 and Up
- Example 3: Homeomorphic Endofunctors
- Example 4: LSD and Chainsaws
- The Internet Talks Back!
- Graph Theory
- Seven Bridges of Königsberg
- Places To Go, and Ways to Get There
- Nodes and Edges
- Attaching Labels to Nodes
- Attaching Labels to Edges
- Directed Versus Undirected Graphs
- Graphs and Git
- Visualizing Your Git Repository
- The Reference Reference
- Making Sense of the Display
- Garbage Collection
- Experimenting With Git
- References Make Commits Reachable
- My Humble Beginnings ←HEAD
- Branches as Savepoints
- Use Your Targeting Computer, Luke
- Testing Out Merges
- Rebase From the Ground Up
- Cherry-Picking Explained
- Using 'git cherry-pick' to Simulate 'git rebase'
- A Helpful Mnemonic for 'git rebase' Arguments
- The End