Mr. Editor-in-chief Mr. Editor-in-chief • April 18, 2026 • Updated April 24, 2026

Merge Request Workflow with GitLab

Below is a detailed example of a complete merge request (MR) workflow in GitLab, including the steps to create, update, review, and merge a merge request, along with example Git commands. This example assumes you're working on a feature branch, addressing reviewer feedback, and completing the merge request process.

Scenario

You’re a developer working on a GitLab project called my-project. You need to add a new feature (e.g., a login page) to the repository. A reviewer will provide feedback, and you’ll update the code based on their comments before merging the changes into the main branch.

Step-by-Step Merge Request Workflow with Example Git Commands

1. Create a Feature Branch

Start by creating a new branch for your feature work from the main branch.

  • Commands:
  # Ensure you're on the main branch and up-to-date
  git checkout main
  git pull origin main

  # Create and switch to a new feature branch
  git checkout -b feature/add-login-page
  • Explanation:
  • git checkout main: Switches to the main branch.
  • git pull origin main: Ensures your local main branch is up-to-date with the remote repository.
  • git checkout -b feature/add-login-page: Creates and switches to a new branch named feature/add-login-page.

2. Make Changes and Commit

Edit your code (e.g., create a login.html file and update app.js to include login logic).

  • Example Changes:
  • Create login.html:
    <!-- login.html -->
    <html>
      <body>
        <h1>Login Page</h1>
        <form>
          <input type="text" placeholder="Username">
          <input type="password" placeholder="Password">
          <button type="submit">Login</button>
        </form>
      </body>
    </html>
  • Update app.js:
    // app.js
    function handleLogin() {
      console.log("Login button clicked!");
    }
  • Commands:
  # Stage your changes
  git add login.html app.js

  # Commit your changes with a descriptive message
  git commit -m "Add login page and basic login handler"

  # Push the branch to GitLab
  git push origin feature/add-login-page
  • Explanation:
  • git add: Stages the modified files for commit.
  • git commit -m: Commits the changes with a message describing the work.
  • git push origin feature/add-login-page: Pushes the branch to the remote GitLab repository.

3. Create a Merge Request in GitLab

