With rewriting history, we update the git branches to make it look like all the files were originally committed to the engine subfolder. So what's the alternative? Rewriting history! Rewriting history: the options If the odd file has moved, that's not a big deal, but if literally every file has moved, that's not a great experience. However, if the file has moved, you'll get a 404.
The downside to that is that while git itself is ok at tracking file moves (it sometimes gets things wrong), it can cause some other issues.įor example, if you're looking at a file on GitHub, and you want to see what it looks like at a particular commit, then you can use the branch selector to change it.
The simplest way to do this is to just move all the files, and create a new commit with the changes, job done. gitignore files, which are still at the top level. Everything has been moved to an engine subfolder.So I started with a directory that looked like this:Īnd I wanted a directory that looked like this:
So rather than having all the existing code in the root directory, I wanted to move it to a child directory. I was working on a small side project the other day, when I realised it would really make sense for it to effectively be a "monorepo". There's a whole world of pain there, as other people will likely have started branches from the branch, and they can easily end up in a complete mess. What I don't do is rewrite the history of my main/ master branch.
I use git push origin -force-with-lease so much, that I have it aliased as git pof. I like to make lots of small commits and tidy them up later using interactive rebase, and to rewrite my PRs to make them easier to understand (and review). Background: rewriting git historyĪs a git user, I like to Rebase. In this post I describe how I used git-filter-repo to rewrite the history of a git repository to move files into a subfolder.
0 kommentar(er)
