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 do I need to fix something (what)?

Answer 1

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 2

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.

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

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 5

This is a beginner's understanding of what is going on. You will find answers on git with a higher level of "git wording". But this is how I found my steps through the git jungle. ;) Hope it helps some other beginner.

Start with checking out your main (here develop) branch:

git checkout develop
git pull --all

Then switch to your new branch-A (that has been worked on in parallel to other commits which are already merged into "develop").

You might either pick each commit separately to be more cautious (recommended) or rebase right on top all of the previous commits of that last MR.

Also, in general, look up stash and stash apply, then you do not need any commits, it is much easier.

git checkout branch-A
git stash #(if you do not use commit, stash is recommended)
git rebase -i develop

-i means interactive, meaning that you will need to change things in an editor popping up.

(If you do not use -i, you do not get the editor, which should also be fine since then, the same settings will be used automatically, but that is in this case only, in other cases, you might really need it, thus it seems good to get used to that editor).

This "todo-editor" opens with the commits that led to the last MR for "develop" (which is like the main in your case).

Leave the pick in front of all of the commits in that "todo-editor", this is the default anyway, and change only the last one to edit instead of pick since your new commit shall be edited by all of the commits you do in the following, not the other commits. Your new commit shall be on top of the MR of the "develop" branch, and all other picked commits should be those before the last MR with "develop".

It looks like:

Then write-close that editor and you will now see all of the conflicts of the first "pick" when you look up

git diff

or better you go into codium/vscode and accept just the current or the incoming code at each conflict (files and folders with conflicts are marked red, and in the file, use the arrow up / down to find the conflicts).

Then:

git rebase --abort

Do not git commit or git push during rebase, instead, use --abort and start rebase again, or use git rebase --continue if you are sure about what you are doing and do not need to check the intermediate results. push can harm your commit tree, commit --amend will change the earlier commits, and commit will create new commits from the old ones.

Rebase is not for this. When you use rebase, you want to come back to the starting point at the end and only then you can git commit --amend and git push -f if needed.

Anyway. Going on with the work:

Repeat the steps above for each commit, the next would be the second pick. The third commit is already the "edit" commit. If you reach that, repeat again the steps above, and when there are no conflicts anymore:

git add .
git stash apply #(or if you use commit: git commit --amend)
git push -f

And you have set your new branch on top of the work that was in your latest "develop" MR.

*In my case, the rebase on the "develop" also led me to the MR commit of the previous "develop" MR itself. I ended up in adding a duplicated commit of that MR, which was wrong. This happens if you - wrongly - commit --amend on an existing MR commit that is already merged. Thus, I had one commit more before my latest commit, so that I had two commits instead of one on top of the "develop".

Therefore, better do not use commit, but stash / stash apply on each picked commit.*