Git missing code after merge

Question

We are having an issue with our GitHub repository. I shall explain our workflow:

Developers create feature/bug fix branches from the mainline branch. They pull request their changes to get it merged back in. They may rebase from the mainline branch to get the latest updates from that as they work. After a rebase they push --force on their feature branch.

Two pull requests were automatically merged using the GitHub web interface recently. Subsequently - about two days after the merge of the request - it was discovered that the changes in these commits were not in the code. Nothing in the history suggests that these changes were reverted or overwritten. The merges themselves do not appear in the commit history and the individual commits themselves do not appear either. But the pull request was successfully merged. One of the missing commits is no longer available to cherry pick. We get a fatal - bad object message when we try.

We suspect some rewriting of history has happened. How can we find out and how can we prevent this from happening. Is there something fundamentally wrong with our workflow?

Answer 1

The problem you are facing has to do with your developers rebasing from the main branch then force pushing their branches. What git rebase actually does is it uncommits all the changes you did, merge the main branch, then re-applies your commits (as if they are patch files). This would create a completely new git commit with a completely new hash.

In short, the old commit was lost, and a new identical commit was created.

That is why it is extremely discouraged to rebase any work that is public, because you are effectively changing history. Any people that branched from your work will have a very bad day if their work is based on changes that are no longer available.

edit: the commit is not lost per se, it still exists in your repo. However, it is no longer available on the branch at hand