Describing Your Problem

There are a lot of ways to undo work in Git, and each method is exactly right some of the time. In order to choose the correct method, you need to know exactly what you want to change—and how it should be different after you are finished. When I was first learning version control, I would often draw a quick sketch of what I was trying to accomplish to ensure I was using the right command for the job. Figure 6-1 shows the three concepts you need to be aware of: the working directory (the files currently visible on your filesystem); the staging area (the index of changes that will be written to the repository after the next commit); and the repository (which stores files and records the changes made to the files over time).

Figure 6-1. The working directory, staging area, and repository each contain different information about your files

Whenever you can separate your problem into the discrete places where Git is storing its information, you have a better chance of choosing the correct command sequence to return your work to the state you want it to be in. Table 6-1 contains a series of scenarios might encounter while working with Git.

Figure 6-2 shows one diagram for the first scenario. Additional answers are available on the Git for Teams website.

Figure 6-2. You want to discard changes you’ve made to a file in your working directory; the incorrect copy of the file is not staged or committed

As you can see in the examples outlined in Table 6-1, some commands have two different outcomes depending on the parameters used. Figure 6-3 contains a flowchart of the scenarios you may find yourself in. Redraw this chart digitally, or on paper. The act of re-creating the chart will reinforce the options you will be forced to deal with in Git, and it will give you a personal reference point, which is often easier to remember than a page in a book.

You may have your own types of changes you need to recover from as well. Create a list of all the problem scenarios you may want to recover from. The better you are able to describe what’s wrong, the more likely you are to find the correct solution. As you work through this chapter, you may choose to expand on the flowchart in Figure 6-3 or create your own diagrams. Please share your work on Twitter by using #gitforteams. I’d love to see what you come up with!

Using Branches for Experimental Work

On a tree, a branch is independent from its sibling branches. Although they may have a common ancestor, you can (typically) saw a branch off a tree without impacting the other branches. In Git, the commits you add to your repository are connected to one or more branches. If you check out a different branch and manipulate the commit objects in that new branch, they are assigned a new identifier, leaving the original commit objects tied to the original branch unchanged. This means it is always safer to do your work in a new private branch, and when you are happy with the results, merge your branch back into the main branch (Figure 6-4).

Figure 6-3. Create a flowchart to help you select the appropriate command

Figure 6-4. Working in a branch protects you from unintended changes; merge your work back into the main branch only when it is correct and complete

Previously we’ve created and deleted branches using the ticket as a starting point. But what if you were working on a ticket, and you weren’t sure which of two approaches you should take? In this case you could create a branch off of your ticket branch, make your experimental changes (Example 6-1), and then merge your experimental branch into your ticket branch (Example 6-2) if you want to save the changes.

$ git checkout -b experimental_idea
  (do work)
$ git add --all
$ git commit

You may have one or more commits in your experimental branch. When you merge the two branches, you can optionally combine all of those commits into a single one at the time of the merge with the parameter --squash. If you use this parameter, you will still need to run the command commit separately to save the changes from the other branch. By merging the branch in this way, you will be unable to unmerge the branch later. As such, it’s appropriate to use --squash only when merging branches you wish had never been separate to begin with.

$ git checkout master
$ git merge experimental_idea --squash

Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested

$ git commit

After merging your experimental branch, you can delete it (Example 6-3).

$ git branch --delete experimental_idea

If you want to discard your experimental ideas, complete the preceding steps, but omit the step where you merge your work into your main ticket branch. To delete an unmerged branch, you will need to use the parameter -D instead of --delete.

Subsequent sections of this chapter cover removing commits you made in a branch before you realized they were just experiments.

Begin Rebasing

Ensure your local copy of the parent branch is up to date with the most recent commits available from the main project repository:

$ git checkout master
$ git pull --rebase=preserve remote_nickname master

Change into the branch that is currently out of date from the main project, but which contains new work that hasn’t been introduced yet:

$ git checkout feature

Begin the rebasing process:

$ git rebase master

If there are no conflicts, Git will skip merrily through the process and spit you out the other end with no additional action required from you. See? Rebasing is easy! You should try it! However, sometimes there are conflicts…

Mid-Rebase Conflict from a Deleted File

A conflict in the rebasing process occurs when the changes you have made occur on the same line as the changes which are stored in one of the new commits on the parent branch. As a simple content tracker, Git doesn’t feel qualified to know whether our changes should be kept, or theirs. Instead of making guesses, Git stops and asks for your help. I think that’s actually quite considerate that Git perceives me to be more of an expert on the content than it is! Unfortunately the process isn’t called “asking you, the expert, for help”; it’s called “resolving conflict while in a detached HEAD state.” This is very scary language for process that is actually quite respectful.

