Branches, pull requests, reviews and conflicts
Each change gets its own branch. When it is ready you push it and open a pull request, where colleagues review it and automated checks run before it is merged into main. If main has changed the same lines in the meantime, Git stops with a merge conflict, and you resolve it by understanding both changes.
A branch per change
A branch is a movable name for a line of commits. Create one per change from an up-to-date main, named the way your team agrees, for example feature/PAY-2231-overtime: git switch -c feature/PAY-2231-overtime (older guides: git checkout -b). Publish it the first time with git push -u origin feature/PAY-2231-overtime.
Pull requests
A pull request asks for your branch to be merged into another, usually main. It shows the commits and every changed line, collects comments, and shows the results of automated checks. You can open one on GitHub's website or with the GitHub CLI, for example gh pr create --base main --title "...".
| Review | What it says |
|---|---|
| Comment | General feedback, without approving or asking for changes |
| Approve | The changes are ready to merge |
| Request changes | Something must be fixed before this is merged |
A CODEOWNERS file can name the people or teams responsible for parts of the repository, for example the copybooks folder; GitHub then asks them for a review automatically when a pull request touches their files.
What to look for in a mainframe review
- JCL: the DISP of every DD (does a step that only reads a file use DISP=SHR?), data set names per environment, SPACE and generation numbers, COND or IF logic on new steps.
- Copybooks: who else copies it. A change to a field's PIC changes the record layout for every program that uses it, and the record length must still match the file.
- COBOL: numeric field sizes and signs, rounding, and file status handling on new I/O.
- A passing check proves only what the check tests. It does not prove the change is right.
Merge conflicts
If both branches changed different parts of a file, Git merges them for you. If both changed the same lines differently, it stops, writes conflict markers into the file and waits:
<<<<<<< HEAD 05 EMP-SALARY PIC S9(7)V99. ======= 05 EMP-SALARY PIC 9(9)V99. >>>>>>> main
- The part between
<<<<<<<and=======is your side (HEAD); the part between=======and>>>>>>>is the branch being merged in. The closing marker names what you merged:mainaftergit merge main, but the fetched commit's full id aftergit pull, because a pull merges that commit. Withmerge.conflictStyleset todiff3, Git also shows the original lines after a|||||||marker. - Decide what each side meant. Here one made the field signed and the other made it wider, so the answer is
PIC S9(9)V99: both. - Remove all marker lines, then check what the file means (here: the record length still matches).
git addthe file and finish withgit commit(orgit merge --continue). To give up and go back to before the merge,git merge --abort.
Getting main's latest work with git pull can stop before any merge starts: when your branch and the remote branch both have commits the other lacks, current Git asks you to choose how to bring them together, either a merge (git pull --no-rebase) or a rebase (git pull --rebase). This course and the Lab use merge, so git pull --no-rebase origin main and git merge origin/main do the same job here.
VS Code shows conflicts with inline actions and has a three-way merge editor, but the decision is still yours.
Fast-forward or merge commit
If main has not moved since your branch started, Git can simply move main forward to your last commit: a fast-forward, with no merge commit. If both have new commits, the merge creates a merge commit with two parents. --no-ff asks for a merge commit even when a fast-forward is possible, so the branch stays visible in the history.
Which command abandons a merge that stopped with conflicts and goes back to how things were?
Show a hint
git merge with an option.
Show the solution
git merge --abort.
Examples are for learning. Run commands and jobs only on a system you are authorised to use, such as a training or test system, and never on production without approval.
Common mistakes
Read both sides first. Often both changes are needed, as with a field made signed on one branch and wider on the other.
Checks test format and builds. Read the JCL and COBOL yourself: a check will not notice a DISP that deletes a production file.
Name the line, the effect and the fix, so the author can act on it straight away.
What you will see at work
- Pull requests are usually small: one ticket, one branch, a few files. Large ones get slow, shallow reviews.
- Copybook changes are often owned by a data or architecture team listed in CODEOWNERS, so they are asked to review automatically.
- When you resolve a conflict in code you do not own, ask its author. A short call beats a wrong guess that compiles.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.