gitlab Request to merge branch-A into develop (3 commits behind) should I worry?

Question

When creating a merge request in gitlab I often get a message: Request to merge branch-A into develop ([x] commits behind) what does gitlab want to tell me? should I worry or d

Answer 1

In addition to the answers above, I usually do the below to rebase my local branch and push. Usually I will have remote origin added to the local git repo, if I am a contributor.

git pull
git checkout <your-branch>
git rebase origin/<remote-branch>
git push --force origin <your-branch>

Answer 2

After some time a merge request is open in a project it is normal that the version of the branch you are trying to merge into becomes outdated due to other people merging their own changes to it.

Gitlab helps you by showing how much the version of the branch you updated is behind the remote branch.

Being behind will not set any hindrance to the act of merging, but it is a common practice to rebase your commits on top of the branch your merging into. This will make your merge request updated by putting your commits chronologically after the ones that already are in that branch. That approach makes the work of the person responsible for the merge easier because the commiter himself has already resolved any conflicts that would have happened.

To do a rebase following the scenario you proposed would be like this:

# Add a remote named `upstream` pointing to the original repository
git remote add upstream https://gitlab.example.com/example/your_project.git

# Fetch the latest commmits from `upstream`
git fetch upstream

# Checkout our branch-A
git checkout branch-A

# Rebase our branch on top of the `upstream/develop` branch
git rebase upstream/develop

# If needed fix any conflicts that may have appeared and then `git rebase --continue`  

# Push the changes to the branch of your merge request
git push --force origin branch-A

Note: The --force flag is necessary when you push because you are rewriting the commit history of origin/branch-A. From git's doc:

[--force] can cause the remote repository to lose commits; use it with care.

Answer 3

In addition of @alejdg's answer, to prevent this

[--force] can cause the remote repository to lose commits; use it with care.

You could also use --force-with-lease which is safer than --force, if others commits are inserted between your rebase and your push --force more information

Answer 4

If you're seeing a 'behind by X commits' message, gitlab is indicating that the branch you're merging into has moved on from the point where you branched.

When you review the diffs in gitlab, they can seem confusing, possibly suggesting that you're about to undo changes that are implemented in later commits on the target branch.

If you want to be sure you're seeing exactly the changes that the merge will perform, the safest thing to do is to update the branch you want to merge by first merging in the target branch...

# fetch the latest code on all branches
git fetch

# checkout your working branch (if you're not already on it)
git checkout branch-A

# merge in the target branch
git merge origin/develop

Fix any conflicts that may arise, then commit them:

# stage changes & commit
git add .
git commit

# push changes to origin
git push

If you now refresh the merge request page on gitlab, the 'behind' message will disappear and the diffs will reflect the changes you've made only.

This is much safer than rebasing your branch as it does not require a --force push. It also means that the chronology of the git timeline matches what actually happened, so if you're trying to track down an issue in the future, you won't be mislead by a re-writing of history.

The downside is that the commit history can look a bit more messy.