I disagree with the commentary in step 1 that people hate hierarchies. They hate arbitrary, overly complex, and/or ambiguous ontologies.
For example, dividing a public library into fiction and non-fiction is something that provides arguable value (although some might argue which books should be on which side). Trying to figure out where something exists by the rules of the Dewey Decimal or Library of Congress or any of the many other classification systems out there can be maddening without experience.
Rather than starting with collapsing items, I believe it would be far more useful if there was consideration for how people use and intuit GitHub, and create the items from there.
For example: there are organizations and people who have projects, and projects contain facets like a code repository, issues, releases, and so on.
For example: the code repository contains branches which contain commits. Some commits are tagged, but all contain a file hierarchy. But since users care so much about the files, Github renders by default the latest commit in the project-default branch (such as master).
So perhaps a better view for files would be to make code itself navigable by breadcrumbs - top view is branches and tags, a branch/tag view winds up taking you to a commit history, and a commit takes you to the file view. You just default to a place inside the breadcrumbs when you go to the root of a project and select to view code.
Step 8 seems to be where it finally broke down for me. The file view lost a lot of information that people rely on and want, without consideration for why they rely on it, or how they can get it back if they need it.