PowerBuilder and Git: Source Control That Works

PowerBuilder has spoken Git natively since 2017 R2, and since PowerBuilder 2025 it is genuinely good. Everything below follows from one fact: a .PBL is a binary library, so Git can't diff or merge it. The whole workflow is about making Git version the exported source objects instead. Here is the working 2026 setup — as a reference, not a longread.

What changed — most horror stories predate PB 2025

If you last tried Git with PowerBuilder years ago, the calculus has changed twice: 2022 stopped you committing binary PBLs, and 2025 made the source itself merge-friendly.

The 2026 setup

1. Commit source, ignore binaries

Ready-to-paste .gitignore for the PB 2025 Solution format:

# Compiled output & machine code — never commit
*.pbd
*.exe
*.dll
.pb/
build/
_BackupFiles/
_UpgradeFiles/

# Per-user IDE state
*.user.opt

Pre-2025 (Workspace model): the .pbl is a binary file, not a folder — add *.pbl to the list above and commit the ws_objects/ source directory instead. On Get, tick “generate PBLs from source” so no binary is ever needed in the repo.

2. Know the sync cycle (this is where changes “vanish”)

3. Branch without the DataWindow merge hell

• Short-lived feature branches. Objects are coarse (a whole window/DataWindow is one file), so long parallel branches on popular objects guarantee conflicts.
• Git has no per-object lock. Enforce one editor per DataWindow by coordination — a claim list where people mark what they're editing.
• Drive branch / switch / merge from the IDE, then Refresh after every switch and Git Pull the target before merging.
• On PB 2025 R2, prefer Rebase for a linear history without Pull's extra merge commit.

4. Resolve conflicts safely

1. Conflicted object shows a ! in the tree → right-click → Edit Conflicts (with Compare / Show Log).
2. Resolve, then confirm the object compiles — a bad merge of an .srd/.srw can crash the IDE.
3. After a multi-object merge, run a full build / 3-pass regenerate so cross-references recompile.
4. .pbg out of sync? Open it as text, add the missing object entries, then Refresh.

5. Build in CI — no IDE, no license on the agent

PBAutoBuild is the modern path: it pulls from Git, regenerates PBLs and builds/deploys from a JSON config you export from the IDE — on a bare agent.

:: encrypt the Git password once
pbautobuild250.exe /p yourGitPassword

:: build + deploy from a JSON config exported by the IDE
pbautobuild250.exe /f build\app.json /l deploy.log /le error.log

Appeon ships a working reference (the PowerBuilder-AutoBuild-Sales-Example repo). On older stacks the classic chain still works: OrcaScript with importonly + refresh target 3pass to build the PBLs from source, then PBC to produce the EXE.

6. Onboard the right way

Use the IDE's “Connect to Workspace”, never a plain git clone. PowerBuilder stores the repo binding in the Windows registry keyed to the workspace path — a raw clone, a copied folder, or moving the folder later all silently disable Git integration. Same reason CI agents need OrcaScript/PBAutoBuild, not a clone-and-build.

What Git still won't do (be honest about it)

• No per-object lock in Git— for a handful of hot, constantly-edited DataWindows, SVN's exclusive lock can prevent more pain than Git's branching saves. Both are native, so it's a real choice.
• The IDE is not a full Git client. Repo browsing, rich logs and some merges still send you to TortoiseGit alongside it.
• Moving to the 2025 Solution format can cost Git history. The on-disk restructure often means a fresh repo — decide up front whether to keep messy same-repo history or start clean.

Bottom line. Target PowerBuilder 2025 / 2025 R2 with the Solution format, commit the exported source (not the PBL), coordinate DataWindow edits because Git can't lock, and build in CI with PBAutoBuild. Do that and PowerBuilder under Git is a normal, boring, working setup — which is exactly what you want from source control.