Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git missing code after merge

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?

like image 972
Daniel Jones Avatar asked Nov 17 '12 10:11

Daniel Jones


People also ask

Does a branch disappear after merge?

In a good workflow, the feature branch is deleted once its merged back into master. New branches should be created for each new feature(s) that you work on.

What does -- no FF do in git?

The Git merge --no-ff command merges the specified branch into the command in the current branch and ensures performing a merge commit even when it is a fast-forward merge. It helps in record-keeping of all performed merge commands in the concerning git repo.

Does merging create a new commit?

Merge branchesGit creates a new commit (M) that is referred to as a merge commit that results from combining the changes from your feature branch and master from the point where the two branches diverged.


1 Answers

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

like image 87
Faisal Avatar answered Oct 12 '22 23:10

Faisal