To resolve a conflict you will need to put on your content expert hat, and help Git make some decisions about what to do next.

This section covers an example of a mid-rebase conflict. The file ch10.asciidoc has been deleted in the source branch, master, but I’ve been making updates to it in feature. This is a problem Git doesn’t know how to resolve. Do I want to keep the file? Should it be deleted? Git has put me into a detached HEAD state so that I can explain to Git how I want to proceed:

First, rewinding head to replay your work on top of it...
Applying: CH10: Stub file added with notes copied from video recording lessons.
Using index info to reconstruct a base tree...
A	ch10.asciidoc
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): ch10.asciidoc deleted in HEAD and modified in CH10:
Stub file added with notes copied from video recording lessons.. Version CH10:
Stub file added with notes copied from video recording lessons. of ch10.asciidoc
left in tree.
Failed to merge in the changes.
Patch failed at 0001 CH10: Stub file added with notes copied from video
recording lessons.
The copy of the patch that failed is found in:
   /Users/emmajane/Git/1234000002182/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

The relevant piece of information from this output is:

When you have resolved this problem, run "git rebase --continue".

This tells me that I need to:

1. Resolve the merge conflict.

2. Once I think the merge conflict is resolved, run the command:

   git rebase --continue

   I accomplish step 1 by opening the file in question in my designated file comparison tool:

$ git mergetool ch10.asciidoc

There are no merge conflict markers displayed in the file, so I quit the merge tool and proceed to the next step Git had identified:

$ git rebase --continue

The following message is returned from Git:

ch10.asciidoc: needs merge
You must edit all merge conflicts and then
mark them as resolved using git add

That’s not very helpful! I just looked at that file and there were no merge conflicts. I’ll ask Git what the problem is using the command status:

$ git status

The output from Git is as follows:

rebase in progress; onto 6ef4edb
You are currently rebasing branch 'ch10' on '6ef4edb'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add/rm <file>..." as appropriate to mark resolution)

	deleted by us:   ch10.asciidoc

no changes added to commit (use "git add" and/or "git commit -a")

Aha! There are two clues here for me. The text: Unmerged paths and then a little later on the text: deleted by us: ch10.asciidoc. Well, I don’t want the file to be deleted. This is useful because Git has told me deleted by us and I know I don’t want to delete the file; therefore I need to unstage Git’s change. Unstaging a change is effectively saying to Git, “That thing you were planning to do? Don’t do it. In fact, forget you were even thinking about doing anything with that file. Reset your HEAD, Git.”

Git tells me how to prevent this change from happening with the following text:

(use "git reset HEAD <file>..." to unstage)

Using this message as a guide, I run the following command:

$ git reset HEAD ch10.asciidoc

Now, what this command is actually doing is clearing out the staging area, and moving the pointer back to the most recent known commit. Because I am knee-deep in a rebase, and in a detached HEAD state as opposed to in a branch, reset clears away the staging area and puts me in the most recent state from the rebasing process. In my case, this leaves me with the older version of the file, which is fine. As I proceed through the rebase, I will replace the contents of the file with the latest version from the branch feature. If I wanted to preserve their deletion of the file, I would skip this step and proceed with the instructions, adding the file to the staging area as described later.

With my chapter file replaced, let’s see what clues Git is giving me on how I should proceed:

$ git status

The output from Git is as follows:

rebase in progress; onto 6ef4edb
You are currently rebasing branch 'ch10' on '6ef4edb'.
  (all conflicts fixed: run "git rebase --continue")

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	ch10.asciidoc

nothing added to commit but untracked files present (use "git add" to track)

So I’ve still got the file (great!), but Git is still confused about what to do, because as far as it’s concerned, that file should have been deleted. I need to explicitly add the file back into the repository, which Git tells me to do by giving me the message:

Untracked files: (use "git add <file>..." to include in what will be
committed) ch10.asciidoc

The formatting is awkward if there is only one affected file but in the case of a longer list of files, the formatting is lovely.

Per Git’s request, I will now add the file ch10.asciidoc to the staging area:

$ git add ch10.asciidoc

Now at this point, I know that the command add is just the beginning of a process, and that I’m going to need to commit the file as well, but this is rebasing and the rules are different. I’m going to ask Git what to do next by checking the output of the command status again:

