Welcome to the NZRT Wiki Podcast. Today we’re looking at Git Branching Strategy.

If you’ve ever worked on a codebase with more than one person — or even just juggled more than one task at the same time — you’ve probably felt the pain of keeping your code organised. That’s exactly what a branching strategy solves. It’s a set of conventions that define how your team handles parallel development, prepares releases, and deals with those urgent production fixes that always seem to arrive at the worst moment.

Let’s start with the building blocks. At the heart of most branching strategies is the main branch — sometimes called master. This is your production-ready code. Every commit on this branch should be something you could deploy right now. Then there’s the develop branch, which acts as an integration point for work in progress. Think of it as the staging area for your next release.

From there, you branch out — literally. Feature branches are where individual developers do their work. You create one from develop, build your feature, and merge it back in through a pull request. Release branches are for preparing a production release — final testing, version number bumps, and last-minute adjustments. And then there are hotfix branches, for those critical production issues that can’t wait for the next release cycle. You branch a hotfix directly from main, fix the issue, and merge it back into both main and develop so nothing gets lost.

NZRT also uses a consistent naming convention across all branches. You’ll see prefixes like feature, bugfix, hotfix, release, and chore — each followed by a slash and a descriptive name. This means you can tell exactly what a branch is for just by reading its name.

Now, NZRT doesn’t use a single branching model for everything. The approach depends on what you’re working on.

For Dolibarr — that’s the ERP platform — and for Dolibarr custom development, NZRT uses trunk-based development. In this model, the main branch is always production-ready, protected by feature flags that let you deploy code without activating it yet. Feature branches here are short-lived, with a maximum lifespan of three days. The idea is to keep branches small and merge them into main frequently, rather than letting long-running branches drift far from the rest of the codebase. There’s no separate develop branch in this model — everything flows directly to main in small, manageable increments. This suits rapid iteration on ERP features, which is exactly what NZRT needs for Dolibarr work.

One rule applies regardless of which model you’re in: all feature branches require a code review before merging. That means opening a pull request on GitHub and getting at least one reviewer to sign off.

So what does this look like in practice? Imagine you’re working on a WordPress upgrade. You start by switching to the develop branch and pulling down the latest changes, so you’re working from the most current version of the code. Then you create a new branch — something like feature slash wordpress-upgrade. You do your work, commit your changes, and push that branch up to the remote repository. From there, you open a pull request on GitHub so a colleague can review your changes before they’re merged in. That’s the full cycle: branch, build, push, review, merge.

Good branching habits keep your codebase clean, reduce merge conflicts, and make it much easier to trace when and why a change was introduced. Whether you’re in trunk-based development or a more structured flow with a develop branch, the underlying goal is the same — make parallel work manageable and releases predictable.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Git Commits and History.

If you’ve ever needed to track down exactly when a bug was introduced, or figure out why a piece of code changed three months ago, you already know why commits matter. Commits are the fundamental building blocks of version control. Every time you commit, you’re capturing a snapshot of your project at that moment in time, paired with a descriptive message that explains what changed and why. Get this right consistently, and your commit history becomes a powerful audit trail. Get it wrong, and you’re left staring at a list of messages like “fix stuff” and “more changes” with no idea what happened.

Let’s walk through the key concepts you need to understand.

First, atomic commits. The idea here is simple — one logical change per commit. Not a dozen things bundled together, just one. That way, if something breaks, you can reverse that single commit without pulling apart unrelated work at the same time.

Next, the staging area. Before you commit anything, you use git add to select exactly which changes go into that next commit. Think of it like packing a box before sealing it — you choose what goes in before you close the lid.

Then there’s amending. If you’ve just made a commit and you realise you forgot something or your message has a typo, you can amend that last commit to fix it. Important caveat though — you can only safely do this before you’ve pushed the commit to a shared remote. Once it’s out there, amending rewrites history and causes problems for everyone else on the team.

When you want to look back at what’s happened, you use git log. This shows you all your commits in chronological order, and every single commit has a unique identifier — a SHA-1 hash — which is that long string of letters and numbers you see next to each entry. That hash is how git tracks and references specific points in your history.