Once the branch is pushed, create a merge request in GitLab to propose merging feature/add-login-page into main.

  • Steps in GitLab:
  • Go to your GitLab project (e.g., https://gitlab.com/your-username/my-project).
  • Navigate to Merge Requests in the left sidebar and click "Create merge request".
  • Select feature/add-login-page as the source branch and main as the target branch.
  • Fill in the merge request details:
    • Title: "Add login page feature"
    • Description: This MR adds a basic login page with a form and a JavaScript handler for login functionality. - Addedlogin.htmlwith a simple form - Updatedapp.jswith a login handler. Please review and provide feedback.
    • Assign a reviewer (e.g., @reviewer-username).
    • Optionally, check "Delete source branch when merge request is accepted" to clean up after merging.

  • Click "Create merge request".

  • Explanation:

  • The merge request is now visible in the Merge Requests section, and the assigned reviewer will be notified.
  • If your project has a CI/CD pipeline, it will run automatically to test your changes.

4. Reviewer Leaves Comments

The reviewer examines your merge request and leaves feedback in the Discussion or Changes tab. For example: - Inline Comment (in login.html on line 5):

  Reviewer: The password input should have `type="password"` to mask the input for security.
  • General Comment (in the Discussion tab):
  Reviewer: Please add basic form validation in `app.js` to check if the username and password are not empty before logging.

5. Update Code Based on Reviewer Feedback

You need to address the reviewer’s comments by updating the code in your feature branch.

  • Make Changes:
  • Update login.html to fix the password input:
    <!-- login.html -->
    <html>
      <body>
        <h1>Login Page</h1>
        <form>
          <input type="text" placeholder="Username">
          <input type="password" placeholder="Password">
          <button type="submit">Login</button>
        </form>
      </body>
    </html>
  • Update app.js to add form validation:
    // app.js
    function handleLogin(username, password) {
      if (!username || !password) {
        console.log("Error: Username and password are required!");
        return;
      }
      console.log("Login button clicked!");
    }
  • Commands:
  # Ensure you're on the feature branch
  git checkout feature/add-login-page

  # Stage the updated files
  git add login.html app.js

  # Commit the changes with a message referencing the feedback
  git commit -m "Address reviewer feedback: fix password input type and add form validation"

  # Push the changes to the same branch
  git push origin feature/add-login-page
  • Explanation:
  • The new commits are automatically added to the existing merge request in GitLab.
  • The reviewer will be notified of the updates via GitLab’s activity log.

6. Respond to Reviewer Comments in GitLab

Go to the merge request in GitLab to acknowledge the reviewer’s comments and confirm the changes.

  • Steps in GitLab:
  • Open the merge request and go to the Discussion tab.
  • Find the reviewer’s inline comment on login.html and reply: @reviewer-username: Fixed the password input type to type="password". Please check.
    • Optionally, click "Resolve thread" if the comment is fully addressed.
  • Reply to the general comment about form validation: @reviewer-username: Added form validation inapp.jsto check for empty username and password. Ready for re-review.

  • If necessary, re-assign the reviewer or mention them to request another review.

  • Explanation:

  • Resolving threads helps track which feedback has been addressed.
  • Mentioning the reviewer (@username) sends them a notification to re-review.

7. Handle Merge Conflicts (If Any)

If the main branch has changed since you created your feature branch, you may encounter merge conflicts when the reviewer tries to merge. GitLab will notify you if conflicts exist.

  • Commands to Resolve Conflicts:
  # Switch to your feature branch
  git checkout feature/add-login-page

  # Merge the target branch (main) into your feature branch
  git pull origin main

  # If conflicts occur, Git will pause and mark conflicting files
  # Edit the conflicting files to resolve conflicts manually
  git add <conflicted-files>

  # Complete the merge
  git commit

  # Push the resolved branch
  git push origin feature/add-login-page
  • Explanation:
  • Resolve conflicts by editing the files to keep the desired changes.
  • The updated branch will reflect in the merge request, and the “Merge” button will become available if no further conflicts exist.

8. Reviewer Approves and Merges

Once the reviewer is satisfied with your changes: - They approve the merge request (in GitLab, under the Overview tab, they click "Approve"). - They merge the merge request by clicking the "Merge" button (assuming they have Maintainer or Owner permissions). - If you selected "Delete source branch" when creating the merge request, the feature/add-login-page branch is automatically deleted.

9. Clean Up (Optional)

If the source branch wasn’t deleted automatically: - Command:

  # Delete the branch locally
  git branch -d feature/add-login-page

  # Delete the branch remotely
  git push origin --delete feature/add-login-page
  • Explanation:
  • This removes the feature branch to keep the repository clean.

10. Verify the Merge

  • Pull the updated main branch to your local repository:
  git checkout main
  git pull origin main
  • Verify that your changes (e.g., login.html and app.js) are now part of the main branch.

Additional Tips

  • CI/CD Pipelines: Ensure any configured pipelines (e.g., linting, testing) pass after each push. Check the Pipelines tab in the merge request for status.
  • Draft/WIP Status: If your merge request isn’t ready for review, mark it as a Draft (or Work in Progress) by adding “Draft:” or “WIP:” to the title when creating it.
  • Permissions: You need at least Developer permissions to create and push to branches, but only Maintainer or Owner roles can merge or delete branches in protected settings.
  • Communication: Use GitLab’s discussion threads to clarify feedback or ask questions to avoid unnecessary back-and-forth.

Example Workflow Recap

  1. Created branch feature/add-login-page and added login.html and app.js.
  2. Pushed changes and created a merge request in GitLab.
  3. Reviewer left comments (e.g., fix password input and add validation).
  4. Updated code, committed, and pushed to the same branch.
  5. Replied to reviewer comments and resolved threads in GitLab.
  6. Handled merge conflicts (if any) and pushed resolutions.
  7. Reviewer approved and merged the MR into main.
  8. Cleaned up the feature branch.

If you need clarification on any step, want help with a specific GitLab feature (e.g., pipelines, labels), or encounter issues like merge conflicts, let me know, and I’ll provide tailored guidance!

After a reviewer leaves a comment on your merge request in GitLab and you need to re-edit the code, follow these steps to address the feedback and update the merge request:

  1. Review the Comments:
  2. Go to the merge request in your GitLab project.
  3. Check the "Discussion" tab for general comments or the "Changes" tab for inline comments on specific lines of code.

  4. Note the reviewer’s feedback to understand what changes are required.

  5. Make Changes to Your Code:

  6. Locally Update Your Branch:
    • Switch to the source branch of the merge request on your local machine using git checkout <branch-name>.
    • Make the necessary code changes based on the reviewer’s comments using your code editor.
  7. Commit the Changes:
    • Stage your changes with git add . or specific files.
    • Commit the changes with a descriptive message, e.g., git commit -m "Addressed reviewer feedback: updated function X".

  8. Push the Changes:

    • Push your updated branch to GitLab with git push origin <branch-name>.
    • This automatically updates the existing merge request with your new commits.

  9. Notify Reviewers:

  10. Go back to the merge request in GitLab.
  11. In the "Discussion" tab, find the reviewer’s comment and click "Reply" to acknowledge their feedback (e.g., “I’ve updated the code to address this. Please review.”).
  12. If the comment is part of a thread, you can mark it as "Resolve thread" if the issue is fully addressed (click the checkmark icon next to the comment).

  13. Optionally, mention the reviewer using @username to notify them of your response and changes.

  14. Wait for Further Review:

  15. The reviewer will be notified of your updates and can re-review the changes in the "Changes" tab.

  16. They may approve the merge request, request further changes, or leave additional comments.

  17. Optional: Request Re-Review:

  18. If the reviewer doesn’t notice your updates, you can explicitly request a re-review by mentioning them in a comment or re-assigning them as a reviewer in the merge request settings.

Additional Tips:

  • Link Commits to Comments: When committing changes, you can reference the merge request or specific comment by including the merge request ID (e.g., !123) in your commit message for clarity.
  • Check CI/CD Pipeline: Ensure any CI/CD pipelines (if configured) pass after pushing your changes. Fix any issues if the pipeline fails.
  • Communicate Clearly: If the reviewer’s feedback is unclear, ask for clarification in the merge request’s discussion thread before making changes.
  • Permissions: Ensure you have the necessary permissions to push changes to the source branch.

If you encounter issues (e.g., merge conflicts or pipeline failures), let me know with more details, and I’ll guide you through resolving them!

← Back