6 ms·

Show HN: I wrote about book about rebasing in Git

69 points by PascalPrecht 7y ago

PascalPrecht 7y ago
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
datene 7y ago
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
- PascalPrecht 7y ago
  You should! If there's one tool I'd recommend everyone to learn it's rebasing. Especially interactive rebasing because it enables things like splitting commits apart, squashing them together and even run automated programs.
  - WorldMaker 7y ago
    The interactive tools exist outside of rebase. You can also split commits apart as you work on them with for example `git add -i` without needing to rebase. I've met junior developers I'd never trust to get rebase right, but interactive add was an important tool to teach them.
    - PascalPrecht 7y ago
      `git add i` is indeed powerful and lets you interactively craft your index before you create a commit. It doesn't enable you to split up an existing commit though.
      - WorldMaker 7y ago
        Interactive hunk splitting the index maps to the mental model of "splitting the work in progress commit". That may be all a developer needs in a "rebase never" workflow.
        PascalPrecht 7y ago
        Certainly can not disagree :) I'm not trying to convince anyone here. By now I've sold over 230 copies and I"m getting really positive feedback. So it must be useful to someone.
- BossingAround 7y ago
  > 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 7y ago
    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.
    - BossingAround 7y ago
      > Obsessing over those is time consuming and risky That's interesting, because to me, it's slopy. If someone doesn't worry about git history, it typically means they don't do pull requests, and that typically, they don't understand know how git works (i.e. how to leverage the features of git). For me, worrying about history literally takes no extra time. I honestly don't understand the argument.
      - wdfx 7y ago
        Pull requests is not the only way to collaborate in a team. git also works with other tools for review and merging can be done by other means.
    - PascalPrecht 7y ago
      Hi, Pascal here. The author. Just to clarify this: The aim of rebasing is not a clean commit history. It enables you to make one in case you've been creating lots of work-in-progress commits with no semantic meaning, which makes it harder to work with it. However, even if you stick to that, it's not like rebasing isn't of value anymore. You might still be interesting in squashing your commits or splitting them up or simply rebase on branch on top of another for various reason. That said, I'd recommend to not advocate not to rebase if it's based on the assumption that it's only useful for clean commit histories.
dreamcompiler 7y ago
Title should probably read "...book about rebasing..."
- dang 7y ago
  Added. Thanks!
AwesomeFaic 7y ago
The "Timeless Content" icon isn't loading for me (using Brave). Otherwise looks great and congrats on the release
- PascalPrecht 7y ago
  That's interesting, cause it's just an emoji, but thanks for letting me know!!
machiaweliczny 7y ago
Related: https://learngitbranching.js.org/ https://learngitbranching.js.org/
dirtydroog 7y ago
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.
- hinkley 7y ago
  I’m torn on this one, because I firmly believe that git is way too complex. But I also don’t think “and entire book for one [technique]” is the litmus test we are looking for. As a profession we are going on 80 years, and we need to start looking at what maturity looks like in other professions instead of trying to define it for ourselves... believing we can out think everyone, even people who have been thinking about things for a couple thousand years. There are whole books describing how to use chisels. There are shelves of books on how to play Go, a game with really only a couple rules (and one of those is just to keep a game from going infinite turns). But what these books are about is getting everything you possibly can out of a deceptively simple process. There is nothing deceptively simple about git.
- PascalPrecht 7y ago
  Hi, Pascal the author here. I'm probably not very good at expressing that the book is not only about rebasing. While it is the main focus, the book covers a lot of other things that aim to give you a really good understanding of the tool (which I believe is necessary to make sense of (interactive) rebasing). And just like you said, you can totally get around with adding/committing/pushing changes without ever touching the rebase command. Perfectly fine. If you want to be more flexible and productive with your work, you might want to learn how to rebase though.
- darekkay 7y ago
  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.
anton_gogolev 7y ago
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 7y ago
  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 7y ago
    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.
