

Rebasing is great when you're working on a small feature or bugfix branch by yourself, but as soon as more than one person works on the same branch, rebasing should no longer be used on pushed commits. Merge-based workflows should be the norm. Have you performed the "Git game" yet? It's great even if you're already familiar with most of Git's common operations: If you really want to rebase commits that have been pushed, I think you have two options: Either you 'force push' your rebased commits, or you configure the origin server that it doesn't complain about history rewriting. This is fine as long as your commits haven't been pushed to the origin server, but once you try to rebase commits that have already been pushed, the server will reject your push because you're telling it to drop commits that may already have been pulled by other users. It doesn't do this for rebasing, presumably because it's a natural operation to want to use. Git usually requires you to use a 'force' command line option to perform actions that rewrite history. A central theme in Git is that no matter what you do, you never lose history. Essentially you take old commits and replace them with new commits. I didn't read through your posts very carefully yet, so maybe I'm misunderstanding the problem, but it appears that you seem to be confused that your push is rejected after a rebase. I have seen similar results with IntelliJ and SourceTree as well.

However, this results an unexpected output: The only thing works is a Pull followed by a Push. It does not allow the branch to be pushed. This sequence is intentionalĪs per my understanding, after rebasing feature on master, this is what I expect: M1-M2-M3-F1-F2-F3 (master/feature) Then, someone commits M3 on master and finally F3 is committed on feature branch. M1-M2-M3 (master)If my ascii design is not clear, M1 is the first commit to master, then M2. While I know how it should work theoretically, in practice, I am not able to get it to work. I've recently switched to a rebase workflow.