$ git status

The output from Git is as follows:

rebase in progress; onto 6ef4edb
You are currently rebasing branch 'ch10' on '6ef4edb'.
  (all conflicts fixed: run "git rebase --continue")

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   ch10.asciidoc

Okay, it’s saying there are changes to be committed (yup, already knew that), but it doesn’t tell me to commit them! Instead it tells me to continue with the rebasing with the message:

all conflicts fixed: run "git rebase --continue"

I proceed with this command even though add is normally paired with commit to save changes:

$ git rebase --continue

Mid-Rebase Conflict from a Single File Merge Conflict

After restarting the rebasing process, Git has run into another conflict as it replays the commits. The output is as follows:

Applying: CH10: Stub file added with notes copied from video recording lessons.
Applying: TOC: Adding Chapter 10 to the book build.
Using index info to reconstruct a base tree...
M	book.asciidoc
Falling back to patching base and 3-way merge...
Auto-merging book.asciidoc
CONFLICT (content): Merge conflict in book.asciidoc
Recorded preimage for 'book.asciidoc'
Failed to merge in the changes.
Patch failed at 0002 TOC: Adding Chapter 10 to the book build.
The copy of the patch that failed is found in:
   /Users/emmajane/Git/1234000002182/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Another conflict. You’re being high maintenance, Git! No wonder people complain about rebasing! Okay, okay, at least it’s a different file this time (CONFLICT (content): Merge conflict in book.asciidoc). I take a closer look at the output of the command status again to see if Git gives me additional clues:

$ git status

The output from Git is as follows:

rebase in progress; onto 6ef4edb
You are currently rebasing branch 'ch10' on '6ef4edb'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

	both modified:   book.asciidoc

no changes added to commit (use "git add" and/or "git commit -a")

Long sigh. Alright, Git. Let’s see what the conflict is in this file:

$ git mergetool book.asciidoc

Opening up the file in my favorite merge tool, I see there is indeed a merge conflict in this file. The merge conflict markers are displayed as three columns. One column for each of the two branches being merged, and one column displaying how the merge conflict should be resolved. I choose the hunk of text I want to keep, which resolves the conflict. I save the file, close the merge tool, and ask Git if it’s happy by using the command status, again:

$ git status

The output from Git is as follows:

rebase in progress; onto 6ef4edb
You are currently rebasing branch 'ch10' on '6ef4edb'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

	both modified:   book.asciidoc

no changes added to commit (use "git add" and/or "git commit -a")

The message is a little misleading because I have fixed the conflicts. At this point, I open the file to double check. Nope, no conflicts there. So now I move on to the next group of instructions: unmerged paths: use "git add <file> …" to mark resolution and then both modified: book.asciidoc:

$ git add book.asciidoc

And check the status again:

$ git status

The output from Git is as follows:

rebase in progress; onto 6ef4edb
You are currently rebasing branch 'ch10' on '6ef4edb'.
  (all conflicts fixed: run "git rebase --continue")

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   book.asciidoc

As before, I don’t pair the command add with the command commit. Instead, Git instructs me as follows: all conflicts fixed: run "git rebase --continue", so I proceed with the rebasing process:

$ git rebase --continue

The output from Git is as follows:

Applying: TOC: Adding Chapter 10 to the book build.
Recorded resolution for 'book.asciidoc'.
Applying: CH10: Outline of GitHub topics

The rebasing procedure has been completed. My copy of the branch feature is now up to date with all changes that had been previously committed to the branch master.

There are a few different ways that rebasing can kick up a conflict. Take your time, read the instructions carefully, and if you aren’t getting useful information, try using the command status to see if there’s something more helpful that Git can offer. If you are really in a panic about what’s happening, you can always abort the process with the command git rebase --abort. This will return you the state your branch was in right before you started the rebase.

Amending Commits

If you realize a commit you’ve just made is just missing one little fix, you can amend the commit to include additional files, or update the message that was used for the commit. I use this command frequently to convert my terse one-line commit messages into well-formed summaries of the work I’ve completed.

If you have made any changes to the files in your working directory, you will need to add the files to the staging area before amending your commit (Example 6-7). If you are just updating the commit message, and there are no new, or modified files, you can omit the command add, and jump straight to the command commit.

$ git add --all
$ git commit --amend

Your new changes will be added to the previous commit, and a new ID will be assigned to the revised commit object.

If you want to amend more than just the previous commit, though, you will need to use either reset or rebase.

