From c94a2402195e709672b29990fc9d1473d2ca5a5c Mon Sep 17 00:00:00 2001 From: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com> Date: Sun, 9 Aug 2020 12:12:38 +0200 Subject: [PATCH 1/2] Rewrite rebase vs merge analogy Closes #351 --- book/03-git-branching/sections/rebasing.asc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 6e47214b1..ad10506a6 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -228,8 +228,10 @@ 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? +Remember, you are likely to need this history yourself, when fixing a bug, or figuring out why you made a particular change. +People in this camp clean up their commit(s) and commit messages, before the work is merged/rebased 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. From f00c42e8d18d35282ffe8d6403610700f34c1eb7 Mon Sep 17 00:00:00 2001 From: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com> Date: Sun, 16 Aug 2020 08:01:20 +0200 Subject: [PATCH 2/2] Rewrite into something nicer Co-authored-by: Ben Straub --- book/03-git-branching/sections/rebasing.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index ad10506a6..8856f7d05 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -229,12 +229,12 @@ 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, so why show your messy work? -Remember, you are likely to need this history yourself, when fixing a bug, or figuring out why you made a particular change. -People in this camp clean up their commit(s) and commit messages, before the work is merged/rebased into the mainline branch. +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. \ No newline at end of file +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.