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.

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 and achieving a similar result.

I've added a few tweaks of my own.

# Clone a bare copy of Metaplex
git clone --bare --no-tags --single-branch -b master '[e-mail]:metaplex-foundation/metaplex.git'

# Push to your private empty repository
cd metaplex.git
git push --mirror '[e-mail]:<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

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:
  ​​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:

git remote add metaplex_upstream '[e-mail]:metaplex-foundation/metaplex.git'
git fetch --no-tags metaplex_upstream master

Now rebase you repository:

git rebase metaplex_upstream/master

You might need to force the update:

git push --force

You can also merge instead of rebase

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.

touch extras

I recommend doing as little change as possible to the Metaplex structure.

Click here to see an example from one of my projects

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