Combining Commits with Reset

The command reset appears in many different forms during the undo process. In this example, we will use it to mimic the effects of squash in rebasing. The most basic explanation of what reset does is essentially a pointing game. Wherever you point your finger is what Git is going to treat as the current HEAD (or tip) of your branch.

Previously you used the command reset to unstage work before making a commit. This time you are using reset to remove commit objects from your branch’s history. Think of a string of beads. Let’s say the string is 20 beads long. Holding the fourth bead, allow the first three beads to slide off the string. You now have a shorter string of beads as well as three loose beads. The parameters you use when issuing the reset command are part of what determines the fate of those beads.

If you want to discard the content contained in the commit objects you removed, you need to use reset with the mode hard. This mode is enabled by using the parameter --hard. When you use the mode hard, the commit objects will be removed, and the working directory will be updated so that all content stored in those commit objects are also removed. If you do not use --hard when you reset your work, Git keeps the content of the working directory the same, but throws away the commit objects back to the reference point. It will be as if you typed all of the changes from the previous commits into one giant piece of work. It’s now waiting to be added and committed.

Using our previous bead example, let’s say you wanted to reset your string of beads so that the most recent three beads were replaced by a single big bead. You would use the command reset to point the new end for your string to the fourth bead from the end. You would then slide the three beads off the end of the string. (If you used the parameter --hard, these beads would be discarded.) Instead, we’re going to remold these beads, and put them back on the string as a new commit.

Using the command log, identify the most recent commit that you want to keep. This will become the new tip for your branch:

$ git log --oneline

699d8e0 More editing second file
eabb4cc Editing the second file
d955e17 Adding second file
eppb98c Editing the first file
ee3e63c Adding first file

Sticking with the three-bead analogy, the bead that I want to have as the new tip of my necklace is eppb98c. (This is the fourth bead from the end—not entirely intuitive if you are completely focused on removing three beads.) We’re going to put our finger on the bead we want to keep, and slide the rest off of the string:

$ git reset eppb98c

The are now three loose beads rattling around. These beads will appear as untracked changes in our repository. The content of the files will not have changed.

You can view what will be in your new commit by using the command diff:

$ git diff

To combine all of the edits that were made in those three commits into a single commit, use the command add to capture the changes in the staging area:

$ git add --all

Ensure the files are now staged and ready to be saved:

$ git status

Now that the files have been staged, the command diff will no longer show you what you are about to commit to your repository. Instead, you will need to examine the staged version of the changes:

$ git diff --staged

Once you are satisfied with the contents of your new commit, you can go ahead and complete the commit process:

$ git commit -m "Replacing three small beads with this single, giant bead."

The three commits will now be combined into one single commit.

If you are having a hard time with the word reset and having to go one past the commit you are looking for, I encourage you to use relative history instead of commit IDs. For example, if you wanted to compress three commits from your branch into one, you would use the following command:

$ git reset HEAD~3

This version of the command puts your repository into the same state as the previous example, but it’s as if the pointer was using another language. Either approach is fine. Use whichever one makes more sense to you. I personally find if there are more than a handful of commits that I want to reset, using the commit ID is a lot easier than counting backward.

If you’ve been following along with the examples in this section, you should now be able to restore a file that was deleted, and combine several smaller commits into one.

Altering Commits with Interactive Rebasing

Rebasing is one of those topics that has gained a strong positive following—and strong opponents. While I have no technical problems using the command, I openly admit that I don’t like what it does. Rebasing is primarily used to change the way history is recorded, often without changing the content of the files in your working directory. Used incorrectly, this can cause chaos on shared branches as new commit objects with different IDs are used to store work identical work. But my complaints are more to do with the idea that it’s okay to rewrite history to suit your fancy. In the nonsoftware world historical revisionism is wrong.

Complaints aside, rebasing is simply the model Git has decided on and so it fits quite well into many workflows. (I use it when it is appropriate to do so—even for my solo projects where its use is not being enforced by an outside team.) One of the times it is appropriate to use rebasing is when bringing a branch up-to-date (as was discussed in “Rebasing Step by Step” and in Chapter 3); the second is before publishing your work—interactive rebasing allows you to curate the commits into an easier-to-read history. In this section you will learn about the latter of these two methods.

