Git Merge

• Operation: git merge develop
• Goal: Integrate the changes from one branch (develop) into another (feature/login).
• Process: Git creates a new "merge commit" that has two parents, one for the last commit of each branch. This preserves the history as it happened.
• Result: The history of the feature/login branch shows a structure with a fork, where the merge commit combines the histories of both branches.

Git Rebase

• Operation: git rebase develop
• Goal: Re-apply the commits on top of another base branch.
• Process: Rebasing takes the changes made in the feature/login branch and reapplies them on top of the develop branch.
• Result: This makes the history linear, as if the changes had been made just after the latest changes in develop.

Key Differences

• History preservation: Merge does not modify the existing history, while rebase rewrites the commit history to make it linear.
• Conflict resolution: With merge, conflicts are resolved at the end of the merge process, while rebase may require resolving conflicts throughout the process as each commit is reapplied.

In short, merge is used to keep a precise history of the changes, while rebase is preferred to simplify the history before integrating a feature branch.

2 - Still not clear?

Git Merge

• What it does: Merges the changes from two branches into one. It combines the development paths.
• How it works: It creates a new commit that has two parents. Each parent represents the last commit of each branch before the merge.
• Commit history: The history clearly shows when the branches diverged and merged. It looks like a graph with a point where two lines join to form one.

Git Rebase

• What it does: Changes the base of your feature branch so that it appears as if it had been created from the last commit of the develop branch.
• How it works: It takes the commits from the feature branch and "replays" them one by one on top of the develop branch.
• Commit history: The history becomes linear. You do not see a fork as with merge. It gives the impression that all changes were made in order, without parallel development.

Why choose one or the other?

• Merge: Used to preserve the complete and explicit history of your project. It is useful when you want to see the precise points where changes were combined.
• Rebase: Used to create a cleaner, simpler history. It is practical if you want your history to look like a direct development sequence without secondary branches.

In short, if you want your project history to show how features were developed in parallel and combined, use merge. If you prefer your history to be simple and direct (as if everything had been developed in a linear order), use rebase.

A practical reminder: rebase only local, unpushed commits. Once a branch is shared, prefer merge (or a pull-request merge) so you do not rewrite history that teammates already pulled. That golden rule avoids most rebase incidents in a team.