Source control: from PDS members to Git
Git stores every version of every file and lets many people work in parallel on branches. Moving mainframe source into Git means turning members into files, sorting out character encoding, and deciding how branches line up with your environments.
Members become files
A COBOL program that lived as member PAYCALC in DEV.COBOL becomes a file such as cobol/PAYCALC.cbl in a repository. Copybooks, JCL and PROCs become files in their own folders. The repository is the single source of truth; the PDS libraries on z/OS are rebuilt from it.
Encoding: the step everyone trips on
Mainframe source is stored in EBCDIC; Git on a workstation works in UTF-8. Git for z/OS can convert automatically, but you have to tell it which files to convert and to which code page. That is done in a file called .gitattributes.
# convert text source to EBCDIC (IBM-1047) when checked out on z/OS *.cbl zos-working-tree-encoding=ibm-1047 git-encoding=utf-8 *.cpy zos-working-tree-encoding=ibm-1047 git-encoding=utf-8 *.jcl zos-working-tree-encoding=ibm-1047 git-encoding=utf-8 # never convert binaries *.bin binary
Branches and environments
A simple, common model: each developer works on a feature branch; a pull request merges it into a shared develop branch that deploys to test; a release branch or tag deploys to QA and production. The exact model matters less than everyone following the same one.
$ git clone https://git.example.com/pay/payroll.git $ git switch -c feature/PAY-142-overtime-rate # ...edit cobol/PAYCALC.cbl in your IDE... $ git add cobol/PAYCALC.cbl $ git commit -m "PAY-142 apply new overtime rate" $ git push -u origin feature/PAY-142-overtime-rate
Pushing the branch is what triggers the pipeline. The pull request then shows the code change, the build result and the test results in one place for review.
Common mistakes
Files arrive on z/OS as unreadable bytes or with corrupted special characters. Set up encoding rules before the first real commit.
If people still edit members directly on z/OS, the repository and the libraries drift apart. Make Git the only place source is changed.
A branch that lives for months is a big-bang release in disguise. Merge small changes often.
What you will see at work
- Migrations from Endevor or ChangeMan to Git are big projects; history is often brought across only for active code.
- You will edit in a modern IDE such as VS Code with Z Open Editor, or IBM Developer for z/OS, rather than ISPF — but ISPF skills remain useful for looking at what is actually deployed.
- Ticket numbers in branch names and commit messages, such as PAY-142, are how auditors trace a production change back to its request.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.