Interactive rebasing can be especially useful if you’ve been committing micro thoughts—leaving you with commits in your history that only capture partial ideas. Interactive rebasing is also useful if you have a number of commits that, due to a peer review or sober second thought, you’ve decided were not the correct approach. Cleaning up your history so there are only good, intentional commits will make it easier to use the command bisect in Chapter 9. To help explain the concept, I created a simple animation showing the basic principles of squashing several small commits into one whole idea.

The first thing you need to do is select a commit in your history that you want to have as your starting point (I often choose one commit older than what I think I’ll need—just in case). Let’s say your branch’s history has the following commits:

d1dc647 Revert "Adding office hours reminder."
50605a1 Correcting joke about horses and baths.
eed5023 Joke: What goes 'ha ha bonk'?
77c00e2 Adding an Easter egg of bad jokes.
0f187d8 Added information about additional people to be thanked.
c546720 Adding office hours reminder.
3184b5d Switching back to BADCamp version of the deck.
bd5c178 Added feedback request; formatting updates to pro-con lists
876e951 Removing feedback request; added Twitter handle.

You have decided that the three commits about jokes should be collapsed into a single commit. Looking to the commit previous to this, you select 0f187d8 as your starting point. You are now ready to begin the rebasing process:

$ git rebase --interactive 0f187d8

pick 77c00e2 Adding an Easter egg of bad jokes.
pick eed5023 Joke: What goes 'ha ha bonk'?
pick 50605a1 Correcting joke about horses and baths.
pick d1dc647 Revert "Adding office hours reminder."

# Rebase 0f187d8..d1dc647 onto 0f187d8
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

The list of commits has been reversed and the oldest commit is now at the top of the list. Edit the list and replace the second and third use of the word squash to pick. In my case, the edited list would appear as follows:

pick 77c00e2 Adding an Easter egg of bad jokes.
squash eed5023 Joke: What goes 'ha ha bonk'?
squash 50605a1 Correcting joke about horses and baths.
pick d1dc647 Revert "Adding office hours reminder."

Save and quit your editor to proceed. A new window commit message editor will open. You will now need to craft a new commit message that represents all of the commits you are combining. The current messages are provided as a starting point:

# This is a combination of 3 commits.
# The first commit's message is:
Adding an Easter egg of bad jokes.

You should add your bad jokes too.

# This is the 2nd commit message:

Joke: What goes 'ha ha bonk'?

# This is the 3rd commit message:

Correcting joke about horses and baths.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Wed Sep 10 06:12:01 2014 -0400
#
# rebase in progress; onto 0f187d8
# You are currently editing a commit while rebasing branch 'practice_rebasing'
on '0f187d8'.
#
# Changes to be committed:
#       new file:   badjokes.md
#

In this case, it is appropriate to update the commit message as follows:

Adding an Easter egg of bad jokes.

- New Joke: What goes 'ha ha bonk'?

You don’t need to remove lines starting with #. I have done this to make it a little easier to read.

When you are happy with the new commit message, save and quit the editor to proceed:

[detached HEAD 1c10178] Adding an Easter egg of bad jokes.
 Date: Wed Sep 10 06:12:01 2014 -0400
 1 file changed, 7 insertions(+)
 create mode 100644 badjokes.md
Successfully rebased and updated refs/heads/practice_rebasing.

The rebasing procedure is now complete. Your revised log will appear as follows:

$ git log --oneline

ef4409f Revert "Adding office hours reminder."
1c10178 Adding an Easter egg of bad jokes.
0f187d8 Added information about additional people to be thanked.
c546720 Adding office hours reminder.
3184b5d Switching back to BADCamp version of the deck.

In the second example, we are going to separate changes that were made in a single commit so they are available as two commits instead. This would be useful if you added made several changes to a single file and commited all of those changes as a single commit but they should have have actually been saved as two separate commits.

To separate a commit into several, begin the same way as you did before. This time when presented with the list of options, change pick to edit for one of the commits. When you save and close the editor this time, you will be presented with the option to amend your commit (you know how to do this! yay!), and then proceed with the rebase process:

Stopped at 0f187d831260b8e93d37bad11be1f41aaeca835e... Added information
about additional people to be thanked.
You can amend the commit now, with

	git commit --amend

Once you are satisfied with your changes, run

	git rebase --continue

At this point you are in a detached HEAD state (you’ve been here before! it’s okay!), but the files are all committed. You need to reset the working directory so that it has uncommitted files that you can work with. Do you remember the command we used previously to accomplish this? It’s reset! Instead of selecting a specific commit, it’s okay to use the shorthand for “one commit ago,” which is HEAD~1:

$ git reset HEAD~1

