Best practices typically spread quickly and early when they make sense and particularly when they are trivial to achieve. That is not the case with rebase. Why? It's disastrous generally speaking. Krzysztof, you are wrong about rebase not changing history; that's actually a fact not a misconception. Of course, if you want to assert rearranging history isn't changing it, that's your prerogative.
You cannot talk about rebase without making it very clear that you must NEVER rebase a shared branch. That means a branch that two or more developers are changing. Even in the case where you are the ONLY developer, your attempt to push your sequential rebase changes will be rejected, and you must use the "force" push option -f. You can pencil out what a disaster it is to rebase shared branches. Total havoc.
Now, having said that, you should continuously rebase your defect or feature that only you are working on. In other words, always create a personal branch, then rebase against the shared branch. ALWAYS rebase origin/shared-branch versus just shared-branch, so you rebase against the shared branch and can ignore your local version if you have one. You probably need to "share it" for a pull request; no problem, but you'll need force push to update it, and again, nobody else should push to that.
So, yes, rebasing creates a nice linear history by keeping your changes together and pasting them on top of incoming changes. Just follow the simple rule of never into a shared branch, which is typically how good developers work anyway. If create a pull request, and have to fix something up, make sure to force push (do not panic) when your changes are rejected because the repositories have "diverged"
Best practices typically spread quickly and early when they make sense and particularly when they are trivial to achieve. That is not the case with rebase. Why? It's disastrous generally speaking. Krzysztof, you are wrong about rebase not changing history; that's actually a fact not a misconception. Of course, if you want to assert rearranging history isn't changing it, that's your prerogative.
You cannot talk about rebase without making it very clear that you must NEVER rebase a shared branch. That means a branch that two or more developers are changing. Even in the case where you are the ONLY developer, your attempt to push your sequential rebase changes will be rejected, and you must use the "force" push option -f. You can pencil out what a disaster it is to rebase shared branches. Total havoc.
Now, having said that, you should continuously rebase your defect or feature that only you are working on. In other words, always create a personal branch, then rebase against the shared branch. ALWAYS rebase origin/shared-branch versus just shared-branch, so you rebase against the shared branch and can ignore your local version if you have one. You probably need to "share it" for a pull request; no problem, but you'll need force push to update it, and again, nobody else should push to that.
So, yes, rebasing creates a nice linear history by keeping your changes together and pasting them on top of incoming changes. Just follow the simple rule of never into a shared branch, which is typically how good developers work anyway. If create a pull request, and have to fix something up, make sure to force push (do not panic) when your changes are rejected because the repositories have "diverged"