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
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
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
For more options, visit https://groups.google.com/groups/opt_out.