5 ms·
Not in remote if you disallow force-push. For local I agree. For hairy rebases I normally set a marker tag (easier than to comb through the reflog). Then it is
by chopin 7y ago
Not in remote if you disallow force-push. For local I agree. For hairy rebases I normally set a marker tag (easier than to comb through the reflog). Then it is easy to reset the branch to its initial irrespective of what you've done.
- mcv 7y agoQuite the opposite, sometimes rebasing means you need to force-push, and not doing so wreaks havoc. Imagine I'm working on my own feature branch, pushing regularly to remote. I make my pull request to develop, but develop is ahead of me and my pull request can't be merged. So I pull develop, rebase my own local commits on top of that, and push the result in my feature branch to remote, which contains some of my old, un-rebased commits. The push is refused, and instead either git or intelliJ automatically pulls from the remote feature branch into my local branch, merging with no problem, so it can be pushed again. It works, but not all my commits occur two times in the history, and that's bad. I suspect it's not git doing this but IntelliJ, but it's a popular IDE, so this can easily happen to anyone if you're accidentally rebasing commits you already pushed. Force pushing prevents the problem, but you're probably better off not rebasing in the first place. Don't change history that also exists in another location.
- deleted 7y ago[deleted]