How to: Mirror your private Metaplex repository

# How to: Mirror your private Metaplex repository ###### tags: `metaplex` I've seen projects publicly forking Metaplex directly for production launch of their NFTs. You should avoid that - for Metaplex or any other production project for that matter. There is a serious risk someone in your team might push sensitive information (keypairs, custom RPC provider URLs, art assets, etc). Or if you don't want anyone finding your releases ahead of time. Follow this guide to learn how to keep your project safe, updated, and clean. :::info :information_source: Best option would be _not_ to mirror and just use it, in which case you would have your scripts versioned elsewhere. But if you have to, read this doc. ::: ### Make a private copy of Metaplex repository You can't privately fork a repository on GitHub, but this guide explains how to [duplicate a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository) and achieving a similar result. I've added a few tweaks of my own. ```bash # Clone a bare copy of Metaplex git clone --bare --no-tags --single-branch -b master 'git@github.com:metaplex-foundation/metaplex.git' # Push to your private empty repository cd metaplex.git git push --mirror 'git@github.com:<you>/<your private repo>.git' ``` Make sure your private target repository is really empty. That's it. Let's break it down. - **`--bare`** This is just a hosted repo but not for edition. - **`--no-tags`** Currently `cmv2` rendered the semantic versioning for the current tag outdated, so there's no point bringing the tags as of today. - **`--single-branch -b master`** You only need one branch. I'm choosing `master` today but this might change (read below). #### Choosing which branch to mirror :::info :information_source: Check the most recent Metaplex documentation and ask the community. ::: Why `master` you may ask? You may choose another one, but it's the one that received the most fixes as of the time of this writing, and the one I successfully minted a client's project on `mainnet`. It has bugs yes, but I found it easier to fix it than others. I'm definitely _not_ an authority here and you should keep a look at what the Metaplex team brings in the next releases. ### Clean it up This is all optional but it's a final touch. - You should only have one single branch at this point, but make sure `master` is the default. - Change branch name from `master` to `main` (I really don't care, but it is the new convention). - Remove templates which you're not going to use: ```bash rm -rf .github/ISSUE_TEMPLATE/ rm -rf .github/PULL_REQUEST_TEMPLATE/ ``` - Remove the GitHub actions which you don't want (I removed all of them). ### Getting fresh changes from Metaplex Keep an eye on Metaplex updates which will bring new features and fixes that you should _definitely_ merge in your code as well. You should update as soon as changes are released, but close to launch day keep it for critical bugs and security fixes. Always re-test everything. First add the upstream & fetch the changes: ```bash git remote add metaplex_upstream 'git@github.com:metaplex-foundation/metaplex.git' git fetch --no-tags metaplex_upstream master ``` Now `rebase` you repository: ```bash git rebase metaplex_upstream/master ``` You might need to force the update: ``` git push --force ``` :::spoiler You can also merge instead of rebase ```bash git merge metaplex_upstream/master ``` ::: ### Keep your files separated from Metaplex Create a single folder on the root directory which you'll store all your custom code. Otherwise your files will end up all over the place. ```bash touch extras ``` I recommend doing as _little_ change as possible to the Metaplex structure. :::spoiler Click here to see an example from one of my projects ![](https://i.imgur.com/sw0zwXm.png) ::: ### Isolate your custom code from Metaplex code You'll inevitability need to change some of the code that is delivered in the Metaplex boilerplate, for example, the `fair-launch`, or even in the libraries and CLI. In such cases, try creating a new class (file, module, etc) to host the majority of your code, import it into the Metaplex code, and call it. This will reduce the headaches and possible merge conflicts in the future. --- Let me know of any additions or corrections via comments or Twitter: [@EvandroPomatti](https://twitter.com/EvandroPomatti)