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.