There are many reasons why you might want to use a local GIT repo like it were a remote repo. I recently wanted to test a new process for using GIT pre-commit hooks using Husky and Lint-Staged for easy configuration.
The basic idea for configuring pre-commit hooks was that anytime I changed code and created a GIT commit the specified commands would run and perform certain actions, like formatting, linting, spell-checking, etc.
To be sure everything was configured and working the way I expected I wanted to create a series of “throw away” commits in a test branch that would cause the pre-commit hooks to execute. The same was true for a pre-push GIT hook that I was configuring also. I needed a place that I could push “throw away” pushes to test that everything worked.
For testing, I created a new empty GIT repository on my local machine that I would push code to just for testing. Once I was confident it would work I could then implement everything as part of the main repository, throwing away my test branches and commits. This process was a great way to understand what was happening with the tools and avoid sending a lot of useless commit messages to the main repo.
To get started, create a new bare GIT repository somewhere on your local machine:
cd ~/Desktop
git init --bare test-remote-repo
Then in your main repo, add a new “dummy” remote repository:
cd ~/Projects/my-project
git remote add dummy-remote ~/Desktop/test-remote-repo
Now with a new “remote” repository we can push our code as if it were a remote repo hosted somewhere:
git push dummy-remote main
This technique of creating a “remote” repository on a local machine is handy for more than just testing. I have also used this technique to:
- Create a backup of code onto an external drive
- Recover from bigger GIT mishaps
- Practice other techniques like
rebaseandmerge