Git changes being lost - why?

Question

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 throug

Answer 1

In my case, I stashed my changes to work on an emergency bugfix and simply forgot to unstash and commit them

Answer 2

While I can't speak to your specific issue, what I can say is that yesterday I experienced something very similar. I had a designer mucking around with some URLs in the code, and updating some images in an iPhone app I was finishing up on, and didn't tell me about it. I pushed my changes I had made which touched on some of these files too (different spots however), and it rejected as non-local fast forward. So I pulled, got conflicts, resolved them and pushed. Problem solved. However, I did undo his code changes in the process.

One thing I have recently added to my workflow due to a problem very similar to this I experienced yesterday, on a github private repo; is to stash my changes I'm about to commit, pull from the repo, and apply my stash. Should there be conflicts, resolve those, then push.

Answer 3

We had the same issue: Dev A made a change. Dev B made a change to something else. After Dev B pushed his changes the change that Dev A made "vanished." The change that Dev B made was weeks ago but it seemed no one had noticed the loss of Dev A's changes until now.

The real reason the change "vanished" was that the tool we were using to view history (TFS) was showing an incorrect version of history. When we looked with different tools (SmartGit and SourceTree) we saw what really happened: Someone had overwritten the change while trying to fix a merge conflict and the overwrite was there in plain view.

So, it was not git that was losing changes, it was the tool we were using giving us a false view of history. Just something to look out for.

We've been using git for a year now and 99% of the time that something has "gone wrong" with git, it was actually caused by someone who did not really understand git. The only time it "was git" was a CRLF issue, but really that was because we didn't know git well enough and (thanks to SO) it was easy to handle.

So, always look carefully and you'll probably find the problem boils down to someone not understanding git and doing something they shouldn't have.