If you are like myself, you would probably have setup a GitHub account some time ago, and just never looked back. GitHub is a great service for those of us actively using git to manage our project source files. It is worth paying for – if you can justify the perks that come with the non-basic plans. In my situation, this is not the case as I have over 15 projects in GitHub, but none of them are public.
After reviewing my setup, I realized I was more or less wasting $12/month, because BitBucket has a free tier that gives 5 free users, and unlimited private repos!
After quickly setting up my account, I realized that there was an “import from github” tool, but it got me thinking and after doing some quick Google searches, I learned that there was an unknown (to me) option –mirror. See this hardcoded article on how to use it.
The –mirror option of the push command, as explained by the git documentation:
Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.
The verbiage is a bit confusing at first, but it is simply saying that the when the –mirror option is passed to the push command, the repository that you are pushing code to will be mirrored into the new repo that is specified. This includes all commit history and other meta-ops.
For example, in my case, I did the following:
- git commit-a
- // this commits my local changes | if on a multi user project, it is a good idea to git pull first and merge in any outstanding changes
- git push —mirror firstname.lastname@example.org:konsoltcorp/ooh_so_fancy_schmancy.git
- // this pushes the latest code into the repo, and mirrors the code onto the new ooh_so_fancy_schmancy repo.
- git remote set–url origin email@example.com:konsoltcorp/ooh_so_fancy_schmancy.git
- // This last step updates the remote repo meta data in your local copy. From here on out, all pushes will be going to the new mirrored location.
This is not necessarily the best option for all situations, and I recommend spending some time to read the git documentation thoroughly to get an understanding of how this works. If you are on GitHub and the number of private projects that you store there are more than the public ones, this is something you might consider when migrating. The tools for import are also available, but you know, #CommandLiningIt is cooler, gives more control and exposes you to some of the intricate workings of the automated tools.
– Martello Jones