Using rebase in original repo to synchronize my fork repo with it is a good practice?

27 Views Asked by At

Let me explain better, I do not like the merge dinamic, it gets too caothic in my opinion. And I really like rebasing, as it creates a linear history of commits. What is the best way of synchronizing with the orignal repo with a linear history of commits? I am a git beginner btw, so if this does not even makes sense, sorry.

When I want to sync with the repo I forked from, here is what I do:

  1. Create a branch in my local, as a clone of the original repo.
  2. Switch to it and rebase it to my main.
  3. Go to my main branch, and FF merge it with the cloned and rebased branch I made.

Doing that, I end up with a linear history of commits starting on my latest main commit and ending on the latest original repo commit. All of that without rebasing my main (since that would screw any other people that is working on it). The only unfortunate part is that since rebasing recreates the original repo commits, Github thinks I do not have the original repo commits and states that I am X commits behind, even though I have them.

So my questions are:

  1. Is this a good practice or is there more to it that could cause problems and I am not seing it?
  2. Is there a easier way to do that, like a git pull --something (--rebase won't work, since it would rebase my main with the original repo, and I actually want to rebase the original repo with my main)?
  3. Is there a way to fix that Github problem? That would be only a whim of mine. Anyway, thanks for the help.
0

There are 0 best solutions below