Here are diagrams and explanations for the four merge methods you asked about:
- Three-way Merge: In a three-way merge, Git will create a new commit that has two parent commits. If Git encounters data that is changed in both histories, it won't be able to automatically combine them, and this situation results in a version control conflict. Git will then need user intervention to continue.
-
Fast-forward Merge: In a fast-forward merge, if the feature branch you're merging into the main branch is ahead of the main branch, Git will just move the main branch pointer up to the latest commit on the feature branch. No new commit is created in this case.
-
Squash Merge: Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge adds all the file changes to a single new commit on the default branch. The squash merge commit doesn't have a reference to the topic branch, and it will produce a new commit that contains all changes from the topic branch. It's recommended to delete the topic branch to prevent any confusion【32†source】.
- Rebase Merge: From a content perspective, rebasing is changing the base of your branch from one commit to another, making it appear as if you'd created your branch from a different commit. Internally, Git accomplishes this by creating new commits and applying them to the specified base. It's important to understand that even though the branch looks the same, it's composed of entirely new commits. Rebasing is a common way to integrate upstream changes into your local repository. Pulling in upstream changes with Git merge results in a superfluous merge commit every time you want to see how the project has progressed. On the other hand, rebasing is like saying, “I want to base my changes on what everybody has already done.
