If you want to merge a feature branch into master on GitLab and still keep your dignity this is the practical guide. It covers keeping your branch current running CI checks opening a merge request and handling reviews with as little sorrow as possible. Yes this is a tutorial and yes you will be mildly entertained.

Prepare your feature branch

Before you push anything make sure your branch is up to date with master and your local tests actually pass. This saves time for everyone and keeps the CI pipeline from angrily failing on behalf of your future self.

• Pick clear commit messages and squash if your repo likes tidy history
• Run unit tests and linters locally

git checkout feature-branch
git fetch origin
# either rebase or merge depending on team rules
git rebase origin/master    # or git merge origin/master
# run tests locally and fix anything that breaks
git add .
git commit -m "Add feature X with tests"
git push origin feature-branch

Open a merge request in GitLab

Go to the GitLab UI and create a merge request targeting master. Give a clear description reference issue numbers and assign reviewers. A short checklist helps reviewers and reduces the number of "please clarify" messages you will get.

Expect at least one reviewer to request tweaks. This is normal. They are not evil they are thorough.

Fix CI failures and address review comments

When the merge request is created GitLab will run the CI pipeline. If a job fails click the pipeline details inspect the failing job logs and fix the exact errors. Common culprits are lint failures missing test fixtures or environment mismatches.

1. Read the job output carefully
2. Reproduce failures locally if possible
3. Commit small focused fixes and push them

# make changes then
git add .
git commit -m "Fix failing test and lint issues"
git push origin feature-branch

Merge into master when everything is green

Only merge once reviewers have approved and the pipeline is green. Use the merge button in GitLab to respect repository settings and merge strategy. Your team might require a merge commit a fast forward or a squash merge. Follow the rule your repo has agreed on.

If you must perform the final merge locally here is a safe example workflow.

git checkout master
git pull origin master
# merge the feature branch according to your policy
git merge --no-ff feature-branch   # or git rebase feature-branch if needed
git push origin master

Cleanup and tag the release

After the merge delete the remote branch and remove the local copy so your branch list does not become a graveyard.

git push origin --delete feature-branch
git branch -d feature-branch
# if you want a release tag
git tag -a v1.2.3 -m "Release 1.2.3"
git push origin --tags

Quick workflow checklist

• Keep branch synced with master
• Run tests locally before pushing
• Open a merge request with a clear description and reviewers
• Fix CI and review comments promptly
• Merge only after approvals and green pipeline
• Delete the branch and tag releases as needed

Follow these steps and your GitLab merge request workflow will be functional and slightly less likely to trigger an email avalanche. If something goes wrong blame Git and then your editor.