In git:
- History is tied to commit, not files.
- Records status, not changes.
The first element means that the story is never lost, it is simply mysterious. This doesn't help much, but git log --follow (as CodeWizard wrote in his answer ) usually does the job (although --follow has some drawbacks).
One consequence of the second paragraph is that git does not track directory operations, such as renaming files. This means that during merge operations (from git merge or from git rebase or git cherry-pick or git revert or something else) git should guess which files were named.
Git Guesses are based on its similarity index whose calculations are a bit complicated . Your main guarantee is that the file, a bit-bit identical to its previous version, will be detected as a rename.
This is not necessary in itself, because git starts the merge machine later, during git merge or git rebase or something else, and renaming (with bit-bit-identical contents) can be buried in history. For example, suppose that commit C0 creates a file, C1 modifies it, C2 renames it, and C3 modifies it again. If you convince git to compare C1 with C2, it will find the rename, but during the merge operation, git compares C0 with C3, and if the file is not similar enough, git skips the rename.
(We can change git so that it iterates through all the commits on the pedigree path from C0 to C3, looking for renames, which would completely solve this problem while you are doing the renaming as a separate operation. Be somewhat expensive, computationally speaking, but probably "This is a good idea for a future version of Git. Of course, that also won’t help you right now. There is another tool, git-imerge , available today that can help.)
TL DR answer: try to commit renaming as standalone commit
Or at least if you make other changes, make them to other files. Keep the renamed file as similar as possible (bit-bit-bit-identical = guaranteed rename detection, everything else = similarity index comes into play).
It only helps if these merges know how to convince git to do the right merges. In the worst case scenario, three mergers should do the trick: one to the rename point, one to make the rename, and one from there to the end. If a path renaming path is found in a future version of git, use this in the future. Meanwhile, rename-only commit is as good as it is.