Menu
Our development team is using git and we've lost changes to files at least twice recently. We are using private Github repos.
In the current case, we can go back through the logs on Github and see some updates I made to a file. Later, another team member changed a different part of the file, and it appears to have destroyed my changes. I still have them locally.
Has else anybody experienced this? Any causes or solutions?
I don't think anybody is doing any rebasing or anything fancy - just pulling and pushing.
591
In your terminal (Terminal, Git Bash, or Windows Command Prompt), navigate to the folder for your Git repo. Run this command: git reset --soft HEAD~
Git keeps track of changes to files in the working directory of a repository by their name. When you move or rename a file, Git doesn't see that a file was moved; it sees that there's a file with a new filename, and the file with the old filename was deleted (even if the contents remain the same).
Reset A Specific Commit This usage of git reset is a simple way to undo changes that haven't been shared with anyone else.
There are two Git commands a developer must use in order to discard all local changes in Git, remove all uncommited changes and revert their Git working tree back to the state it was in when the last commit took place. The commands to discard all local changes in Git are: git reset –hard. git clean -fxd.
Similar thing happened to my team too.
Lesson learned: when you pull, you should be careful about merge conflicts. If there're conflicts on pull, git doesn't commit merged changes into your local repo and you must do this after you resolve the conflict. Otherwise, while pushing, you will overwrite remote repo with your local copy NOT containing changes of people did in remote before you pulled. This explains some 'strange files' you might see uncommitted but you're sure that's not your changes - this is indication of a merge conflict on 'pull' and - again - you must commit these changes to local after you resolve the conflict and then push to remote.
If you have no conflicts in merge on pull - no issues with lost changes arise. Because git fetches, merges and commits to your local copy, and 'push' then propagates these merged changes to remote.
154
I managed to reproduce an instance of this in Visual Studio.
In the conflict resolution screen in VS, once you finish picking the changes from both branches, if you don't manually save the file before clicking "accept merge", it just uses the left (old) version without prompting for lost changes, as it would in other circumstances.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
