As you know, there are two main ways in GIT to merge changes from two different branches:
Question: why move the commits (Rebase) when there is a Merge operation that leads to the same result? Or am I misunderstanding something?
The result of the merge and rebase is different. And I'm not talking about the state of the files in the last commit, but about the history in the repository.
merge spawns a new commit-merge, while rebase changes the portable commit itself. More precisely, it creates a duplicate with the same properties. You cannot change commit. But if no one referred to the commit except for the portable branch, it is deleted, and it looks like a change.
The advantage of merge over rebase is that it is easy to separate changes by task, from changes in the merge process. But the disadvantage is that the story is cluttered.
The importance of these differences is obtained to understand when it is necessary for a relatively long history (that is, from what programmers themselves do not remember) to understand who and most importantly why he made a specific change. For example, using blame or bisect
If I work on a project alone, and the changes are fairly simple, I rebase
If the changes are serious and conflicts are guaranteed, then definitely merge .
But if there are several developers, but the changes are simple, then you need to choose a strategy that is convenient for the whole team.
Source: https://ru.stackoverflow.com/questions/942700/
All Articles
mergeis good: stackoverflow.com/questions/708667/… - 0andriyrebaseand when: medium.freecodecamp.org/… - 0andriy 9:13 pmrebaseabout 100 times more often, yes, I was not mistaken, thanmerge. And the reason here is very simple - I am not the main maintainer of the project, on which I mainly work. - 0andriy 9:16 pm