I might be miss something, but I always merge.
What is the point of having two tools doing almost the same thing? One of them is potentially dangerous and might screw the work if used in a public branch.
Rebase allows to have a clean linear history.
Well, I guess it's personal, but I don't mind merge commits. In our company we usually have max 3 developers working on the repo at the same time, so the git history looks well readable. But I suppose that for the project with 20 developers the git history with merge commits everywhere would look like a mess.
Clean commit messages + amending if necessary + merge - this is all I need.
It's not about how it looks like. Rebasing allows backtracking to specific commits when hunting bugs. It makes git-bisect a very powerful tool for pin-pointing buggy commits. When you know which small commit introduced the bug, you are able to fix it more quickly. This is also why smaller commits are way better than large commits.
I might be miss something, but I always merge.
What is the point of having two tools doing almost the same thing? One of them is potentially dangerous and might screw the work if used in a public branch.
Rebase allows to have a clean linear history.
Well, I guess it's personal, but I don't mind merge commits. In our company we usually have max 3 developers working on the repo at the same time, so the git history looks well readable. But I suppose that for the project with 20 developers the git history with merge commits everywhere would look like a mess.
Clean commit messages +
amending if necessary + merge - this is all I need.It's not about how it looks like. Rebasing allows backtracking to specific commits when hunting bugs. It makes git-bisect a very powerful tool for pin-pointing buggy commits. When you know which small commit introduced the bug, you are able to fix it more quickly. This is also why smaller commits are way better than large commits.
It's possible to backtrack to specific commits and git-bisect with
mergeas well.