- darekkay 7y ago
  > I feel we as an industry took a wrong turn somewhere Git is a powerful yet complex (and sometimes confusing) tool. But imho people that are using Git every single day and yet not willing to invest some time to learn the fundamentals properly (because it's "just" a VCS) is the real issue here. It's especially difficult for people coming from other VCSs (like SVN or Mercurial). I was there once. I would probably still have the same attitude, if I didn't win a 2-day Git workshop a few years ago, which completely changed my mental model and made "advanced features" appear quite simple. This fact (people learning commit/push/pull and moving on) creates the market for such books. "You don't want to spend 2 days on (re-)learning Git? Here's one major feature explained that you should know".

69 points by PascalPrecht 7y ago

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

datene 7y ago

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

PascalPrecht 7y ago
You should! If there's one tool I'd recommend everyone to learn it's rebasing. Especially interactive rebasing because it enables things like splitting commits apart, squashing them together and even run automated programs.
- WorldMaker 7y ago
  The interactive tools exist outside of rebase. You can also split commits apart as you work on them with for example `git add -i` without needing to rebase. I've met junior developers I'd never trust to get rebase right, but interactive add was an important tool to teach them.
  - PascalPrecht 7y ago
    `git add i` is indeed powerful and lets you interactively craft your index before you create a commit. It doesn't enable you to split up an existing commit though.
    - WorldMaker 7y ago
      Interactive hunk splitting the index maps to the mental model of "splitting the work in progress commit". That may be all a developer needs in a "rebase never" workflow.
      - PascalPrecht 7y ago
        Certainly can not disagree :) I'm not trying to convince anyone here. By now I've sold over 230 copies and I"m getting really positive feedback. So it must be useful to someone.
BossingAround 7y ago
> 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 7y ago
  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.
  - BossingAround 7y ago
    > Obsessing over those is time consuming and risky That's interesting, because to me, it's slopy. If someone doesn't worry about git history, it typically means they don't do pull requests, and that typically, they don't understand know how git works (i.e. how to leverage the features of git). For me, worrying about history literally takes no extra time. I honestly don't understand the argument.
    - wdfx 7y ago
      Pull requests is not the only way to collaborate in a team. git also works with other tools for review and merging can be done by other means.
  - PascalPrecht 7y ago
    Hi, Pascal here. The author. Just to clarify this: The aim of rebasing is not a clean commit history. It enables you to make one in case you've been creating lots of work-in-progress commits with no semantic meaning, which makes it harder to work with it. However, even if you stick to that, it's not like rebasing isn't of value anymore. You might still be interesting in squashing your commits or splitting them up or simply rebase on branch on top of another for various reason. That said, I'd recommend to not advocate not to rebase if it's based on the assumption that it's only useful for clean commit histories.

dreamcompiler 7y ago

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

dang 7y ago
Added. Thanks!

AwesomeFaic 7y ago

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

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

machiaweliczny 7y ago

Related: https://learngitbranching.js.org/ https://learngitbranching.js.org/

dirtydroog 7y ago

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.

hinkley 7y ago
I’m torn on this one, because I firmly believe that git is way too complex. But I also don’t think “and entire book for one [technique]” is the litmus test we are looking for. As a profession we are going on 80 years, and we need to start looking at what maturity looks like in other professions instead of trying to define it for ourselves... believing we can out think everyone, even people who have been thinking about things for a couple thousand years. There are whole books describing how to use chisels. There are shelves of books on how to play Go, a game with really only a couple rules (and one of those is just to keep a game from going infinite turns). But what these books are about is getting everything you possibly can out of a deceptively simple process. There is nothing deceptively simple about git.
PascalPrecht 7y ago
Hi, Pascal the author here. I'm probably not very good at expressing that the book is not only about rebasing. While it is the main focus, the book covers a lot of other things that aim to give you a really good understanding of the tool (which I believe is necessary to make sense of (interactive) rebasing). And just like you said, you can totally get around with adding/committing/pushing changes without ever touching the rebase command. Perfectly fine. If you want to be more flexible and productive with your work, you might want to learn how to rebase though.
darekkay 7y ago
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.

anton_gogolev 7y ago

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 7y ago
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 7y ago
  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.
darekkay 7y ago
> I feel we as an industry took a wrong turn somewhere Git is a powerful yet complex (and sometimes confusing) tool. But imho people that are using Git every single day and yet not willing to invest some time to learn the fundamentals properly (because it's "just" a VCS) is the real issue here. It's especially difficult for people coming from other VCSs (like SVN or Mercurial). I was there once. I would probably still have the same attitude, if I didn't win a 2-day Git workshop a few years ago, which completely changed my mental model and made "advanced features" appear quite simple. This fact (people learning commit/push/pull and moving on) creates the market for such books. "You don't want to spend 2 days on (re-)learning Git? Here's one major feature explained that you should know".