{"id":718,"date":"2020-11-18T09:44:15","date_gmt":"2020-11-18T08:44:15","guid":{"rendered":"https:\/\/nguenkam.com\/blog\/?p=718"},"modified":"2022-08-23T15:22:59","modified_gmt":"2022-08-23T13:22:59","slug":"git-rebase-vs-merge","status":"publish","type":"post","link":"https:\/\/nguenkam.com\/blog\/index.php\/2020\/11\/18\/git-rebase-vs-merge\/","title":{"rendered":"Git Rebase vs Merge"},"content":{"rendered":"\n

When you are using git, most probably you may used git merge or git rebase to combine two branches. Pretty much both of these commands do the same thing, but in a different way. This post is to compare the difference between git merge vs rebase and when to use.<\/p>\n\n\n\n


Think about what happens if you’re working on a new feature in a dedicated branch and another team member updates the master branch with new commits. This leads to a split-off history.<\/p>\n\n\n\n

\"A<\/figure>\n\n\n\n


Let’s say that the new commits in master are relevant to the feature you’re working on. To integrate the new commits into your feature branch, you have two options: merging or rebasing. <\/p>\n\n\n\n

the second variante also, Once you completed the feature implementation on feature branch, you need to combine it with the latest master branch. Either you can merge or rebase feature branch with the master.<\/p>\n\n\n\n

Die Merging-Option<\/h4>\n\n\n\n

Let\u00b4\u00b4 s say we are merging branche “master” into the feature branch , This creates a new \u201cmerge commit\u201d in the feature branch that ties together the histories of both branches, giving you a branch structure that looks like this:<\/p>\n\n\n\n

\"Merging<\/figure>\n\n\n\n

Merging is nice because it\u2019s a\u00a0non-destructive<\/em><\/strong>\u00a0operation. The existing branches are not changed in any way.\u00a0<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

After a merge, we have a single new commit on the branch we merge into. This commit contains all the changes from the source branch.<\/strong> <\/p>\n\n\n\n

You can merge master branch into the feature branch by running following command:<\/p>\n\n\n\n

#Merge aus Master nach Feature<\/span><\/p>\n\n\n\n

git checkout feature\ngit merge master<\/code><\/pre>\n\n\n\n
or with single line<\/p>\n\n\n\n
git merge feature master<\/code><\/pre>\n\n\n\n
#Merge aus Master nach Feature, bei dem im Konflitktfall immer Feature gewinnt<\/span><\/p>\n\n\n\n
git checkout feature\ngit merge -s ours master<\/code><\/pre>\n\n\n\n
Git Rebase<\/h4>\n\n\n\n
Rebase is little different than merge. Rebase apply all feature branch changes on top of master branch by creating new commit for each of its previous commit messages. Which means that rebase command will change your commit history and regenerate commits again on top of master branch. Final output of git rebase can be represent as follows.<\/p>\n\n\n\n
\"Rebasing<\/figure>\n\n\n\n
Following command can be used to rebase feature branch on top of master branch. “-i” option used for interactive rebase. Otherwise you can simply use “git rebase master”.<\/p>\n\n\n\n
git checkout feature\ngit rebase -i master<\/code><\/pre>\n\n\n\n
The major benefit of rebasing is that you get a much cleaner project history:<\/span><\/em><\/p>\n\n\n\n
  1. First, it eliminates the unnecessary merge commits required by git merge<\/code><\/li>
  2. Second, as you can see in the above diagram, rebasing also results in a perfectly linear project history \u2014 you can follow the tip of feature all the way to the beginning of the project without any forks<\/li><\/ol>\n\n\n\n
    This makes it easier to navigate your project with commands like git log<\/code>, git bisect<\/code>, and gitk<\/code>.<\/p>\n\n\n\n
    Rebase or Merge<\/h4>\n\n\n\n
    You can use either rebase or merge to combine two branches. Peoples are tend to use rebase over merge due to following facts.<\/p>\n\n\n\n