re: A closer look at git rebase VIEW POST


I agree that it is a much cleaner approach than merging feature branches into master (and master back into the feature branch to get changes from other branches and developers) and as well that squashing and rebasing helps to keep the history of master clean, e. g. by squashing work unit and WIP commits into a single or few feature commits on master. I found this post via How I Git, so my question might relate to that post as well.

But I have one caveat with this workflow:

How do I rebase my feature branch on top of master to get rid of it's stale status when it is remote tracked on GitHub or GitLab? And there are mainly three reasons to remote track a feature branch and regularly push it:

  • Having a backup of the code in case something happens my the local working copy or machine it is on.
  • Working on the same branch on different computers, e. g. office and home office or workstation and notebook.
  • More than one developer is working on a branch, maybe first the backend developer does all the business logic and then the frontend developer takes over to implement the UI.
code of conduct - report abuse