Rebase vs Merge?

Question

git

What and when will be more correct to use? In what situations?

Answer 1

To understand when to use merge and rebase, you need to (suddenly) understand how they work and what they do.
At the same time, we try not to use and even completely prohibit the rebase if the story has become collective. What does it mean? Well, for example:

• another branch was made from the branch and someone else is working on it;
  
• changes in the branch have started to undergo code review (since code comments are usually associated with commits, the formation of a new history leads to "falling off" comments).
  

Answer 2

I made this conclusion for myself:
1) it is better to do git pull with the --rebase option, otherwise there will be commits like merge origin/develop to develop in the history
In order not to write --rebase every time, you can globally set the appropriate option in the config
2) it’s also better to add the trunk branch to your branch through rebase, so that the pull request of the feature branch to the main branch consists of only the necessary commits (without merge commits). Gitlab and Bitbucket provide this option from the web interface.
3) Merging your branch back to the main branch is better not through rebase, so that you can see in which branch the change was made. I'm more of a supporter of squash here, but then the tasks in the bug tracker need to be decomposed in more detail.

Answer 3

Well, it's better not to use rebase at all.
It is such a specific tool that its use is only justified in very specific cases.
For example, the password for prod that got into CVS.
The value of CVS is precisely in the history of changes.
And rebase allows this history to be "rewritten".
Usually rewriting history does not lead to anything good :-)