How previously introduced changes can go missing from a branch?

Summary

Previously added commits go missing from a branch causing changes to be lost.

This can occur in scenarios if multiple users working on same file and branch and misses to perform a fetch to get the newly added changes. This will result in changes added by one user to be ignored. 

Diagnosis

Verify if a change on a particular file exists by accessing the file directly on the UI using the commit on which you want to verify. 

For example, if you want to verify whether certain lines exist or not on the below file package.json at a particular state of a repository. In the below URL, the user can verify how a file looks like at the commit - 8afa538b1003b5e6bc1465303744659c31aeba8f

The format of the URL would look like - https://bitbucket.org/<workspaceid>/<repositoryslug>/src/8afa538b1003b5e6bc1465303744659c31aeba8f/package.json

Cause

This behaviour can be reproduced in the following scenario.

• • Assuming a user-A adds a change to a file using commit-x and that commit-t is the parent of the commit-x.

  • Another user-B who is working on the same file wants to add another changes on different lines.

  • On his local copy, this user-B only has commit-t and doesn't have commit-x as this commit is recently added by user-A.

  • If user-B misses to perform a fetch from the branch and continues to add his change to commit-t by creating commit-s. 

  • Now user-B pushes the commit-s to the repository with force push. 

  • Although the commit-x exists on the repository but other user-B missed to fetch these changes and pushed his own changes on an older version of the file. 

• This results in loss of the commit-x and changes added with commit-x will be lost due to a possible force push. 

Solution

• Avoiding force push will help mitigate these issues. Force push can be restricted on branches using the branch restriction rule as described in this document. 

• It is recommended for every user to perform a 'git pull --all` before adding new changes, so that they will work on the recent version of the repository in all scenarios.

• Alternatively, it is also a good practice for customers to work on different branches instead of a common branch in order to isolate the work and use pull requests to merge the changes after going through a code review process.