Skip to content
Computer Science · 9th Grade

Active learning ideas

Collaborative Code Sharing

Active learning works well for collaborative coding because version control disciplines like pull requests and code review are inherently social. Students need to practice coordinating edits, explaining decisions, and resolving feedback in real time to understand how distributed teams ship reliable software.

Common Core State StandardsCSTA: 3A-AP-22
20–45 minPairs → Whole Class4 activities

Activity 01

Collaborative Problem-Solving45 min · Small Groups

Collaborative Lab: Shared Repository Workflow

Groups of three share a repository. Each student is assigned to edit a different function in the same file, commit their changes, and push to a shared remote. The group then pulls all changes and discusses what happened when edits overlapped, practicing the sequence of pull-before-push as a coordination habit.

Explain how sharing code effectively contributes to a team project.

Facilitation TipDuring the Collaborative Lab, walk the room with a live repo projected on the board so students see branches and merges in real time.

What to look forPresent students with a scenario: Two students worked on separate features, then tried to merge their code. One student's changes overwrote the other's. Ask students to identify the likely cause (e.g., no branching, no pull request) and suggest one step they could have taken to prevent this.

ApplyAnalyzeEvaluateCreateRelationship SkillsDecision-MakingSelf-Management
Generate Complete Lesson

Activity 02

Think-Pair-Share20 min · Pairs

Think-Pair-Share: What Makes a Good Pull Request?

Show students two pull request descriptions for the same code change -- one vague ('fixed bug'), one specific ('fixed null pointer exception in login when username field is empty'). Partners discuss which is more useful and why. Class builds a list of criteria for effective pull request descriptions.

Design a process for team members to contribute code to a shared repository.

Facilitation TipIn the Think-Pair-Share, prompt pairs to compare a vague commit message with a concrete one before sharing with the whole class.

What to look forStudents work in pairs on a small coding task, each making separate commits. After completing their individual work, they must create a pull request for their partner to review. The reviewer checks for: clear commit messages, logical code structure, and adherence to project requirements, providing written feedback on the pull request.

UnderstandApplyAnalyzeSelf-AwarenessRelationship Skills
Generate Complete Lesson

Activity 03

Round Robin40 min · Pairs

Code Review Round Robin

Each student submits a short code snippet (10-15 lines) to a shared folder. Students rotate to review a peer's code, leaving at least one positive observation and one specific suggestion for improvement as comments. After two rounds, students revise their code based on feedback received.

Analyze the benefits of using version control for tracking individual contributions.

Facilitation TipFor the Code Review Round Robin, provide a single PR template so reviewers focus on structure rather than format.

What to look forAsk students to write down three key benefits of using version control for team projects. Then, have them describe one potential challenge they might face when merging code from a teammate and how they would address it.

RememberUnderstandAnalyzeRelationship SkillsSelf-Management
Generate Complete Lesson

Activity 04

Gallery Walk25 min · Small Groups

Gallery Walk: Contribution Tracking

Display a repository's git log history (anonymized) on four poster sheets. Groups analyze the commit history and answer: Who contributed most? Are commit messages clear? Can you tell what the project does from the history? Groups report their analysis and class discusses what a healthy contribution history looks like.

Explain how sharing code effectively contributes to a team project.

What to look forPresent students with a scenario: Two students worked on separate features, then tried to merge their code. One student's changes overwrote the other's. Ask students to identify the likely cause (e.g., no branching, no pull request) and suggest one step they could have taken to prevent this.

UnderstandApplyAnalyzeCreateRelationship SkillsSocial Awareness
Generate Complete Lesson

A few notes on teaching this unit

Teachers should avoid live-coding the entire PR workflow; instead, narrate each step while students perform it on their own machines. Emphasize that good version control is a habit, not a one-time lesson. Research shows that students benefit from seeing both successful and failed merges, so deliberately seed minor conflicts to build diagnostic confidence.

Students will demonstrate the ability to fork a branch, make focused commits, open a pull request, review peers’ work, and merge changes without losing contributions. They will articulate why clear commit messages, small PRs, and constructive reviews matter in professional workflows.


Watch Out for These Misconceptions

  • During the Collaborative Lab: Shared Repository Workflow, watch for students who try to push directly to main or who create only one branch for the whole team.

    Use the lab’s step-by-step checklist to redirect teams: insist on branching from main, making small commits, and opening PRs before merging. Show them how a shared branch without PRs can overwrite work.

  • During the Think-Pair-Share: What Makes a Good Pull Request?, watch for students who believe a PR’s only purpose is to fix errors.

    Use the provided PR rubric during the pair discussion: require reviewers to note at least one positive observation about code readability or design, not just bugs. Bring examples of PRs that improved maintainability.

  • During the Gallery Walk: Contribution Tracking, watch for students who assume any overlap in a file will cause a conflict.

    During the walk, point to specific commits that edited separate lines in the same file and show the clean merge output. Ask students to predict when Git will auto-merge versus when it will flag a conflict line.


Methods used in this brief