How to avoid automatic merge commits when pushing changes to GitLab repository?

Backend
1

I’m working on a development branch and running into issues with unwanted merge commits. Here’s my typical workflow:

  1. I clone the dev branch and make my changes.
  2. Before pushing, I run git pull to get the latest updates.
  3. Git shows me this error:
fatal: Not possible to fast-forward, aborting.
  1. I commit my local changes first.
  2. When I try pulling again, I get these suggestions:
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands:
hint: 
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase  
hint:   git config pull.ff only       # fast-forward only

I usually choose git config pull.rebase false and then push with git push origin dev:dev.

The problem is that GitLab shows an extra merge commit in the history that doesn’t clearly display my actual changes. This makes it really hard to review what was modified. How can I push my work so that only my original commit appears in the repository history?

2

The issue stems from your workflow sequence. You are committing your changes before pulling, which creates divergent histories that Git cannot fast-forward. Instead of using git config pull.rebase false, configure your repository with git config pull.rebase true to enable rebasing by default. This will replay your commits on top of the latest remote changes, eliminating merge commits entirely. Alternatively, you can fetch first with git fetch origin dev, then rebase your changes using git rebase origin/dev before pushing. This approach maintains a linear history and ensures your actual changes remain clearly visible in GitLab without the clutter of automatic merge commits.

3

hmm, sounds like you’re dealing with the classic merge vs rebase dilemma! have you tried using git pull --rebase instead of the config option? it might give you cleaner history. also curious - are you commiting before or after pulling? maybe switching that order could help avoid the divergent branches issue entirely?

4

try git pull --rebase origin dev before comitting your changes. this way git will put your uncommited work on top of latest remote changes without creating merge commits. if you already commited, use git rebase -i HEAD~2 to squash things together nicely.