Finally, rebasing. This is a more advanced technique that lets you reorder or combine commits. It’s useful for cleaning up a messy local history before you share your work, so the final record looks logical and easy to follow.

Now let’s talk about the NZRT commit message format, because at NZRT this isn’t optional — every commit needs to follow the standard structure.

The format has four parts. You start with a type and a scope in parentheses, followed by a colon and a short subject line. Then you leave a blank line and write a body with more detail. Finally, you add a footer for things like issue references or breaking change notices.

For the type, you choose from a fixed list: feat for a new feature, fix for a bug fix, docs for documentation changes, style for formatting that doesn’t affect logic, refactor for code restructuring, perf for performance improvements, test for adding or updating tests, and chore for maintenance tasks like dependency updates.

The scope is the area of the codebase you’re touching — so something like dolibarr, wp-sync, or scripts depending on what you’re working on.

The subject line should be written in present tense and kept under fifty characters. Think of it like the subject line of an email — short, specific, and descriptive.

To make this concrete, here’s what a real NZRT commit message looks like in plain language. The type is feat, the scope is wp-sync, and the subject says “add product comparison module.” The body then explains that this implements a side-by-side product comparison feature for customers, adds a new shortcode for easy integration, and includes the CSS and JavaScript needed to make it work. The footer closes issue number forty-two.

That structure means anyone reading the history six months from now immediately knows what changed, why it changed, and which issue it was tied to.

In the NZRT context specifically, the Dolibarr custom repository maintains a detailed commit history and every commit needs to be production-ready before it’s pushed. Daily pushes are the norm, so keeping each commit clean and well-described is critical for the team to audit who changed what and when.

There are three git commands worth knowing for navigating that history. The first shows you the last twenty commits in a compact, one-line-per-commit view. The second lets you look at the full details of any specific commit by passing in its hash. The third shows you the full change history for a single file — so if you want to trace every modification ever made to a particular script or config file, that’s the command you reach for.

Taken together, clean atomic commits with descriptive messages, the NZRT type-scope-subject format, and regular use of git log turn your repository’s history into something genuinely useful — not just a backup, but a clear record of your project’s evolution that anyone on the team can read and learn from.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Git Cheatsheet.

This is a quick reference for the essential Git commands you’ll use day to day at NZRT. Whether you’re just getting started or need a reminder, let’s walk through the key areas together.

First up, setup and configuration. Before using Git on a new machine, you need to tell it who you are. You set your global username and email address — these get attached to every commit you make. Once that’s done, you can view all your configuration settings with a list command. When you’re ready to start a project, you either initialise a new repository from scratch, or clone an existing one from a URL.

Next, the basic daily workflow. You check the status of your working tree to see which files are modified, staged, or untracked. Then you stage the files you want in your next commit — either one at a time, or all changes at once. Once staged, you commit with a message describing what you did. After that, you push your commits up to the remote, and pull down changes your teammates have made.

Branching is how you work on features or fixes without touching the main codebase. You can list your local branches, or all branches including remote ones. You can create a branch and switch to it in one step, or do them separately. When you’re done, you delete it safely — Git warns you if it hasn’t been merged — or force delete if you’re sure. You can also delete a branch from the remote server directly.

For history and inspection, you can view the full commit log or a compact one-line version. You can limit it to the last ten commits, or filter by a specific file. You can show the details of any individual commit, see what’s changed but not yet staged, what’s staged and ready to commit, and even see who changed each line of a file — that last one is called blame.

Merging and rebasing are how you bring branches together. A regular merge combines another branch into your current one. A squash merge does the same but collapses all the incoming commits into a single one, keeping history tidy. Rebasing replays your commits on top of another branch for a clean linear history. Interactive rebase lets you edit, squash, or reorder your recent commits. And if a merge goes wrong mid-way, you can abort it and get back to where you started.

Undoing changes — you’ll need this sooner or later. You can discard changes to a specific file, unstage something you accidentally added, or throw away all local changes with a hard reset back to your last commit. If you need to undo a commit that’s already been pushed, revert is the safe option — it creates a new commit that cancels the old one out. You can also clean out untracked files and directories when your working directory gets messy.

