title: Peepcode-git.pdf: Best strategy to keep a long standing feature branch in sync with main branch with rebase
body: <p>In the following documentation peepcode-git.pdf located at <a href="https://github.com/pluralsight/git-internals-pdf/releases" rel="nofollow noreferrer">https://github.com/pluralsight/git-internals-pdf/releases</a>, page 39 notes different use cases for rebase. Particularly this quote:</p>
  <p>&quot;If you get a huge project or idea – say refactoring the entire code base to the newest version of your framework or switching database vendors or something, you create a long-term branch, continuously rebase it to keep it in line with other development, and once every - thing is tested and ready, merge it in with your master.&quot;</p>
  <p>The thing is the examples in the e-book goes over the ideas, the abstract applications for rebase but it doesn't provide concrete commands the user can reproduce examples against it. I can follow most of it except the &quot;continuous rebase&quot; part. Typically, when I have rebased I found it effective when:</p>
  <ul>
  <li>I am working on a branch of which I don't know how many commits I will make to get to the solution. Usually when I am experimenting with some code and it doesn't work, I put a note in the commit log to squash that commit since it offers no value. When I finally figure out the desired content state of my code, I rebase the branch to just the important commits, squashing out the others as stated. I then replay those changes via rebase onto the main branch.</li>
  </ul>
  <p>If I am working on a long task however, I don't quite understand the idea of rebasing main onto my branch to stay in sync with it as it means that each commit in main will be replayed into a new commit onto my feature branch but it would  the exact same content state. This seems counter intuitive as valuable information is lost when the commit hash changes. Additionally, when it comes time to put feature branch work onto main, it would replay all its changes onto main including the duplicate commits (with different hashes) onto main. I think it would make more sense to continually merge main onto your local branch to keep it in sync with main and then when complete, rebase it onto main. This would help keep the merge-base to a newer point and reduce the number of commits that are replayed onto main. What am I missing?</p>