Version Control GitHub Collaboration Branching Workflow

Week 3 Reading

Version Control & Team Collaboration

Study how Git tracks history, how GitHub supports remote teamwork, and how branching, merging, and collaboration workflows keep team projects organized.

Explore Topics Open Presentation
Topics4Core collaboration concepts
Objectives12Learning goals across the week
Review Prompts8Questions for revision
Workflow Stages4Plan, branch, review, merge

Week 3 Content

Version control, remote collaboration, and team workflow

Each topic combines objectives, discussion notes, a diagram, an applied example, and review questions so the book can support reading and teaching.

Git, GitHub, branching, workflow
Topic 3.1 3 deep dives 2 review questions

Git Basics

Git is a distributed version control system that tracks changes to files, records history, and lets teams move safely between versions while they develop software.

Topic Build
Objectives3
Deep dives3
Review prompts2
Learning Objectives
  • Explain why version control is essential in software development.
  • Describe commits, repositories, branches, and the working tree.
  • Use Git to save progress and revisit earlier states safely.
Discussion Notes
01

Version control keeps a complete history of a project, so you can see what changed, when it changed, and who changed it.

02

A repository stores the project history, while the working tree is the current editable copy on your computer.

03

Commits are snapshots of progress. Good commit messages make the history easier to understand later.

04

Git is distributed, so every developer can keep a full copy of the repository history on their own machine.

Team Insights

A change normally moves from the working tree to the staging area and then into a commit. That flow gives developers a chance to review what will be saved before the history is recorded.

Git makes experiments safer because you can create a branch, test an idea, and keep the original work untouched. If something fails, you can recover without losing the entire project.

Small commits with clear messages are easier to review than large commits that combine many unrelated edits. A clean history also makes debugging and collaboration much easier.
Workflow Diagram Click to zoom
Git History Flow Working TreeEdit files StagingPrepare commit CommitSave snapshot
Applied Example

A student updates a project layout, tests the changes, and commits the improvement with a message such as "Refine homepage layout". Later, the history can show exactly when the redesign happened.

Review Questions
  1. What is the difference between the working tree and the repository history?
  2. Why are small commits easier to manage than large ones?
Key Takeaways
  • Git records project history as commits.
  • A repository is a full versioned copy of the project.
  • Clear commit history makes future work easier.
Topic 3.2 3 deep dives 2 review questions

GitHub for Remote Collaboration

GitHub extends Git with remote hosting, pull requests, issue tracking, code review, and shared project visibility for distributed teams.

Topic Build
Objectives3
Deep dives3
Review prompts2
Learning Objectives
  • Explain how GitHub supports teamwork beyond a local repository.
  • Describe the purpose of remotes, pushes, pulls, and pull requests.
  • Recognize how GitHub helps teams review and discuss changes.
Discussion Notes
01

A remote repository is a shared copy of the project stored on a server such as GitHub.

02

Developers push changes to share their work and pull updates from the shared branch to stay synchronized.

03

Pull requests give teams a place to review code, discuss changes, and record approval before merging.

04

Issues, discussions, and project boards help teams organize tasks and track progress together.

Team Insights

The remote copy becomes the collaboration point for the team. Developers can work on their own machines, then publish their changes when they are ready for review.

GitHub pull requests are important because they turn code into a discussion. Reviewers can comment on the design, suggest changes, and confirm that the update fits the project goals.

GitHub also makes work visible. Branch names, review status, and issue links help the team understand what is being built and what still needs attention.
Workflow Diagram Click to zoom
Remote Collaboration Local RepoBranch workCommit locally GitHubPull requestReview and discuss TeamApprove changesMerge safely
Applied Example

One student fixes a form validation bug on a feature branch, pushes it to GitHub, and opens a pull request. Another student reviews the change and suggests a cleaner error message before merge.

Review Questions
  1. Why do teams use a remote repository instead of sharing files manually?
  2. What is the purpose of a pull request?
