Rebasing Branches - Git Recipes - page 241

patches to the master branch. However, because the master branch should remain
unchanged in the resulting repository, we will use detached HEAD state.
This recipe gives you more detailed, practical knowledge about detached HEAD
state. I warned you to avoid it so you may ask why introduce it in git at all. The reason
behind a detached HEAD state is that some commands, such as rebase, change the
graph of revisions. To preserve the original branches, it is necessary to perform these
operations in a detached HEAD state. If something goes wrong, you can easily return
to the state before the operation because the original branches are not changed.
Okay, right now we need to enter a detached HEAD state in which HEAD points to
the same revision as the master branch. How to produce the SHA-1 name of the revi-
sion pointed to by the master branch? You can do this using the $ git rev-
parse command:
$ git rev-parse master
The above command converts a symbolic reference, such as HEAD , HEAD ∼ , fea-
ture , info^2 , into a SHA-1 name. Using a back-tick operator to pass the result of
the $ git rev-parse as a parameter to checkout you will enter the desired de-
tached HEAD state. The complete command is shown in Listing 7-2 . Your repository
now looks like Figure 7-4 .
Listing 7-2. Using rev-parse to enter a deteched HEAD state with HEAD pointing to
master
$ git checkout `git rev-parse master`
Figure 7-4 . The repository from Figure 7-1(a) after the command from Listing 7-2