I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.
At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don’t run into conflicts very often. Branches really shouldn’t be shared too often anyway, and the ones that are should be write protected.
Catastrophic data loss isn’t really possible either with git since it’s all preserved and you can git reflog even if you mess up.
Years of experience don’t really matter here, that’s just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don’t know that.
Anyway, what you’re saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won’t help for either.
Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn’t matter, but you’ll find people screaming at each other about it. See Emacs vs. Vi. Same crap.
I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.
Bad take IMO,
At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don’t run into conflicts very often. Branches really shouldn’t be shared too often anyway, and the ones that are should be write protected.
Catastrophic data loss isn’t really possible either with git since it’s all preserved and you can
git reflogeven if you mess up.The meme is right. Git good
Years of experience don’t really matter here, that’s just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don’t know that.
Anyway, what you’re saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won’t help for either.
Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn’t matter, but you’ll find people screaming at each other about it. See Emacs vs. Vi. Same crap.