I run across this problem quite a bit: I have a branch that I'm working on. Unfortunately for me, in order to get my code tested and built by our build servers and infrastructure (which is a requirement before it can be code reviewed and merged, plus it builds my code on platforms I don't otherwise have easy access to) I have to push it to our main git repo, since that's the only place the build infrastructure can get it from.
This means I have to publish my work-in-progress branches up to the git server, including all the false starts, backups, single-line "oops" fixes, etc. Then if I merge my branch into the master branch, all that
becomes part of the mainline of the code.
If it's a small change which is really just one thing I can just use a squash merge into master. But for larger changes what I'd like to do is clean it all up into a smaller set of well-formed commits and push
those. This sounds like a job for rebase -i.
However, I've already pushed my branch to master. I know rebasing stuff you've already pushed is considered a no-no in general, but I can't avoid it. Does anyone have suggestions for how to make this work better? Should I be rebasing to a brand new branch, then merge that to master? Just rebase directly to master? None of the above? Something else entirely?
