Skip to main content

NetSuite Git User Guide

Complete Guide for VS Code Users - For Vendor Team & IT Team Developers

How to Use This Guide​

This guide covers everything you need to know to work with Git and VS Code. Start with Getting Started for initial setup, then refer to Daily Workflows for step-by-step instructions on common tasks.

Part 1: Getting Started​

What is Git? (Basic Concepts)​

Git is a version control system that tracks changes to your code. Think of it like "Track Changes" in Microsoft Word, but much more powerful.

Key Terms You Need to Know​

TermWhat It Means
Repository (Repo)A folder that contains all your project files and their complete history. Like a shared drive but with version tracking.
CloneDownloading a copy of the repository to your computer. You only do this once.
BranchA separate copy of the code where you can make changes without affecting others. Like working on a draft before publishing.
CommitSaving your changes with a description. Like clicking "Save" but with a note about what you changed.
PushUploading your committed changes to GitHub so others can see them.
PullDownloading the latest changes from GitHub to your computer.
Pull Request (PR)A request to merge your changes into the main code. This is where code review happens.
MergeCombining changes from one branch into another.
Merge ConflictWhen two people edit the same lines of code. Git needs your help to decide which version to keep.

Our Branches Explained​

BranchPurposeRule
mainProduction code - what's live in NetSuiteNEVER push directly
developIntegration testing - combines everyone's workMerge via Pull Request only
feature/*Your working branches for new featuresCreate from develop, merge back to develop
bugfix/*Your working branches for bug fixesCreate from develop, merge back to develop
hotfix/*Emergency production fixesCreate from main, merge to main AND develop

One-Time Setup (Do This First)​

Complete these steps once to set up your development environment.

Step 1: Install Required Software​

  1. Install Git: Download from git-scm.com and run installer (use default options)
  2. Install VS Code: Download from code.visualstudio.com
  3. Install SuiteCloud Extension: In VS Code, go to Extensions (Ctrl+Shift+X) → Search "SuiteCloud" → Install

Step 2: Configure Git with Your Identity​

In VS Code, open Terminal (Ctrl+` or View → Terminal) and type these commands:

git config --global user.name "Your Full Name"
git config --global user.email "your.email@company.com"
tip

Use the same email you used for your GitHub account!

Step 3: Clone the Repository​

This downloads the entire project to your computer. You only need to do this once.

  1. Open VS Code
  2. Press Ctrl+Shift+P to open Command Palette
  3. Type "Git: Clone" and press Enter
  4. Paste the repository URL: https://github.com/[org-name]/netsuite-production.git
  5. Choose a folder on your computer to save the project (e.g., C:\Projects\)
  6. When prompted, sign in to GitHub
  7. Click "Open" when VS Code asks to open the cloned repository

Step 4: Verify Setup​

Check that everything is working:

  • In VS Code, look at the bottom-left corner - you should see main (the current branch)
  • In the left sidebar, click the Source Control icon (looks like a branch/fork)
  • You should see the project files in the Explorer panel

Understanding VS Code Git Interface​

VS Code has built-in Git support. Here's where to find everything:

LocationWhat You Can Do
Bottom-Left Status BarShows current branch name. Click to switch branches or create new ones.
Source Control Panel (left sidebar, branch icon)See changed files, stage changes, write commit messages, push/pull.
Sync Button (↑↓ arrows in status bar)Push your changes up and pull others' changes down in one click.
... Menu (in Source Control panel)Access all Git commands: pull, push, stash, branch operations, etc.

Part 2: Daily Workflows (Step-by-Step)​

Follow these step-by-step instructions for common development tasks.

Scenario A: Creating a New Feature​

Use this workflow when: You need to create new functionality or make enhancements.

A1. Update Your Local Code First​

Always start by getting the latest code from the team.

  1. Click the branch name in the bottom-left corner of VS Code
  2. Select develop from the list
  3. Click the Sync (↑↓) button in the status bar, or go to Source Control → ... → Pull
  4. Wait for the sync to complete

A2. Create Your Feature Branch​

  1. Click the branch name (develop) in the bottom-left
  2. Select "+ Create new branch..."
  3. Type your branch name following this format:
Your TeamBranch Name Format
Vendor Teamfeature/vendor-[TICKET]-[short-desc]
IT Teamfeature/it-[TICKET]-[short-desc]

Examples: feature/vendor-NS123-invoice-automation or feature/it-NS456-report-enhancement

  1. Press Enter to create the branch. VS Code automatically switches to your new branch.

A3. Make Your Changes​

  1. Edit the script files in VS Code
  2. Test your changes in NetSuite Sandbox
  3. Modified files appear in the Source Control panel with an M (modified) or U (new file)

A4. Commit Your Changes​

  1. Open the Source Control panel (branch icon in left sidebar)
  2. Review your changed files
  3. Click the + next to each file to stage it (or click + next to "Changes" to stage all)
  4. Type a commit message in the text box at the top:
[NS-123] Add invoice validation logic for international orders
  1. Click the ✓ Commit button
Good Commit Messages

Start with ticket number, describe WHAT changed, not HOW.

  • Good: [NS-123] Fix tax calculation for EU customers
  • Bad: Changed line 45

A5. Push Your Branch to GitHub​

In the Source Control panel, click "Publish Branch" (or Sync if it shows that)

Your branch is now on GitHub and visible to others.

A6. Create a Pull Request​

  1. Go to GitHub.com and open your repository
  2. You'll see a yellow banner: "[your-branch] had recent pushes" → Click Compare & pull request
  3. Fill out the pull request form:
    • Base: develop (this is where your code will go)
    • Compare: your branch name
    • Title: Brief description of changes
    • Description: Fill in the template (testing done, rollback plan, etc.)
  4. Click Create pull request
  5. Wait for reviewer approval (you'll get an email notification)

A7. After Approval - Clean Up​

Once your PR is approved and merged:

  1. In VS Code, switch back to develop branch (click branch name in bottom-left)
  2. Pull the latest changes (Sync button or Source Control → Pull)
  3. Delete your local feature branch: Source Control → ... → Branch → Delete Branch

Scenario B: Fixing a Bug​

Use this workflow when: You need to fix a non-critical bug that can wait for the next release.

Process: Same as Scenario A, but use bugfix/ prefix instead of feature/

Branch naming:

  • bugfix/vendor-NS789-fix-po-validation
  • bugfix/it-NS101-correct-tax-calc

Scenario C: Emergency Hotfix​

Use this workflow when: There's a critical production bug that needs immediate fixing.

Important

Hotfixes go directly to main and bypass develop. Notify the IT Lead before starting a hotfix!

C1. Create Hotfix Branch from Main​

  1. Switch to main branch (click branch name → select main)
  2. Pull latest: Source Control → ... → Pull
  3. Create new branch: hotfix/NS999-critical-fix-description
  4. Make your fix and test thoroughly
  5. Commit and push
  6. Create Pull Request to main (not develop)

C2. After Hotfix is Merged​

The hotfix must also be added to develop to keep branches in sync:

  1. Switch to develop branch
  2. Pull latest changes
  3. Source Control → ... → Branch → Merge Branch
  4. Select main to merge into develop
  5. Push the develop branch

Scenario D: Working on Shared Scripts​

Use this workflow when: You need to modify a script in the shared/ folder that both teams use.

D1. Before You Start​

  1. Announce your intent: Post in the team Slack/Teams channel: "I'm going to modify [script name] for [reason]."
  2. Check for conflicts: Ask if anyone else is currently working on the same script.
  3. Minimize changes: Only modify what's necessary to reduce conflict risk.

D2. Development Process​

Follow the same process as Scenario A, but:

  • Pull from develop more frequently (at least daily)
  • Keep your feature branch short-lived (complete within 1-2 days if possible)
  • Your PR will require approval from both IT and Vendor team reviewers

Scenario E: Resolving Merge Conflicts​

When this happens: You try to merge or pull, and Git says there are conflicts because someone else changed the same code.

Don't panic!

Conflicts look scary but are easy to fix. VS Code highlights exactly what needs your attention.

E1. Understanding Conflict Markers​

When you open a conflicted file, you'll see something like:

<<<<<<< HEAD (Current Change)
var taxRate = 0.08;
=======
var taxRate = 0.10;
>>>>>>> develop (Incoming Change)
  • Current Change (HEAD): Your version of the code
  • Incoming Change: The other person's version

E2. Resolving the Conflict​

  1. VS Code shows buttons above the conflict. Click one:
    • Accept Current Change - keep your version
    • Accept Incoming Change - keep their version
    • Accept Both Changes - include both (you'll need to edit)
    • Or manually edit the file to combine changes correctly
  2. Delete the conflict markers (<<<<<<<, ======, >>>>>>>)
  3. Save the file
  4. Stage the resolved file (click + in Source Control)
  5. Commit with message like: Resolve merge conflict in [filename]
  6. Push your changes

Scenario F: Reviewing Someone's Code​

When this happens: You receive a notification that someone requested your review on a Pull Request.

F1. Review the Pull Request​

  1. Click the link in the email/notification to open the PR on GitHub
  2. Click the Files changed tab to see all modifications
  3. Review the code changes:
    • Green lines = added code
    • Red lines = removed code
  4. To comment on a specific line, hover over it and click the + button

F2. Submit Your Review​

  1. Click the Review changes button (green, top right)
  2. Choose one option:
    • Comment - just feedback, no approval
    • Approve - code looks good, ready to merge
    • Request changes - changes needed before approval
  3. Click Submit review

F3. What to Look For​

  • Does the code do what the ticket requires?
  • Are there any obvious bugs or logic errors?
  • Is error handling included?
  • Are there any hardcoded values that should be parameters?
  • Is the code readable and well-commented?
  • Could this change break existing functionality?