Hi all. 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? Cheers! -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
