Welcome to the NZRT Wiki Podcast. Today we’re looking at 📦 Repositories.

So let’s start with the basics. A GitHub repository is essentially a project container. Think of it as a single organised folder that holds everything related to a project — your code, your documentation, your issue tracker, and the full history of every change ever made. Whether you’re building a web app, managing config files, or storing deployment scripts, the repository is where it all lives.

Now, repositories come with a lot of settings, and understanding those settings is really what separates a well-managed project from a chaotic one. Let’s walk through the key concepts you need to know.

First up is visibility. A repository is either public or private. Public means anyone on the internet can view it — that’s typical for open source projects. Private means only people you’ve explicitly invited can see it. At NZRT, most repositories are private, which makes sense for business tooling and client work.

Next is the default branch. This is the branch that GitHub treats as the source of truth for the project. You’ll often see it called main or develop. It’s also usually the branch that gets deployed, so it matters a lot. Whatever goes into the default branch is what ends up in production.

Then there’s branch protection. This is a set of rules you apply to important branches — usually the default branch — to stop people from accidentally pushing directly to it. You might require that all changes come in through a pull request, that at least one other person reviews and approves that pull request, and that any automated checks or tests pass before the merge goes through. Branch protection is one of those things that feels like overhead until the day it saves you from a very bad situation.

Moving on — collaborators and teams. Collaborators are individual users you’ve given explicit access to a repository. There are five permission levels to know about. Pull access means someone can read and clone the repo. Triage lets them manage issues and pull requests. Write means they can push code. Maintain gives broader project management control. And Admin is full control — settings, access, the works. Teams work similarly, but instead of assigning permissions to individuals one by one, you group users into a team and assign permissions to the whole group. Much easier to manage at scale.

You should also know about the README file. When someone lands on your repository’s home page on GitHub, the first thing they see is the README. It’s your project’s front door — it should explain what the project is, how to set it up, and how to use it. A good README saves everyone time.

And finally, the license. If your repository is public and you want to let others use your code, you need a license. The most common ones at NZRT are MIT, Apache, and GPL. Each has different rules about how people can use, modify, and distribute your work. Without a license, legally speaking, no one has permission to use your code at all.

Now let’s look at a real example from NZRT. There’s a repository called Dolibarr-Custom. It’s private, which makes sense because it holds ERP customisations and modules — internal business logic you wouldn’t want exposed publicly. The default branch is main, and the main branch has protection rules in place: you need at least one review before anything merges, and all status checks must pass. Two collaborators are set up — fin with Maintain access, and xc with Admin access.

If you’re ever setting up a new repository at NZRT, there’s a handy checklist to work through. You want to confirm the visibility is correct, the default branch is set, and branch protection is enabled. Make sure collaborators are invited with the right permission level — not too much, not too little. Set up any webhooks you need for notifications. Add secrets for deployments so credentials never end up in the codebase. Write a README, add a license if it’s open source, and configure a gitignore file so the right files get excluded from version control. And if the project needs a public-facing site, consider whether GitHub Pages should be enabled.

If you want to go deeper, the related wiki notes on GitHub Overview, Branch Protection, and Secrets and Tokens are good next reads.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.