The Scout Pattern
Here's a quick overview of the steps in this recipe:
- Make sure you're on the right branch and that you have a clean working state.
- Create a new branch (I often name it test_merge) and switch to it.
- Do the merge.
- Switch to your visualizer and predict how its view will change when you refresh it.
- Refresh your visualizer and see whether your prediction was correct.
- Are you happy with the result?
- If YES: Move your real branch forward to where the test_merge branch is.
- If NO: Delete the test_merge branch.
I call this the Scout pattern: you're unsure what the terrain ahead is like, so you send a scouting party ahead to check it out. If they radio back that everything's okay, you'll move ahead and join them. If not, well, it was just a small scouting party and we'll tell the families that they died with honor...
The long version
You're on the master branch and you want the changes from the spiffy_new_feature branch to be incorporated into master. You're not sure if this will be a good idea, so you want to try out the merge, but be able to abort it if things don't go smoothly.
-
Make sure you're on the right branch and that you have a clean working state.
-
Whatever visualizer you're using, figure out how it shows you where your current branch is. Or, at the command line, type
git status
and you should see something like this:# On branch master
nothing to commit (working directory clean)
-
Whatever visualizer you're using, figure out how it shows you where your current branch is. Or, at the command line, type
-
Create a new branch and switch to it.
-
Type
git checkout -b test_merge
. Now, if you typegit status
again, you should see a message that you're on the test_merge branch.
-
Type
-
Do the merge.
-
Type
git merge spiffy_new_feature
. If you're lucky, there won't be any merge conflicts you can't resolve. - If you want to abort the merge at this point, type
git reset --hard
.
-
Type
-
Switch to your visualizer and predict how its view will change when you refresh it.
-
For example:
- After a merge, you should see a new commit.
- The new commit should have a message like "Merge branch 'spiffy_new_feature' into test_merge".
- Your test_merge branch label should have moved to this new commit, while the master and spiffy_new_feature branch labels should still be in the same place.
-
For example:
- Refresh your visualizer and see whether your prediction was correct.
-
Are you happy with the result?
-
If YES: Move the master branch forward to where the test_merge branch is with:
git checkout master
git merge test_merge -
If NO: Drop the test_merge branch with:
git checkout master
git branch -D test_merge
-
If YES: Move the master branch forward to where the test_merge branch is with:
- 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
- Reachability
- Graphs and Git
- Visualizing Your Git Repository
- References
- The Reference Reference
- Making Sense of the Display
- Garbage Collection
- Experimenting With Git
- References Make Commits Reachable
- My Humble Beginnings
- 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