Key Takeaways
  • GitHub hosts shared code and collaboration tools.
  • Push and pull keep the remote and local copies aligned.
  • Pull requests create a review step before merge.
Topic 3.3 3 deep dives 2 review questions

Branching and Merging

Branching lets developers work on changes independently, while merging brings the work back together after it has been reviewed and tested.

Topic Build
Objectives3
Deep dives3
Review prompts2
Learning Objectives
  • Describe why branches are used for feature work and experimentation.
  • Explain how merges combine separate lines of history.
  • Recognize merge conflicts and the need for careful coordination.
Discussion Notes
01

A branch is a separate line of development. It lets you make changes without disturbing the stable version of the project.

02

Feature branches, bugfix branches, and release branches are common ways to organize work in a team.

03

Merging combines the branch back into the main line after the work has been validated.

04

If two people change the same part of a file, Git may raise a merge conflict that must be resolved manually.

Team Insights

A branch strategy should match the team size and release process. Small teams may keep it simple, while larger teams may prefer feature branches and protected main branches.

A conflict is not a failure of Git; it is Git asking humans to decide how the overlapping changes should be combined. Good communication reduces the chance of hard conflicts.

Short-lived branches are easier to merge because they stay close to the current main branch. Long-running branches often drift and become harder to integrate.
Workflow Diagram Click to zoom
Branch and Merge Main Branch A Branch B Merge
Applied Example

A class project uses a branch for the login page, another branch for the dashboard, and then merges both after review. If both branches edit the navigation bar, the team resolves the conflict before final merge.

Review Questions
  1. Why is branching safer than editing the main branch directly?
  2. What causes a merge conflict?
Key Takeaways
  • Branches isolate work in progress.
  • Merging brings separate changes together.
  • Conflicts require human review and resolution.
Topic 3.4 3 deep dives 2 review questions

Team Collaboration Workflow

A team workflow combines planning, branching, review, testing, and merge decisions so that collaboration stays organized and predictable.

Topic Build
Objectives3
Deep dives3
Review prompts2
Learning Objectives
  • Describe a practical Git workflow for a team project.
  • Explain how review, testing, and feedback fit into collaboration.
  • Understand how disciplined workflow reduces mistakes and confusion.
Discussion Notes
01

A strong team workflow usually begins with planning the task and creating a branch for the change.

02

After the code is written, the developer pushes the branch, opens a pull request, and asks for review.

03

Reviewers check correctness, style, readability, and whether the change matches the task requirements.

04

Once the change is approved and tested, it is merged and the branch is cleaned up to keep the repository tidy.

Team Insights

The best workflow starts before the first line of code is written. If the task is clarified early, the team avoids rework and conflicting assumptions.

A pull request should not only check whether the code works, but whether the code is understandable and safe to maintain later. Tests and review protect the shared branch from avoidable problems.

Teams move faster when everyone follows the same branch and review rules. Clear conventions reduce merge mistakes, duplicated work, and accidental overwrites.
Workflow Diagram Click to zoom
Team Workflow PlanAgree task BranchCreate work ReviewComment, test MergeDone
Applied Example

In a group assignment, each student takes one feature branch, submits a pull request, and receives review feedback before merge. The shared repository then stays organized and easy to audit.

Review Questions
  1. What steps make a team workflow reliable?
  2. Why should a pull request include review and testing?
Key Takeaways
  • A good workflow starts with planning and branching.
  • Review and testing should happen before merge.
  • Team conventions make collaboration smoother.
6 questions True / False Auto-marked

Week 3 Quiz

Answer each statement, submit the quiz, and review the score with the correct answers shown underneath.

Quiz Rules
Total items6
Pass mark70%
GradingInstant

Enter your Name and Matric No, then press Start Quiz to begin the attempt.

The quiz stays hidden until you start it, just like Quiz 1.

Press Start Quiz to open the questions and begin the attempt.