Stashing is your save point for work in progress. If you need to switch context without committing half-finished work, you stash your changes and they’re set aside safely. You can list all your stashes, restore the most recent one with pop, or apply a specific stash by its index number. When you’re done with a stash, you drop it.

Tags and releases give you named markers in your commit history. You can list existing tags, create a lightweight one, or create an annotated tag with a message — annotated tags are the better choice for marking releases. You can push a specific tag to the remote, or push all tags at once.

Remote management covers your connections to remote repositories. You can list your remotes and their URLs, add a new remote, or remove one. Fetch downloads changes from the remote without merging them — handy when you want to inspect before integrating. Fetch with prune also cleans up any remote branches that have been deleted on the server.

And finally, a few advanced commands worth knowing. Cherry-pick lets you apply one specific commit from another branch onto your current one — great for pulling in a single fix. Bisect helps you hunt down which commit introduced a bug by doing a binary search through your history. Reflog shows you a log of everywhere your HEAD has pointed — it’s your safety net when something goes wrong and you need to recover. And filter-branch can rewrite commit history entirely, but that one should be used carefully and deliberately.

That covers the full Git cheatsheet — from first-time setup through to recovery tools for tricky situations.

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

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.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Git Merging and Rebasing.

If you’ve ever worked on a team codebase, you’ve probably hit the moment where two people have been working on the same project at the same time, and now you need to bring that work together. That’s exactly what merging and rebasing are for — and understanding when to use each one makes a real difference to how clean and manageable your code history stays.

Let’s start with the basics. A merge is when Git takes two branches and combines them into one. The most common type is called a merge commit — Git creates a brand new commit that joins the two branches together, and crucially, it keeps the full history of both. You can see exactly what happened and when. There’s also something called a fast-forward merge, which only happens when there’s no divergence between branches — Git just moves the pointer forward in a straight line, keeping everything linear without needing an extra commit.

Rebasing works differently. Instead of joining branches together, rebasing takes your commits and replays them on top of a new base point. The result is a much cleaner, linear history — it looks like everything happened in a straight line, even if the work was happening in parallel. The trade-off is that rebasing rewrites history, which means you need to be careful about using it on shared branches.

Then there are merge conflicts. These happen when the same section of code has been changed in both branches, and Git can’t figure out which version to keep. When that happens, Git adds conflict markers directly into the file. You’ll see a section marked as coming from your current branch, a dividing line, and then the incoming changes below. You have to open the file, read both versions, decide what the final code should look like, and save it manually.

Another strategy worth knowing is a squash merge. Instead of bringing in every individual commit from a feature branch, squash merge collapses all of those commits into a single one. This keeps your main branch history very tidy — one feature, one commit.

Now, how does NZRT actually handle this? For the Dolibarr Custom project, the approach is squash merges into main, following what’s called a trunk-based development model. Before any merge happens, the branch gets rebased so that the history is perfectly linear. This makes rollbacks much simpler — if something goes wrong after a release, you can pinpoint exactly which change to undo.

Importantly, all of this happens through GitHub’s pull request interface, not the command line. You raise a PR, get it approved, and hit the merge button. The squash and rebase settings are configured at the repository level, so the right strategy is applied automatically.

Let’s talk through what that looks like in practice. Imagine you’ve finished a feature branch. First, you switch to the develop branch and run a squash merge of your feature branch into it. That collapses all your feature commits into one clean commit, which you then label with a meaningful message like “feat: my feature.” Before that merge, if you want to avoid any merge commits at all, you rebase your branch on top of develop first, then use a fast-forward-only merge. Fast-forward-only means Git will refuse to merge if it can’t do it in a straight line — a useful safety check.

To bring it all together: use merge commits when you want to preserve the full history of how branches came together. Use rebase when you want a clean, linear history before merging. Use squash merge when you want one tidy commit per feature on your main branch. And always resolve conflicts carefully, reading both sides before deciding what stays.

At NZRT, the decision is already made for you on Dolibarr Custom — squash and linear, always via GitHub. But understanding the mechanics underneath means you’ll know exactly what’s happening when you click that merge button.

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