git - dealing with divergence from origin/master

Question

On a particular project I am using git to work on a fork of a shared repo. On this fork only I (and occasionally a bot like requires.io ) have pushed commits to origin/master , so there is on concern about overwriting the work of another team member.

Recently, I pushed quite a few commits to a public origin/master of my fork and later, I realised some of those commits were not sensible, and wanted to edit or revert them. So, I took a copy of the latest version of the code on disk, reverted about 30 commits and pushed the reverted head to origin/master .

Then I rebased the local copy of the repo (which was now about 30 commits ahead of origin/master ). Now git says that my local HEAD has diverged from origin/master and have 30 and 18 different commits each.

I have two questions about this. Obviously, I want my local commits to be pushed to origin/master , I don't want to pull --rebase and allow my local commits to be overwritten by the remote commits. Is there a simple way to do this without opening a merge tool frequently?

Secondly, this seems very messy. What workflow should I be using to avoid this sort of situation? Pushing less frequently is not likely to be a useful option here, since the buggy commits I was trying to fix were to do with a travis.ci YAML file, which I can only usefully test by pushing to origin/master .

Answer 1

Never, ever, rebase remote when there are other people pushing or pulling from it. Otherwise, you're going to upset and frustrate a lot of people.

To do this, just don't push your commits until you're happy with them.

For reverting commits that have been pushed already, use the git revert tool to create a revert commit then push that.

This is generally the way my workflow works.