Unstaged changes after reset:
M	README.md

Now you have an uncommitted file in your working directory that needs to be added before you can continue the rebasing.

At this point, you can stage your files interactively by adding the parameter --patch when you add your files. This allows you to separate changes saved into one file into two (or more) commits. You do this by adding one hunk of the change to the staging area, committing the change, and then adding a new hunk to the staging area:

$ git add --patch README.md

You will be asked if you want to stage each of the hunks in the file:

diff --git a/README.md b/README.md
index 291915b..2eceb48 100644
--- a/README.md
+++ b/README.md
@@ -49,3 +49,5 @@ Emma is grateful for the support she received while employed at
 Drupalize.Me (Lullabot) for the development of this material.
 The first version of the reveal.js slides for this work were posted at
 [workflow-git-workshop](https://github.com/DrupalizeMe/workflow-git-workshop).
+
+Emma is also grateful to you for watching her git tutorials!
Stage this hunk [y,n,q,a,d,/,e,?]?

If you want to include the hunk, choose y; otherwise, choose n. If it’s a big hunk and you want to only include some of it, choose s (this option isn’t available if the hunk is too small). Proceed through each of the changes in the file and select the appropriate option. When you get to the end of the list of changes, you will be returned to the prompt. Use the command git status, and assuming there was more than one hunk to change, you will see your file is ready to be committed and not staged for commit:

$ git status

rebase in progress; onto bd5c178
You are currently splitting a commit while rebasing branch 'practice_rebasing'
on 'bd5c178'.
  (Once your working directory is clean, run "git rebase --continue")

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   README.md

Proceed by committing your staged changes:

$ git commit

If the remainder of the changes can all be included in the same commit, you can omit the parameter --patch and add and commit the file to the repository:

$ git add README.md
$ git commit

With all of your changes committed, you are ready to proceed with the rebase. It seems like there aren’t any hints, but if you check the status, Git will remind you you are not done yet:

$ git status

rebase in progress; onto bd5c178
You are currently editing a commit while rebasing branch 'practice_rebasing'
on 'bd5c178'.
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working directory clean

To complete the rebase, follow the command as Git has described in the status message:

$ git rebase --continue

Successfully rebased and updated refs/heads/practice_rebasing.

Phew! You did it! That was a lot of steps, but they were all concepts you have previously tried; this time they were chained together. Well done, you.

If you have followed each of the examples in this section, you should now be able to amend commits, and alter the history of a branch using interactive rebasing.

Unmerging a Branch

Mistakes can happen when you are merging branches. Maybe you had the wrong branch checked out when you performed the merge; or maybe you were supposed to use the --no-ff parameter when merging, but you forgot. So long as you haven’t published the branch, it can be quite easy to “unmerge” your branches.

Ideally, you will notice you have incorrectly merged a branch immediately after doing it. This is the easiest scenario to reverse. Git knows some of its commands are more dangerous than others, so it stores a pointer to the most recent commit right before it performs the dangerous maneuver. Git considers a merge to be dangerous, and so you can easily undo a merge right after it occurs by running reset, and pointing the tip of your branch back to the commit right before the merge took place:

$ git reset --merge ORIG_HEAD

If you did not notice your mistake right away, you will need to ask yourself a few more questions before proceeding. Figure 6-6 summarizes the considerations you will need to make in order to select the correct commands to unmerge your work.

You will need to think carefully about what work you may want to retain, and what work can be thrown out, before proceeding. If you have deleted the branch you are removing, you may wish to create a backup copy of the commits in a separate branch. This will save you from having to dig through the reflog to find the lost commits.

Let’s say the branch you are working on is named master, and you want to create a backup branch named preservation_branch:

$ git checkout master

$ git checkout -b preservation_branch

Figure 6-6. Before unmerging your branch, consider what may happen to the lost commits

You now have a branch with the good commits and the bad commits, and you can proceed with removing the bad commits. This assumes there are no additional commits you want to save on the branch that needs cleaning:

$ git checkout master
$ git reset --merge ORIG_HEAD

If you do want to save some of the commits, you can now cherry-pick them back from the backup branch you created.

$ git cherry-pick commit_to_restore

The method of using ORIG_HEAD as a reference point will only work if you notice right away that you need to unmerge the bad branch. If you have been working on other things, it’s possible that Git will have already established a new ORIG_HEAD. In this case, you will need to select the specific commit ID you want to return to:

$ git reset last_correct_commit

As Figure 6-6 shows, there are a few different scenarios for unmerging branches. Take your time and remember, the reflog keeps track of everything, so if something disappears, you can always go back and check out a specific commit to center yourself and figure out what to do without losing any of your work.

Reverting a Previous Commit

If there was a commit in the past that was incorrect, it is possible to apply a new commit that is the exact opposite of what you had previously using the command revert. If you are into physics, revert is kind of like noise-canceling headphones. The command applies the exact opposite sound as the background noise, and the net effect to your ears is a silent nothingness.

When you use the command revert, you will notice that your history is not altered. Commits are not removed; rather, a new commit is applied to the tip of your branch. For example, if the commit you are reverting applied three new lines, and removed one line, the revert will remove the three new lines and add back the deleted line.

For example, you have the following history for your branch:

50605a1 Correcting joke about horses and baths.
eed5023 Joke: What goes 'ha ha bonk'?
77c00e2 Adding an Easter egg of bad jokes.
0f187d8 Added information about additional people to be thanked.
c546720 Adding office hours reminder.
3184b5d Switching back to BADCamp version of the deck.
bd5c178 Added feedback request; formatting updates to pro-con lists

You decide that you want to remove the commit made about the reminder for the office hours, because that message was only relevant for that particular point in time. This message was added at c546720:

$ git revert c546720

The commit message editor will open. A default message is provided, so you can save and quit to proceed:

[master d1dc647] Revert "Adding office hours reminder."
 1 file changed, 2 deletions(-)

Your logged history now includes a new commit to undo the changes that were added in c546720:

d1dc647 Revert "Adding office hours reminder."
50605a1 Correcting joke about horses and baths.
eed5023 Joke: What goes 'ha ha bonk'?
77c00e2 Adding an Easter egg of bad jokes.
0f187d8 Added information about additional people to be thanked.
c546720 Adding office hours reminder.
3184b5d Switching back to BADCamp version of the deck.

Repeat for each commit that you want to revert.

If you have followed along with each of the examples in this section, you should now be able to reverse the changes that were implemented in a previous commit.

Unmerging a Shared Branch

Previously in this chapter you learned how unmerge two branches using the command reset. This command deletes commits from a branch’s history. As a result, Git will treat them as new commits if it encounters them again. This happens if people merge their (now out of date) branch into the main repository.

To know which commands to use, you will first need to determine what kind of merge it is. Figure 6-7 compares a fast-forward merge and a true merge. A fast-forward merge is aligned with the commits from the branch it was merged into; a true merge, however, is displayed as a hump on the graph and includes a commit where the merge was performed.

Using the command log, look for the point where the incorrect branch was merged in (Example 6-8). If there is a merge commit, you’re in luck! If there is no merge commit, you are going to have to do a lot more work to get the branch unmerged.

Figure 6-7. When graphed, a fast-forward merge loses the visual of a branch; a true merge maintains it.

$ git log --oneline --graph

*   4f2eaa4 Merge branch 'ch07' into drafts
|
| * c10fbdd CH07: snapshot after editing draft in LibreOffice
| * 9716e7b CH07: snapshot before LibreOffice editing
| * 8373ad7 App01: moving version check to the appendix from CH07
| * d602e51 CH7: Stub file added with notes copied from video recording lessons.
* | 1ae7de0 CH08: Incorrect heading formatting was creating new chapter
* | 7907650 CH08: Draft chapter. Based on ALA article.
* | ad6c422 CH8: Stub file added with notes copied from video recording lessons.

You may also want to look at a single commit to confirm if it is a true merge using the command show. This will list SHA1 for the branches that were merged:

$ git show 90249389

commit 902493896b794d7bc6b19a1130240302efb1757f
Merge: 54a4fdf c077a62
Author: Joe Shindelar <[email protected]>
Date:   Mon Jan 26 18:30:55 2015 -0700

    Merge branch 'dev' into qa

Thanks, Joe, for this tip!

Once you know if there is a merge commit present, you can choose the appropriate set of commands. Figure 6-8 summarizes these options as a flowchart.

If the branch was merged using a true merge, and not a fast-forward merge, the undo process is as follows: use the command revert to reverse the effects of the merge commit (Example 6-9). This command takes one additional parameter, --mainline. This parameter tells Git which of the branches it should keep while undoing the merge. Take a look at your graphed log and count the lanes from left to right. The first lane is 1. You almost always want to keep the leftmost lane, and so the number to use is almost always 1.

$ git checkout branch_to_clean_up
$ git log --graph --oneline
$ git revert --mainline 1 4f2eaa4

The commit message editor will open. A default commit message is provided indicating a revert is being performed, and including the commit message from the commit it is reversing (Example 6-10). I generally leave this message in place due to sheer laziness; however, the upside is that it is quite easy to search through my recorded history and find any commits where I’ve reverted a merge.

Figure 6-8. Depending on how your branch was merged, you will use different commands to unmerge the shared branch

Revert "Merge branch 'video-lessons' into integration_test"

This reverts commit 0075f7eda67326f174623eca9ec09fd54d7f4b74, reversing
changes made to 0f187d831260b8e93d37bad11be1f41aaeca835e.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 23 and 2 different commits each, respectively.
#   (use "git pull" to merge the remote branch into yours)
#
# Changes to be committed:
#       deleted:    lessons/01-intro/README.md
#       deleted:    lessons/02-getting-started/README.md
#       deleted:    lessons/03-clone-remote/README.md
#       deleted:    lessons/04-config/README.md
(etc)
#

Occasionally you will run into conflicts when running a revert. No reason to panic. Simply treat it as any other merge conflict and follow Git’s on-screen instructions:

$ git revert --mainline 1 a1173fd

error: could not revert a1173fd... Merge branch 'unmerging'
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Resolved 'README.md' using previous resolution.

Something went wrong—check the status message to see which files need reviewing:

$ git status

On branch master
Your branch and 'origin/master' have diverged,
and have 20 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
You are currently reverting commit a1173fd.
  (fix conflicts and run "git revert --continue")
  (use "git revert --abort" to cancel the revert operation)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	deleted:    badjokes.md
	modified:   slides/slides/session-oscon.html

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

	both modified:   README.md

The messages about the repository being out of sync with origin is unrelated to this issue. Skip that, and keep reading. The first useful bit of information starts at: You are currently reverting. You are given the options on how to proceed, and on how to abort the process. Don’t give up! Keep reading. The next bit looks like a regular ol’ dirty working directory with some files that are staged, and some that aren’t. If you were just making edits to your files, you would know how to deal with this. First you add your changes to the staging area, and then you commit them:

$ git add README.md
$ git commit -m "Reversing the merge commit a1173fd."

[master 291dabe] Reversing the merge commit a1173fd.
 2 files changed, 2 insertions(+), 7 deletions(-)
 delete mode 100644 badjokes.md

If there is no merge commit, you will need to deal with each of the commits you want to undo individually. This is going to be especially frustrating because a fast-forward merge does not have any visual clues in the graphed log about which commits were in the offending branch. (After the first time unpicking an incorrect merge, you’ll begin to see the logic in using a --no-ff strategy when merging branches.)

The first thing you need to do is get a sense of where the bad commits are. If you are not entirely sure how things went wrong, you can get a list of all the branches a commit is contained within by using the command branch with the parameter --contains:

$ git branch --contains commit

Assuming the merged-in branch hasn’t been deleted, you should be able to use the information to figure out which branch you are trying to unmerge, and what commits were applied to that branch that you might want to remove. Remember, though, the commits are going to be in both branches, so you won’t be able to run a comparison to find which commits are different. This step isn’t necessary if you already know which commits you are targeting.

If the commits you need to revert are sequential, you’re in luck! The command revert can accept a single commit, or a series of commits. Remember, though, that a revert is going to make a new commit for each commit it is reversing. This could get very noisy in your commit history, so instead of reversing each commit individually, you can group them into a single reversal by opting to save your commit message to the very end:

$ git revert --no-commit last_commit_to_keep..newest_commit_to_reject

After running this command you will end up with a dirty working directory with all of the files reverted back. Review the changes. Then, complete the revert process:

$ git revert --continue

Review the commit message and make any necessary updates to improve the clarity of the message. By default the message will be “Revert” followed by the quoted text of what was in the newest of the commits you are reversing. Often this will be sufficient, but you may want to be more descriptive if the original message was subpar.

If the commits are not sequential, you will need to revert the offending commits one at a time. Send me a tweet at @emmajanehw and I will commiserate and cheerlead.

$ git revert commit

Unmerging a merged branch is not something Git is designed to do unless a very specific workflow has been followed. Your team may never need to unmerge a branch. I have definitely had the occasional bad merge on a personal project where I was a solo developer and opted to swear a bit, and then shrug and move on. Sometimes history doesn’t really matter all that much; sometimes it does. With experience and hindsight, you know for sure which commands you should have been using.