Ready to shove your latest work from develop into master and pray the build does not explode? Good. This guide walks you through a sane GitLab merge request workflow that keeps CI happy and releases predictable. Expect a little command line, a little review drama, and fewer unexpected hotfixes.

Quick checklist before you start

• Make sure develop is up to date with origin
• Run the test suite locally if you enjoy fewer surprises
• Have CI pipelines configured on merge requests
• Assign reviewers so the human parts get checked

Create a merge request in GitLab

Open GitLab and create a merge request with develop as the source and master as the target. Give it a clear title and a short description so reviewers do not fall asleep. Mention any migration steps or deploy quirks up front so people do not waste time guessing.

Run and check CI pipelines

Wait for pipelines to finish and get a green status before merging. Use job logs to diagnose failures and re run failing jobs from the UI if needed. If a pipeline keeps failing, fix the tests or the job rather than hitting the merge button and hoping.

Troubleshooting failing jobs

• Inspect the job logs for failing commands
• Reproduce the failure locally when possible
• Rerun jobs in GitLab after pushing a small fix

Request review and collect approvals

Assign reviewers and request approvals. Keep reviews focused on behavior and tests rather than nitpicking formatting. Small focused reviews merge faster and reduce the chance of arguments that derail the release.

Resolve merge conflicts locally by rebasing or merging

If GitLab reports conflicts you need to resolve them locally. Two common approaches are rebase and merge. Rebase keeps history linear and is nice for tidy repos. Merge preserves the original branch history.

git fetch origin
# Option A keep a linear history with rebase
git checkout develop
git rebase origin/master
# fix conflicts, then
# git add files and git rebase --continue
git push --force-with-lease origin develop

# Option B merge master into develop
git checkout develop
git merge origin/master
# resolve conflicts, commit and push
git push origin develop

After resolving conflicts push the updated develop branch and let CI run again. Once pipelines are green and approvals are in place you can complete the merge.

Merge in GitLab or do it locally

Use the GitLab merge button to keep things simple. The platform will perform a fast forward or a merge commit depending on project settings. If you prefer doing the final merge locally use these commands.

git checkout master
git fetch origin
git merge develop
git push origin master

Tag master and create a release

Tagging master marks the release point and makes life easier for deployment and rollbacks.

git checkout master
git tag -a v1.2.3 -m 'release'
git push origin v1.2.3

Alternatively use the GitLab release UI to create a nicer release page with notes and links. Either way, keep your release naming consistent so your next self does not curse you.

Summary and best practices

• Create a merge request from develop into master
• Run and verify CI pipelines
• Request focused reviews and get approvals
• Resolve conflicts by rebasing or merging locally
• Merge via the UI or locally and tag master for release

Following this workflow with GitLab and git keeps your branching and release process predictable. It will not eliminate all chaos but it will reduce the number of midnight panic deploys that end with everyone blaming the CI server.