| | Git Merge | Git Rebase | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Destructive? | **No** - it's non-destructive and safe to use, because merge doesn't affect existing commits and it's preferred for less experienced developers | **Yes**, it's destructive for source branch (feature branch), because all commits are recreated (new commit hash will be created) | | Distributed work affected? | **No**, because commits in remote repo are not affected. | **Yes** - there could be a discrepancy between a new state (branch that has commits with a new commit IDs) and the old state, that the team | ### Git Merge - Git rebase is destructive for source branch, this is feature branch, because all commits are recreated. ### Git Rebase - Git merge is non-destructive and safe to use for less experienced developers. - Because of it, we need to be aware about issues with distributed work, where there will be discrepancy between the real state and the team who may have older state of a feature branch containing old commits with old hashes. This means that using git rebase requires discipline from the team so all developers will adjust their local repository to reflect the changes made after rebase is performed. - In both "merge" and "rebase" methods, all changes can be visible under single commit ("merge" adds extraneous commit, whereas "rebase" offers similar feature, because we can use interactive mode to squash multiple commits into a single one) ### See also 1. [[Git Merge]] 2. [[Git Rebase]] 3. [[What is source and target branch in git rebase?]]