Hey I tinkered a little example:
GitHub only shows the rename properly if you review the specific commit. ( In the feature/rename )
But the important thing in git to follow the history of a file is the log command:
git log --oneline --follow -- new-name.txt
If you clone the repository and try this command out once in feature/rename and feature feature/delete-add you see that in the branch where the rename is lost only the last commit represents the history of the file.
I hope this explanation is detailed enough.
P.s.: You can use rebase -i to split up the commits if it is not in recent history. But keep in mind that this is a rewrite history and you can produce even more complex issue. I recommend to apply such a thing only in feature branches where so one else did build on the changed history.
If anyone is interested how the rebase approach works, I can make something up and document it as a little blog post.
P.s. (2): GitHub uses a heuristic to determine, if a file is just renamed or delted+new. I try to have a single commit to rename the files to keep the history.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.