3 ms·
Rebasing private code to clean up WIP commits and break it into logical steps is healthy and a very good practice. But as Linus himself says in the linked mail
by tux1968 6y ago
Rebasing private code to clean up WIP commits and break it into logical steps is healthy and a very good practice. But as Linus himself says in the linked mailing list post[1], just don't rebase public code.
"In other words, you really shouldn't rebase stuff
that has been exposed anywhere outside of your own
private tree. But *within* your own private tree, and
within the commits that have never seen the light of
day, rebasing is fine."
-- Linus Torvalds
[1] https://yarchive.net/comp/linux/git_rebase.html https://yarchive.net/comp/linux/git_rebase.html
- frant-hartm 6y agoThis applies mainly to projects with kernel style of development. There are not many of those. In centralized repo style (GitHub), it's fine to rebase, even force push as long as you know exactly what you are doing and coordinate with your colleagues.
- jeremyjh 6y agoIn a lot of projects topic branches generally have a single owner and are not used as the basis of other people's branches, even if they are technically public they are not public in the same sense that he is referring to. If you aren't going to be getting PRs on your branch you can consider it private and rebase all you like IMO. edit to add: I generally prefer people not rebase after they've asked for a PR review just because the reference for comments will be lost. If they want to, maybe do it after all the reviews are approved.
- matwood 6y agoI'm going to disagree, unless your are a solo developer (and even then it's bad practice to rebase commits that have already been pushed). Allowing rebase on shared branches just opens the door to too many possible catastrophic mistakes. When I make a new repo the first thing I do is disable history rewriting.