Menu
I always hear that it's something scary and something I should never do. For example, here's how the pull dialog looks like in SourceTree:
So I'm curious, what would happen and how bad would it be if I had pushed changes, then rebased and pushed them again? And how to fix the repository if I'd break it this way?
285
To push the changes to the branch after a rebase, you need to force push your commits using the -f or --force flag in the git push command on Git. This is because something has changed in the remote branch and the commit history is different for both the remote and your local branch.
If you're working on your own branch, always push immediately after rebasing. and assuming that they should git pull --rebase , which in this case is exactly what you don't want.
Rebasing can be dangerous! Rewriting history of shared branches is prone to team work breakage. This can be mitigated by doing the rebase/squash on a copy of the feature branch, but rebase carries the implication that competence and carefulness must be employed.
Nothing would happen, but your next push would be not accepted.
Unless you would force push. This would not break remote repository also, so it is also not that bad.
Things go bad when you have more people using this repo. Rewriting history can cause a bit of chaos for others who will pull new changes from remote. Especially if they do not have good knowledge of git. There can be different things that might happen for person pulling rewritten remote branch depending on state of their local repository.
So if someone would work on feature X and you changed the code on which he based his changes, he might get at least upset to downright angry depending on how much of his work you made obsolete.
126
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
