Welcome to the NZRT Wiki Podcast. Today we’re looking at 📚 Git Overview.

So, what is Git? At its core, Git is a distributed version control system. What that means in practice is that it tracks changes to your files over time, lets you collaborate with other developers, and keeps a complete history of your entire project. Every time something changes, Git knows about it. And at NZRT, Git is the foundation that holds all of our development workflows together, particularly around Dolibarr customisations and the supporting tools that sit alongside them.

Let’s start with the key concepts you need to understand before anything else.

First, distributed version control. Because Git is distributed, every developer working on a project has a full copy of the repository, including its entire history. You’re not dependent on a central server being online to work. You have everything you need locally.

Next up are commits. Think of a commit as a snapshot of your code at a specific point in time. Each one comes with a descriptive message so that you and your teammates know exactly what changed and why. Good commit messages matter a lot at NZRT, and there are specific standards for how they should be written.

Then there are branches. Branches let you work on multiple features at the same time without stepping on each other’s toes. You spin up a new branch, do your work in isolation, and bring it back into the main codebase when it’s ready.

The staging area is something that trips people up early on. Before you actually commit your changes, you stage them. This is your chance to review what you’re about to lock in. You choose what goes into the commit rather than just bundling everything together automatically.

You’ll also encounter merge conflicts at some point. These happen when two branches have both made changes to the same piece of code. Git can’t automatically decide which version wins, so it flags it and asks you to resolve it manually.

And finally, tags. Tags are named snapshots that mark important moments in a project’s life, things like a version one release or a stable milestone. You might see labels like v one point zero point zero attached to specific commits.

Now, how does all of this work specifically at NZRT? The main repository you’ll be working with is Dolibarr-Custom, which lives on the NZRT GitHub account and contains all of the ERP customisations. The team uses trunk-based development with feature flags, which means the main branch is always the source of truth, and new work branches off it, gets reviewed, and comes back in cleanly.

Every commit must follow the NZRT Commit Message Standards format, so make sure you’re familiar with that before you start pushing code. Once your changes are ready, you push your branch to GitHub, open a pull request, and a peer reviews it before anything gets merged. GitHub Actions then automatically runs linting and tests on every pull request, so quality checks happen without anyone having to think about it.

For your local development environment, NZRT uses Laragon, which gives you PHP version eight and above, MySQL, and Python three point thirteen all running together. Deployment flows from GitHub through GitHub Actions and out to the production server.

Now let’s walk through what a typical Git workflow looks like at NZRT. There’s a code example in the wiki that shows the full sequence, so let me walk you through what it’s doing in plain English.

You start by cloning the Dolibarr-Custom repository from GitHub down to your local machine. That pulls down all the code and history. Then you navigate into that project folder. From there, you switch to the main branch and pull the very latest changes from the remote, making sure you’re starting from an up-to-date base.

Next, you create a new branch for the feature you’re about to work on. The branch name starts with the word feature followed by a short description of what you’re building. That naming convention is intentional and makes it easy for the team to see what’s in progress at a glance.

After you’ve made your changes, you stage everything you want to include in your commit. Then you write a commit message. In the example, the message starts with the word feat followed by a colon and a short description. That’s the conventional commits format that NZRT follows. Finally, you push that feature branch back up to GitHub, where it becomes available for review.

And that’s the loop. Clone, branch, code, stage, commit, push, review, merge. Once you’re comfortable with that rhythm, Git starts to feel like a very natural part of how you work rather than an extra layer of complexity.

If you want to go deeper, the wiki has related notes on Repository Structure, Branching Strategy, Commits and History, and a Git Commands Cheatsheet. Those are great next stops after this overview.

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