53

I use GitLab in my project. I'm exploring Merge Requests feature.

  1. I created a topic_branch from master.
  2. Made a bunch of commits on topic_branch.
  3. Pushed topic_branch to remote.
  4. Created a merge request on master to pull changes from topic_branch.
  5. On accept merge in Gitlab, master pulled all the commits and also created a merge commit which is horrible to see duplication of code.

I should have created a squash of commits on branch and then created merge request. But still master would have two new commits, one from the branch and another one would be merge commit. I'm assuming, if I do this from command line i.e,

  1. checkout master
  2. merge topic_branch into master
  3. commit / push master In this case, there would be only 1 commit on master.

How to achieve this from GitLab ?

Improve this question
1
  • If you are looking for rebase and merge in gitlab you will be disappointed to know gitlab does not have it like the way it is available in github > github.blog/developer-skills/github/…. All answers below do suggest fast-forward merge but it essentially isn't rebase and merge. Although the resultant history is linear, still it isn't exactly the same. Commented Sep 15 at 20:18

6 Answers 6

Reset to default
64

TL;DR

Your Project > Settings > General > Merge Request Settings > Fast-Forward Merge.

Note: in recent Gitlab versions the Merge Request Settings are not located under General anymore, they're directly located under Settings: Your Project > Settings > Merge Requests > Merge Method > Fast-Forward Merge.

Personally, I also prefer to do squash commits on every merge.

I think GitLab supports this now.

Steps

  1. Go to your project
  2. Navigate to project settings (Note: This is NOT the profile settings available on the top right)
  3. Go to General tab.
  4. Navigate to Merge Request Settings section
  5. Choose Fast-Forward Merge.

enter image description here

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

PS: the Fast-Forward setting only supported in EE or CE(10.1+)
This fast forward option force us always to rebase source branch. Can we avoid that?
Is there a way to set this as a preference for all future projects?
I do not want a fast-forward. If the development branch has several commits, I do not want to see all the commits in the main, only the result. I have the same comment/issue that Gitlab on squash generates 2 commits. To address this, I do on the command line git merge --no-ff dev-branch, and then push to Gitlab, thus there is only 1 new commit on main. I do not see the value of the extra commit. I wish a merge no-ff could be possible in Gitlab.
2

I should have created a squash of commits on branch

With GitLab 13.3 (August 2020), there is a new option which is interesting in your case:

Squash Commits Options

Squashing commits in Git is a great way to combine several commits into a single one.
It’s great for grouping several commits, which by themselves may provide little historical value, into a single large commit before pushing upstream.
Pushing a single commit allows for a more meaningful commit message, as well as ensuring the group of commits provides a “green” continuous integration pipeline.

In GitLab 13.3 we are adding configurable defaults for squashing commits, allowing project maintainers to configure the option to suit their preferred workflow.

Because changing squash configuration may introduce unwanted behavior, configuration has not been changed for new or existing projects. With 314 upvotes 👍, this is one of the most highly requested improvements by the community and we hope it allows more users to use this powerful feature.

https://about.gitlab.com/images/13_3/create_source_code_configurable_defaults_for_squash_commits_option.png -- Squash Commits Options

See Documentation and Issue.

Improve this answer

Comments

0

As I understood from http://doc.gitlab.com/ee/workflow/rebase_before_merge.html GitLab will always create merge commit to keep a way to revert the whole branch.

Improve this answer

3 Comments

@CSchulz, we have some free Gitlab instance and Merge requests create merge commits even while rebasing. Maybe you mean EE has some "revert" button? You can revert merge commits from console and without need of --force.
Sorry I missed the detail about the rebase. I will delete this comment soon.
Note: The rebase before merge is an Enterprise Edition feature.
0
  1. checkout master
  2. merge topic_branch into master
  3. commit / push master In this case, there would be only 1 commit on master.

That is not true. You will have all the commits from topic_branch and a Merge branch 'topic_branch'commit in your master, except the case that no commits were added to your master branch since you branched off topic_branch. In this case, the default behaviour of git merge is to perform a fast forward merge. A fast forward merge merges your topic_branches changes to master without a merge commit (see here for further documentation).

However, when you create a merge request in GitLab, as the name says, you are requesting to merge your topic_branch into your code base. Per default, GitLab will always create a merge request, even if a fast forward merge is possible, to preserve the fact that the commits were developed on another branch in your history.

Now the good news: you can configure GitLab to perform fast-forward merges instead of creating merge commits: see here. It seems, however, that this is only possible in GitLab Enterprise Edition.

Improve this answer

Comments

0

Well，as the doc say：

GitLab Enterprise Edition offers a way to rebase before merging a merge request. You can configure this per project basis by navigating to the project settings page and selecting Merge Requests Rebase checkbox.

basically Enterprise Edition is the key point，pay for rebase function.

enter image description here

Improve this answer

1 Comment

Not very related to the question IMO. The OP did not ask how to do fask-forward merge if the target branch has new commits.
-1

update currently gitlab supports both rejecting non-fast-forward commits and squashing multiple commits of a merge request, so my comment below isn't that valid anymore

original content

If you don't want to have a merge commit, don't do a merge. That means do a rebase on target branch (master) and a push.

Improve this answer

2 Comments

This doesn't answer the question. Manually yes, you can do all flows you need. But from GitLab's interface there doesn't appear to be a good solution to not have an extra Merge commit.
@k3liutZu it is up to user whether he wants or not to have a merge commit irrespectively of what gitlab thinks of that. The author of the question would obviously prefer not to have one (me to).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.