4 ms·
Rebasing is perfectly fine for shared branches, all you have to do is pull —rebase and push —force-with-lease when changing branch history. I do this at work f
by sornaensis 8y ago
Rebasing is perfectly fine for shared branches, all you have to do is pull —rebase and push —force-with-lease when changing branch history.
I do this at work for all the feature projects I work on with my team.
You mostly run into problems when people get confused about what is happening when they see the branch history has changed.
Git histories are wonderful and immutable so messing around with commits is quite easy if you know how to move branches around to undo changes if you mess up.
- jamietanna 8y agoI found recently (https://www.jvt.me/posts/2018/09/18/safely-force-git-push/ https://www.jvt.me/posts/2018/09/18/safely-force-git-push/) that `--force-with-lease` can actually be dangerous, you need to specify the ref, too
- jillesvangurp 8y agoGit histories are only immutable if you don't rewrite them with --force. That's why it's called --force. It means you messed up and need to rewrite history. Nice to have the option but probably not great to make it a habit to mess up your history. It's a feature that gets turned off server side in bigger projects and on OSS projects you don't get to push your changes at all and instead you need to work to get people to pull your changes. I'd argue that's a great way to isolate yourself from people misbehaving on their own branches since it is entirely their problem to get their branch in a a shape where it is straight forward to pull (as in fast forward merge). Rebasing can be a valid tool to get there. Force push is not thing generally in such projects except maybe on your own private fork.