Search code examples
gitgitlabrebase

After git rebase history is still not linear


This is our workflow for rebase:

  1. Pull develop
  2. Checkout feature-branch
  3. "git rebase develop"
  4. solve conflicts
  5. after rebase, (still on feature) "git push --force"
  6. go to gitlab and create merge request on feature branch to develop
  7. merge branches

And after this the history is still not linear, we end up with multiple branches "guitar-hero" like.

Any ideas what we are doing wrong?


Solution

  • What you're seeing are merge commits. These track the action of merging the feature branch into the target branch.

    GitLab by default uses a normal merge, which produces merge commits. If you don't want merge commits, you need to perform a fast-forward merge. GitLab supports this: Fast-forward merge requests | GitLab

    Retain a linear Git history and a way to accept merge requests without creating merge commits.


    With that said, I would encourage you to not use this fast-forward workflow, and appreciate the merge commits.

    • The merge commits help to delineate the history and show clear boundaries where one feature completes and another begins.
    • If you're using Merge Requests, then you're doing some amount of code review and approval. In this case, the merge commits record in the permanent Git history the action of approving said branch -- something that is lost with a flat ff-only workflow.