Search code examples
gitbranchrebasegit-rebasegit-workflow

Is it neccessary to rebase changes from master into branch before committing to keep history clean

I have a question regarding keeping the git-history clean when using git rebase.

I came accross the following problem: I had the following history, made by others of the project:

m0 - m1 - m2 - m3
  \- b1 - b2

Now I wanted to rebase the changes into the master so what I learned was, that you use git rebase master git checkout master git merge branch

all fine. The master now had the changes of the branch and vice versa. so I pushed the master, great. I wanted to push the branch and found out, that the remote has set the flag to forbid non-fast-forward pushes. After some other problems and mistakes made by me, I resolved the problem by deleting the branch, and creating a new one, containing the commits from the master.

Now my question is:...What would have been the right thing to do, when wanting to use rebase...Does every user of any branch always needs to do

git stash
git fetch
git rebase origin/master
git stash pop

before committing, to keep the git-history clean so the problem described earlier won't occur? In my eyes that would be a bit overwhelming for other users (perhaps beginners) within the git project. And as soon as one person would forget rebasing the origin/master before committing his changes within the branch, the whole git-history would not be clean anymore, correct? So what is the correct thing to do? To properly use rebase in the project?

Because what I see is, that as soon as the changes from master are not rebased into the branch before committing it would always happen, that the history looks like this:

m0 - m1 - m2 - m3 - b1 - b2
  \- m1 - m2 - m3 - b1 - b2 //<-----PUSH-Problems, since history changed!

Can anyone clarify my missunderstanding of git rebase? If there is any? Because with my understanding right now it is a bad idea to use git rebase as soon as there are multiple people working on a project.

If the question is not clear enough: I'm asking for some representative example for

  1. resolving the described problem when remote forbids non-fast-forward pushes
  2. The tipicle aproach of using branches and rebase when more than 3 or 4 people work on one project and perhaps one branch

EDIT: Perhaps I should clarify that we need to use a remote branch, since multiple people are working on one feature/one branch

Solution

  • After some more research I noticed, that I seem to have missunderstood the usage of rebase. Rebase in short is there for adding your local changes to a public branch (or master) without creating irrelevant merge-commits. It's not a tool, that shall completely replace merge. This article describes a typical workflow for using rebase: https://www.randyfay.com/node/91 In a summary you (obviously) never want to work on the base-branch directly. When adding something to a project, for example adding something to a feature of a tool (public branch featureX), you create your own local branch (bugfix for said feature, oder adding a functionality, which is part of the feature) and commit to exactly this branch. Then when you are done you rebase (not merge) the base-branch to your local branch, creating a log, which simply added your commits to the back of the base-branch. Then when merging the base-branch with the local branch, it simply fast-forwards the head to the end of the local-branch and you have one nice line with all commits.

    So rebase should only be used for local branches! And not for public-branches, where multiple people work on. Since that would lead to exactly the problem I described in the question. Advices saying to use "git push --force" or similar should only be used in very situation-depending problems, but not here!