You've successfully navigated the pull request process! Your changes have been reviewed, feedback has been addressed, and your colleagues have given their approval. Now comes the exciting part: merging your work into the main branch of the project. This is where your contributions officially become a part of the codebase.
The merge process integrates the commits from your feature branch into the target branch (often 'main' or 'master'). GitHub provides a user-friendly interface for this, making it a seamless experience. When you click the 'Merge pull request' button on your pull request page, GitHub intelligently analyzes the history of both branches and attempts to combine them.
graph LR
A[Feature Branch] --> C{Merge Pull Request};
B[Target Branch (e.g., main)] --> C;
C --> D[Integrated Codebase];
There are a few common ways GitHub can merge your changes, depending on the complexity and history of your branches. The most common are 'Merge commit' and 'Squash and merge'.
Merge Commit
This is the default and most straightforward merge strategy. A new commit is created on the target branch that has two parents: the last commit on the target branch and the last commit on your feature branch. This preserves the entire commit history of your feature branch, showing exactly what happened step-by-step. It's excellent for understanding the evolution of features.
graph TD
A[Target Branch Commit 1] --> B[Target Branch Commit 2];
C[Feature Branch Commit 1] --> D[Feature Branch Commit 2];
B --> E(Merge Commit);
D --> E;
Squash and Merge
Instead of creating a merge commit and preserving all individual commits from your feature branch, 'Squash and merge' takes all the changes from your feature branch and applies them as a single new commit on the target branch. This keeps the history of the target branch cleaner, especially for small, self-contained changes, but you lose the granular commit history of the feature branch.
graph TD
A[Target Branch Commit 1] --> B[Target Branch Commit 2];
C[Feature Branch Commit 1] --> D[Feature Branch Commit 2];
D -- Squashed --> E(Single New Commit on Target Branch);
B --> E;
Rebase and Merge
While less common for beginners and often performed via the command line, 'Rebase and merge' rewrites the commit history of your feature branch. It replays your feature branch's commits one by one on top of the latest commit of the target branch. This results in a linear history, as if you had branched off the latest version of the target branch from the start. Be cautious with rebasing if others are also working on the same feature branch, as it rewrites history and can cause confusion.
graph TD
A[Target Branch Commit 1] --> B[Target Branch Commit 2];
C[Feature Branch Commit 1] --> D[Feature Branch Commit 2];
B --> E(Rebased Target Branch Commit);
D -- Replayed --> E;
Once you've chosen your merge strategy (GitHub will often default to 'Merge commit' for simplicity), you'll see a confirmation. After clicking the final merge button, your changes will be incorporated into the target branch. The next step is often to delete your feature branch, as its purpose has been fulfilled.
It's a good practice to fetch the latest changes from the remote repository to your local machine after a merge has occurred. This ensures your local environment is up-to-date with the newly merged code. You can do this using the command:
git pull origin mainCongratulations! You've successfully merged your code and contributed to the project. This cycle of branching, coding, pull requests, and merging is the heart of collaborative development on GitHub.