Expand your SuiteScript skills in the Sustainable SuiteScript community for NetSuite developers.

My git Process for SuiteScript in 2025

Created: January 27, 2025

On a recent episode of the SuiteScript Stories podcast , I quickly outlined how I use git for SuiteScript development. Let's expand on that discussion with more detail.

Some Context

Before blindly adopting someone else's approach to anything, it's important to understand the context they're operating in.

I am a solo NetSuite developer who works primarily on large features for NetSuite end users.

I do think my approach is a good baseline or starting point for general SuiteScript teams, but it may not be optimal in every context. If you need help working out the optimal approach for your context, I can help.

My git Environment

I use git for all of my source control; I've used other version control systems in the past and hated them all (👀 looking at you, ClearCase 😡).

To interact with git, I use a bash shell running on WSL embedded in WebStorm; I know plenty of other devs who use a separate GUI client, so those work equally well if that's more your bag.

To host my repositories, I use gitlab. In the past, I've used github and bitbucket as well. I've worked with clients who used Azure DevOps. All of them are great and will get the job done.

My Branching Strategy

I use a few different types of branches to isolate development efforts for my tasks.

The main branch

  • The primary long-running main branch for my stable, Production-ready code.
  • There is only ever one main branch.
  • All other new branches are always created from the tip of main.
  • Any commit on this branch should be considered stable and assumed safe to deploy to any Account.
  • The main branch only receives merge commits from Pull Requests. Commits are never pushed directly on main.

It's critical that I do not expect the tip of main to be the source of truth for what is deployed to Production; I only trust it to be the latest stable code that I have verified as acceptable for Production. The only source of truth for what is deployed to a NetSuite Account is the NetSuite Account.

Feature Branches

  • Short-lived branches for developing new features or fixes.
  • Any commit on a feature branch is considered under active development and assumed only safe to deploy to the active development account.
  • Feature branch names are prefixed with feature/: e.g. feature/1475 or feature/fix-memo-generation
  • New commits are pushed directly to Feature branches.
  • There are many of these branches in each release cycle.

Release Branches

  • Short-lived branches for features which pass all testing and are deemed ready for Production.
  • Release branches follow the naming scheme release/YYYYMMDD, e.g. release/20250127 where the date represents the date we intend to deploy the release to Production
  • Any commit on a release/ branch is considered ready for acceptance testing and safe to deploy to any testing environment.
  • Release branches only receive merge commits from Pull Requests.
  • There is one Release branch per release cycle.
  • The current Release branch is the target of all Feature pull requests in the corresponding release cycle.

Some teams might opt for Semantic Versioning here.

I am usually a proponent of SemVer; however, when your repository represents an entire NetSuite account, it becomes difficult to decide what constitutes a major versus minor versus bugfix change, which then makes it challenging to decide how to increment your versions appropriately.

For that reason, I usually just go with a date stamp for identifying my releases.

Hotfix branches

  • A special case of a Feature branch that skips the Release branch step
  • Short-lived branches for when Production must be stabilized outside the typical release cycle.
  • These should be exceptional, rare branches.
  • Due to the exceptional nature, any commit on a hotfix/ branch should be considered deployable to any Account, but that does not necessarily imply the commit is stable.
  • Hotfix branches follow the naming scheme hotfix/YYYYMMDD e.g. hotfix/20240501 where the date is the date I started work on the hotfix

Once a hotfix is completed, deployed to Production, and merged to main, all other active branches must be updated with the fix. Personally, I follow a rebasing workflow, so that means I need to rebase the current Release branch and any active Feature branches onto the new tip of main. The same is true of a merging workflow, but you would merge down from main rather than rebase up.

That's It

That's all there is to my git approach. There are many advanced tactics and techniques I use when helping clients build more automation into their process. For the projects where I'm doing the actual development work, this process has proven simple, safe, and effective for years now.