The Ultimate Git Merge Guide: How to Safely Merge Changes from Dev to Main

Published: 2025-11-13
Author: DP
Views: 25
Category: Git
Content
## The Scenario In modern software development, it's common practice to work on new features or bug fixes in a separate `dev` or feature branch. This keeps the `main` branch stable and always in a deployable state. Once the development work is complete, a core question arises: How do you safely and correctly merge all the commits from the `dev` branch back into the `main` branch? This article will guide you through two primary solutions: a direct local merge and merging via a Pull Request (PR). --- ## Method 1: Direct Merge Using `git merge` This is the most straightforward and fundamental method, suitable for personal projects or simple workflows. The process can be broken down into the following steps: ### Step 1: Switch to and Update the `main` Branch Before performing any merge, it's crucial to ensure your local `main` branch is up-to-date with the remote repository. This helps prevent unnecessary merge conflicts. ```bash # 1. Switch to the main branch # 'git checkout main' is an equivalent command git switch main # 2. Pull the latest changes for the main branch from the remote (usually 'origin') git pull origin main ``` ### Step 2: Perform the Merge With your `main` branch updated, execute the `git merge` command to integrate the commit history from the `dev` branch. ```bash # Merge the commit history from the 'dev' branch into the current branch ('main') git merge dev ``` * **No Conflicts**: If the `main` branch hasn't received new commits since the `dev` branch was created, Git will perform a "Fast-forward" merge. If `main` also has new commits, Git will automatically create a new merge commit. * **Conflicts Occur**: If Git cannot automatically merge the files (e.g., the same line in the same file was changed in both branches), it will report merge conflicts. You will need to resolve these manually. ### Step 3: (If Necessary) Resolve Merge Conflicts When a conflict occurs, open the conflicted files. You'll see markers like this: ```plaintext <<<<<<< HEAD Content from the main branch ======= Content from the dev branch >>>>>>> dev ``` You need to edit the file to decide which content to keep, and then remove the `<<<<<<<`, `=======`, and `>>>>>>>` markers. After resolving all conflicts, complete the merge with the following commands: ```bash # 1. Add the resolved files to the staging area git add . # 2. Commit the merge result; Git will auto-generate a commit message git commit ``` ### Step 4: Push the Changes to the Remote Repository Once the merge is successful locally, push the updated `main` branch to your remote repository, such as a project hosted on `wiki.lib00.com`. ```bash # Push the local 'main' branch to the remote named 'origin' git push origin main ``` --- ## Method 2: The Collaborative Best Practice – Pull Requests (PRs) In a team environment, pushing directly to the `main` branch is often discouraged. A more structured and safer approach is to use a Pull Request (PR) on platforms like GitHub/Gitee or a Merge Request (MR) on GitLab. This method facilitates Code Review and allows for the integration of automated checks, ensuring code quality. The workflow is as follows: 1. **Push the `dev` Branch**: Push your local `dev` branch to the remote repository. ```bash # Ensure your dev branch is up-to-date and push it git push origin dev ``` 2. **Create a Pull Request**: On your code hosting platform (e.g., GitHub), initiate a new Pull Request from the `dev` branch to the `main` branch. 3. **Code Review and Discussion**: Team members can review your code on the PR page and provide feedback. You can push additional commits to your `dev` branch to address the feedback, and they will automatically appear in the PR. 4. **Merge the PR**: Once the code is approved and all automated checks (like CI/CD pipelines) have passed, a maintainer with the appropriate permissions can merge the PR by clicking the "Merge" button. The platform handles the merge, applying the changes from `dev` to `main`. --- ## Conclusion * For **personal projects**, `git merge` is a quick and efficient choice. * For **team projects**, the **Pull Request (PR)** workflow is highly recommended. It significantly enhances code quality and team collaboration transparency through code reviews and automated checks. By mastering these two methods, you can confidently handle various branch-merging scenarios. This guide was prepared by **DP@lib00** at **wiki.lib00**. We hope you find it helpful.