Select commits from gitlab develop branch to create merge request to main

To select specific commits from a GitLab develop branch for a merge request to main, you must first isolate those changes using git cherry-pick or by creating a new feature branch. Directly modifying the protected main branch is prohibited in modern Git workflows. The correct approach involves isolating the desired commits into a temporary branch and then opening a Merge Request against main. This ensures code review integrity and prevents accidental direct pushes to production-ready code.

Understanding the Workflow Constraints

In professional GitLab environments, the main branch is typically protected. This protection setting prevents users from pushing directly to it, which safeguards your stable release line from unreviewed or broken code. When you need to move specific changes from develop to main, you cannot simply merge the entire develop history unless that is the intended scope of the release. Instead, you are often dealing with hotfixes or specific features that need to be backported or promoted independently. The previous draft suggested dangerous practices like pushing to protected branches or confusing directions for Merge Requests. We will avoid those pitfalls entirely. The goal is to create a clean, auditable trail of changes that can be reviewed by peers before integration.

Step 1: Isolate the Commits

Before creating any Merge Request, you need to identify the exact commit hashes you want to transfer. Navigate to the develop branch in your local repository or on GitLab’s interface. You can view the commit history to find the specific IDs. Let us assume you have identified two commits: abc1234 and def5678. You have two primary methods to isolate these commits: creating a new branch or cherry-picking. Creating a new branch is generally safer for complex histories because it preserves the full context of the changes. However, if you strictly need only those specific changes applied to a clean slate, cherry-pick is the tool. If you choose to create a new branch, start by checking out main locally. Then, create a new branch named something descriptive, such as feature/hotfix-selection. Switch to this new branch. Now, apply the commits from develop onto this new branch. If you use cherry-pick, run git cherry-pick abc1234 def5678. This command applies the changes introduced by those commits to your current branch without bringing over the rest of the develop history. Resolve any conflicts that may arise during this process. Alternatively, if the commits are contiguous, you might just create a branch from develop at the point after the last unwanted commit and before the first wanted commit, but this is rare. The cherry-pick method is more precise for non-contiguous selections. Once the commits are applied, push this new branch to the remote repository using git push origin feature/hotfix-selection.

Step 2: Create the Merge Request

With your isolated changes pushed to a new branch, you are ready to initiate the Merge Request (MR). Navigate to your project in GitLab. Click on the "Merge Requests" tab in the left-hand sidebar. Select the green "New Merge Request" button. GitLab will prompt you to compare branches. In the "Source branch" dropdown, select your newly created branch, such as feature/hotfix-selection. In the "Target branch" dropdown, select main. This configuration is critical. It tells GitLab that you want to propose the changes from your isolated branch into the main production line. Review the diff in the web interface. Ensure that only the intended changes appear. If you see unexpected files or lines, the isolation step was incorrect, and you should fix it locally before proceeding. Once verified, click "Create Merge Request". Add a clear title and description explaining why these specific commits are being moved. Mention the original issue numbers if applicable.

Step 3: Review and Merge

After creating the MR, other team members will receive notifications. They can review the code, leave comments, and request changes. This step is vital for maintaining quality. If changes are requested, make them in your local branch, push again, and the MR will update automatically. Once approvals are granted, you can merge the request. Choose the appropriate merge strategy, such as "Merge commit" or "Squash and merge," depending on your team's policy. After merging, the changes are now in main. You can delete the source branch to keep the repository clean. For more details on managing protected branches, see our guide on Securing Your Main Branch in GitLab. Additionally, understanding how to handle conflicts during cherry-picking is essential, as covered in Resolving Conflicts During Cherry-Pick Operations.

Frequently Asked Questions

Can I merge develop directly into main?

Yes, you can merge the entire develop branch into main if you are preparing a full release. However, this brings all changes, not just selected ones. Use this method only when the entire development cycle is ready for production.

What happens if cherry-pick fails?

If cherry-pick fails due to conflicts, Git will pause and ask you to resolve them manually. Edit the conflicting files, stage them with git add, and then continue the cherry-pick with git cherry-pick --continue. If you wish to abort, use git cherry-pick --abort.

Why not just copy the files?

Copying files breaks the commit history and version control tracking. Git relies on commit hashes to track changes. Using cherry-pick or branching maintains the integrity of the history, making it easier to audit who changed what and when.

How do I undo a cherry-pick?

You can undo a cherry-pick by resetting your branch. If you have not pushed yet, use git reset HEAD~1 to remove the last cherry-picked commit. If you have already pushed, you may need to force push or create a revert commit, depending on your team's rules.

Is it safe to push to main if it is unprotected?

Even if main is technically unprotected, best practices strongly discourage direct pushes. Always use Merge Requests to ensure peer review. Direct pushes bypass the review process and increase the risk of introducing bugs into the stable branch.