Programming 2: Team Workflow and Version Control

Lesson Overview

Coordinate a team artefact using issues, branches, commits, reviews and integration discipline.

Portfolio focus: Split a project into four issues.

ConceptTeam software engineering

Run fileTeamWorkflowVersionControlDemo.java

Baselinefeat: add mark validation

Evidence3 tasks

Starter: think before typing

Before running this team software engineering example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `feat: add mark validation`; predict how the focus line helps produce that evidence.

Learning Objectives

Use version control vocabulary accurately.
Plan tasks so team members can work safely.
Write useful commit messages.
Review code constructively.

Learning Outcomes

By the end of the lesson, you can use version control vocabulary accurately.
By the end of the lesson, you can plan tasks so team members can work safely.
By the end of the lesson, you can write useful commit messages.
By the end of the lesson, you can review code constructively.

Why this idea exists

Version control developed because software teams needed a reliable history of changes and a way to combine work without losing it. Modern workflows build review and integration around that history.

A commit is more than a save point. It is a small explanation of intent, evidence of progress and a recovery point if a change breaks something.

Degree-level team programming expects technical and social discipline: clear tasks, small branches, readable commits, respectful review and shared ownership of quality.

Deep dive

Mechanism in this example

The important mechanism is visible around `String commitType = "feat";`. Read it as a concrete move in the program, not as decorative syntax: identify what value, object, branch, call or boundary is being created at that point.

Design pressure

Degree-level team programming expects technical and social discipline: clear tasks, small branches, readable commits, respectful review and shared ownership of quality.

Failure mode to watch

For Team Workflow and Version Control, deliberately disturb the assumption behind `String commitType = "feat";`: use an awkward value, missing input, wrong order of calls or boundary case. The useful question is how that disturbance exposes a weakness in the team software engineering design.

Extension step

Extend the example by doing this: Create branch names for each issue. The point is to make one small change that forces you to revisit the concept, rather than adding unrelated features.

Portfolio standard

The portfolio note should not repeat the lesson wording. It should show the edited code, the run result, and your own explanation of this evidence: review one peer change using evidence.

Lesson visual

Photo of a team kanban board with branch labels, commit notes, pull request review and green test status.Download visual

Type this and run it

Create TeamWorkflowVersionControlDemo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.

public class TeamWorkflowVersionControlDemo {
  public static void main(String[] args) {
    String commitType = "feat";
    String message = "add mark validation";
    System.out.println(commitType + ": " + message);
  }
}

Build and run it with:

javac TeamWorkflowVersionControlDemo.java && java TeamWorkflowVersionControlDemo

Expected baseline: feat: add mark validation

Run the code in your browser

Use the editor as an experiment surface. First run the checked version, then make one small change to the part of the program that demonstrates team software engineering and compare the new behaviour with the reference output.

Editable Java code

public class TeamWorkflowVersionControlDemo {
  public static void main(String[] args) {
    String commitType = "feat";
    String message = "add mark validation";
    System.out.println(commitType + ": " + message);
  }
}

feat: add mark validation

Line-by-line explanation

Read the code as a sequence of responsibilities. The focus line for this lesson is String commitType = "feat";; the surrounding lines prepare it, use its result or make the behaviour observable.

public class TeamWorkflowVersionControlDemo {

This names the runnable class for the Team Workflow and Version Control example, giving the compiler and JVM one clear unit to build.

public static void main(String[] args) {

This is the program entry point. In Team Workflow and Version Control, it keeps the demonstration of team software engineering in one traceable starting script.

String commitType = "feat";

This introduces commitType as named state for Team Workflow and Version Control. Later lines can read, update, pass or print that specific value as evidence.

String message = "add mark validation";

This introduces message as named state for Team Workflow and Version Control. Later lines can read, update, pass or print that specific value as evidence.

System.out.println(commitType + ": " + message);

This prints commitType + ": " + message as the observable evidence for Team Workflow and Version Control. The output lets the learner check whether the team software engineering idea behaved as predicted.

}

This closes the innermost Team Workflow and Version Control block, so the immediately preceding method, branch or loop has finished.

}

This closes the outer Team Workflow and Version Control structure, returning the reader to the surrounding class or file.

Worked example

From code to explanation

Problem: Use Team Workflow and Version Control to complete a small portfolio-quality step: Split a project into four issues.

Method: Locate the line `String commitType = "feat";`, explain the exact role it plays, then decide what you would change to extend the example without changing the whole program.

Reveal worked answer

The checked run should produce `feat: add mark validation`. A strong answer links the result back to team software engineering: what was created, selected, stored, called or protected, and why that matters for the portfolio task.

Trace the program

Before: Before the key operation, identify the relevant value, object, branch or resource that the team software engineering concept depends on.

During: Trace `String commitType = "feat";` as the Team Workflow and Version Control example executes. Say whether that operation creates data, checks a condition, calls behaviour, stores information or crosses a boundary.

After: Compare the run with the expected evidence: `feat: add mark validation`.

Change: Now create branch names for each issue, run again, and explain the smallest reason the behaviour changed.

Common misconception

A common mistake in team workflow and version control is treating the example as a finished answer. For team software engineering, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?

Quick checks

1. In this Team Workflow and Version Control example, what is the best reason to focus on `String commitType = "feat";`?

It is where the code demonstrates team software engineering in a concrete way.It is the only line where punctuation matters.It can be ignored as long as the final page looks correct.

2. Which evidence is strongest after you edit and rerun this example?

Only a screenshot of the page after pressing Run.The edited code, the run result `feat: add mark validation` or changed output, and a short explanation of the decision.Only the final answer, with failed attempts removed.

How to study this lesson

For Team Workflow and Version Control, predict how team software engineering changes the run before you press Run.

Use the first portfolio task as your main edit: Split a project into four issues.

Use the second task as your variation: Create branch names for each issue.

Finish with evidence, not a diary entry: Review one peer change using evidence.

Portfolio Practice

Split a project into four issues.
Create branch names for each issue.
Review one peer change using evidence.

Final self-check

Can you explain the key operation?

Explain the line identified in the quick check in one or two sentences. Your answer should say what it does before the output feat: add mark validation appears.

Can you justify the portfolio evidence?

Your evidence should include the original run, one edited run, and a short note explaining how the edit affected team software engineering.

Study route

Practise team software engineering by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.

Next, move into Specialism Mini-Project and carry forward one improvement from this lesson into the next program.