Why did git (bash) insert a bunch of nonsense into my new files?

Question

So. I added some new files to a git repository that I hadn't touched in a couple months. For some reason, after merging, pulling and pushing my changes to github, I noticed that all the new files had text inserted into them like this:

>>>>>>>>
HEAD
c0d3234k2jl423;lk4j232;l34jk32;l23j4

Those sorts of lines were inserted sort of randomly but perhaps not entirely randomly throughout the newly added files. Fortunately, there weren't too many new files and I was able to go through, clean them out fairly easily, then re- add / commit / push, and now I believe the problem is behind me.

But what was going on? I'm still pretty new to git and github. How can I avoid this happening in the future? I was using the git bash console on Windows XP.

Also - since this might be related - when I tried committing files earlier via my PHPStorm CLI interface, I would hit "commit" and the commit would never complete. Just kept trying and trying. So I kept having to abort that command, then go in and manually delete the index.lock file, as well as a COMMIT_EDITMSG.swp file.

Also, this last time (when the nonsense was inserted), I got an error message that said

E138: can't write viminfo file u:_viminfo!
Press enter or type command to continue

Perhaps that is related as well? Like I said, the problem seems to be behind me for now, just wondering what went wrong and how to avoid it in the future.

Answer 1

This is too long for a comment, so:

You always have to merge (or do something) if you've made some commits and the remote has different commits. You can only push if it would result in only adding new commits on top of what the remote already has. (This is called a "fast-forward".)

It's only you, so the remote shouldn't have different commits. But if you've been pulling shenanigans like rebase or force-pushing without understanding what you're doing, you might have created the delightfully absurd situation of merging a branch into itself.

So, here is a crash course with one of those commit graph diagrams you will learn to hate:

         H <- merge
        / \
you -> G   E <- github
       |   |
       F   D
        \ /
         C
         |
         B
         |
         A

This is what commit history might look like if you did work up to C, then someone else (or you on another computer) added D and E and pushed them, and then you started working from C again and did F and G. You can't push like this, because your local branch doesn't know anything about D and E or how they relate to history; you only have A-B-C-F-G.

But if you merge first to create H, you now have a branch with all the commits from both you and github on it, and github can be updated merely by "moving" its arrow upwards. You can't do this work on the remote because it involves changing your files to create merged versions, and the remote machine doesn't actually have physical copies of your files. (Plus, you'd have no way of resolving conflicts.)

git log --graph --oneline --decorate is a pretty useful view that should show you what you were merging with. The above diagram will come out looking like this:

* H (master)
|\
*| G
*| F
|* E (origin/master)
|* D
|/
* C
* B
* A

git will tell you if there are conflicts after a merge, and git status (which you should run religiously) will always show conflicting files in scary red. When this happens, git has almost certainly injected conflict markers into those files, and you need to resolve the problem and finish the merge. (git will tell you how to finish the merge when it tells you there's a conflict.)

If the stuff between the conflict markers was truly garbage, it's possible your IDE screwed up and corrupted the files. git is pretty solid and should never destroy data (unless you inadvertently ask it to, of course).