Merge branch 'master' into feature/add-section-change-existing-branch-name

Author: ben

book/03-git-branching/sections/rebasing.asc

@@ -228,11 +228,13 @@ So what if there was a messy series of merge commits?
 That's how it happened, and the repository should preserve that for posterity.
 
 The opposing point of view is that the commit history is the *story of how your project was made.*
-You wouldn't publish the first draft of a book, and the manual for how to maintain your software deserves careful editing.
-This is the camp that uses tools like `rebase` and `filter-branch` to tell the story in the way that's best for future readers.
+You wouldn't publish the first draft of a book, so why show your messy work?
+When you're working on a project, you may need a record of all your missteps and dead-end paths, but when it's time to show your work to the world, you may want to tell a more coherent story of how to get from A to B.
+People in this camp use tools like rebase and filter-branch to rewrite their commits before they're merged into the mainline branch.
+They use tools like `rebase` and `filter-branch`, to tell the story in the way that's best for future readers.
 
 Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple.
 Git is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different.
 Now that you know how both of these things work, it's up to you to decide which one is best for your particular situation.
 
-You can get the best of both worlds: rebase local changes before pushing to clean up your work, but never rebase anything that you've pushed somewhere.
+You can get the best of both worlds: rebase local changes before pushing to clean up your work, but never rebase anything that you've pushed somewhere.

book/05-distributed-git/sections/contributing.asc

@@ -60,7 +60,7 @@ Getting in the habit of creating quality commit messages makes using and collabo
 As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation.
 The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior -- this is a good guideline to follow.
 Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug."
-Here is a https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[template originally written by Tim Pope]:
+Here is a template you can follow, which we've lightly adapted from one https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[originally written by Tim Pope]:
 
 [source,text]
 ----
@@ -70,7 +70,7 @@ More detailed explanatory text, if necessary.  Wrap it to about 72
 characters or so.  In some contexts, the first line is treated as the
 subject of an email and the rest of the text as the body.  The blank
 line separating the summary from the body is critical (unless you omit
-the body entirely); tools like rebase can get confused if you run the
+the body entirely); tools like rebase will confuse you if you run the
 two together.
 
 Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
@@ -787,6 +787,11 @@ Result: OK
 
 ==== Summary
 
-This section has covered a number of common workflows for dealing with several very different types of Git projects you're likely to encounter, and introduced a couple of new tools to help you manage this process.
+In this section, we covered multiple workflows, and talked about the differences between working as part of a small team on closed-source projects vs contributing to a big public project.
+You know to check for white-space errors before committing, and can write a great commit message.
+You learned how to format patches, and e-mail them to a developer mailing list.
+Dealing with merges was also covered in the context of the different workflows.
+You are now well prepared to collaborate on any project.
+
 Next, you'll see how to work the other side of the coin: maintaining a Git project.
 You'll learn how to be a benevolent dictator or integration manager.

book/07-git-tools/sections/rewriting-history.asc

@@ -299,6 +299,27 @@ This changes the SHA-1s of the three most recent commits in your list, so make s
 Notice that the last commit (`f7f3f6d`) in the list is unchanged.
 Despite this commit being shown in the script, because it was marked as ``pick'' and was applied prior to any rebase changes, Git leaves the commit unmodified.
 
+==== Deleting a commit
+
+If you want to get rid of a commit, you can delete it using the `rebase -i` script.
+In the list of commits, put the word ``drop'' before the commit you want to delete (or just delete that line from the rebase script):
+
+[source,console]
+----
+pick 461cb2a This commit is OK
+drop 5aecc10 This commit is broken
+----
+
+Because of the way Git builds commit objects, deleting or altering a commit will cause the rewriting of all the commits that follow it.
+The further back in your repo's history you go, the more commits will need to be recreated.
+This can cause lots of merge conflicts if you have many commits later in the sequence that depend on the one you just deleted.
+
+If you get partway through a rebase like this and decide it's not a good idea, you can always stop.
+Type `git rebase --abort`, and your repo will be returned to the state it was in before you started the rebase.
+
+If you finish a rebase and decide it's not what you want, you can use `git reflog` to recover an earlier version of your branch.
+See <<ch10-git-internals#_data_recovery>> for more information on the `reflog` command.
+
 [NOTE]
 ====
 Drew DeVault made a practical hands-on guide with exercises to learn how to use `git rebase`.