
Show HN: I wrote about book about rebasing in Git - PascalPrecht
https://rebase-book.com
======
PascalPrecht
Hey everyone,

over the past two months I made it myself a challenge to write an ebook about
rebasing in git and today I'm happy to launch a first version of it!

I see a lot of people struggling with having a fundamental understanding of
how git works. Rebasing in Git is probably one of the most powerful features
of the tool that can make everyone extremely productive when it comes to
version control and working with peers on projects.

I've documented my progress at IndieHackers here:
[https://www.indiehackers.com/product/rebase-
book](https://www.indiehackers.com/product/rebase-book)

Will also write a post-mortem about how I've authored and published the book
in just two months.

Feel free to follow me on twitter for updates:
[https://twitter.com/PascalPrecht](https://twitter.com/PascalPrecht)

------
anton_gogolev
Not to undermine author’s efforts, but I feel we as an industry took a wrong
turn somewhere. An entire book on what essentially is a single Git command is
just insane.

~~~
ollerac
You could be saying one of two things here:

1\. "The average dev these days is so terribly uninformed, they're willing to
buy an entire book to explain what, to me, is a simple concept. I feel like
devs these days aren't as good."

Or:

2\. "Our tools these days are so complex that the average dev needs an entire
book just to understand a single command. I feel like our tools are too
complicated."

You might want to work on being clearer about what you mean in the future, or
else risk coming off as rude. I thought you meant #1 when I first read your
statement, but, after rereading your statement, I'll give you the benefit of
the doubt and assume you meant #2.

To respond to point #2: imagine explaining a complex bash command to someone.
If they mostly used bash to change directories and list files, you might need
to explain pipes, buffers, and the unix philosophy before they'd really
understand it. As someone in this thread mentioned, they mostly use git for
push/pull/merge and that's not uncommon. Most devs need more background about
how git works behind the scenes in order to really get the benefits of
something like git rebase. I happen to be one of those devs and I'm glad a
book like this exists.

~~~
PascalPrecht
Hey, Pascal here, the author.

I understand this reaction. And just like you've pointed out, it's actually
not a whole" book about a single command.

In order to get a good understanding of rebasing, I believe it's good to have
a solid foundation of how git works, which is pretty much what the first half
of the book covers.

I could've left that out and only talk about rebasing without going into all
the other topics but then, for someone who isn't experienced with the
internals of git will have a hard time following what's going on.

------
dirtydroog
The thing is, git is a tool, it should be pretty easy to use. If someone has
to write an entire book about rebasing then, in my opinion, there's something
wrong.

I just push/pull/merge. I've never had any issues, a monkey could do it and
would have to go out of their way to screw it all up.

"Noob! You don't understand how git works"... maybe true. I understand how
source control should work. I have far more important things on my day-to-day
plate then to dig into the internal workings of git. The branching setup
described in the git-flow thing has been around far longer than git.

~~~
darekkay
I agree with Git being a (too) complex tool. However, I do not agree with the
conclusion.

> _I just push /pull/merge. I've never had any issues_

If you're working alone or in a very small team, this may be true. But
personally I am constantly (like monthly) helping my team mates fixing their
Git issues. Last week our build job went rougue and created 400 commits with
60MB of data. We could have ignored it and lived with it for the rest of the
repository's life - instead we just did a reset and rebased open pull
requests. As if nothing ever happened.

And it's not only about _issues_. Knowing more then push/pull/merge makes the
work more efficient. Example: not knowing how to _amend_ changes (or not
knowing that something like this even exists) will lead to useless commits
("Fix typo", "Add missed file"). In a git log, I don't really care. When doing
a git blame (at least weekly), I would have to go through those useless
commits to get to the commit I am looking for. Sure, it does take only a few
minutes, but on the other hand amend is no Git internal black magic either.

I also remember a lot of situations where people "lost" (or maybe actually
_lost_ ) their changes and had to redo them by hand. A one-liner might be
fine, a full day of work is not.

> _I have far more important things on my day-to-day plate then to dig into
> the internal workings of git._

You don't have to know the internal workings. But the fundamental knowledge on
commit level (what is a commit? what is a branch? what does
reset/checkout/rebase actually do?) makes most "advanced" features really
easy. Spending a couple of hours to properly learn the tool I'm using daily
gives a great ROI.

------
machiaweliczny
Related:
[https://learngitbranching.js.org/](https://learngitbranching.js.org/)

------
datene
That's really cool, the hand-drawn charts are super clear. I've never
considered rebasing but I'll give it a go on my next project

~~~
BossingAround
> I've never considered rebasing ...

Sounds like you either don't use GIT a lot, or your team doesn't care about
clean history.

With clean history, you can, for example, automate the generation of release
notes. It's very helpful if you ask me.

~~~
wdfx
IMO the pursuit of, or even a concept of 'clean history' is a fallacy and
waste of time. It is a level of obsession which I think is just not worth it.
Furthermore, a commit log is not the same thing as release notes. More often
than not you need release notes for a product to be constructed in a user
centric manner, describing features or changes which affect them - and that
actually comes from the original requirements lists and not the minute
implementation details.

IMO don't rebase, don't worry about 'clean' history. Obsessing over those is
time consuming and risky. Just do your work and move on. Let your manager/lead
deal with the external world.

~~~
darekkay
> IMO the pursuit of, or even a concept of 'clean history' is a fallacy and
> waste of time. It is a level of obsession which I think is just not worth
> it.

While I do _obsess_ over a git clean history (at least in my personal
projects), I still mostly agree. Doing rebase instead of merge to have a
cleaner history (as in git log) might not be worth it (git log --no-merges
will return a similar image). But there's one feature I use constantly that
relies on not having any useless commits on it: git blame. Whenever I'm asking
myself why a changes was made (at least weekly), I'm looking for the commit
that introduced the change. Things like "fix typo" or "add missing files"
don't help. Hence, I am doing a lot of amends and interactive rebases to
combine changes that belong to each other. It may take 2 more minutes, but it
will make my (and my collegues') life easier in the future.

~~~
WorldMaker
If you follow a PR heavy or PR only methodology heavy on meaningful merges
with good descriptions, `git log --first-parent` can be more useful than `git
log --no-merges`. It's more condensed and focused on high level features
instead of the smaller baby steps that build up the high level. `git blame`
_also_ accepts `--first-parent`.

------
AwesomeFaic
The "Timeless Content" icon isn't loading for me (using Brave). Otherwise
looks great and congrats on the release

~~~
PascalPrecht
That's interesting, cause it's just an emoji, but thanks for letting me know!!

------
dreamcompiler
Title should probably read "...book about rebasing..."

~~~
dang
Added. Thanks!

