DoAssignment study guide

B1.7 · Manage shared source code and versions safely

Learn to manage shared source code and versions safely through clear examples and targeted practice.

Ontario Grade 12 Computer Science

Software Development

A practical Grade 12 guide to coordinating changes, preserving working copies, and identifying reliable versions

When several people work on the same program, a useful change can be lost or another person’s work can be overwritten. A version is a saved state of the source code. Managing versions safely means making it possible to tell which state is current, who changed it, and how to return to a known-good state if needed. In this lesson, “safe” means protecting the team’s source code from accidental loss, confusion, or unreviewed changes; it does not mean that a version-control tool guarantees that a program is correct.

What you will learn

Explain why a team needs an agreed way to share source code and keep track of versions.
Use a simple, safe workflow for making, reviewing, and combining changes.
Choose clear version labels and preserve a known-good copy.
Respond safely when changes conflict or a mistake is discovered.

1. Start with a shared plan

From ICS3U, you already know that source code is the written set of instructions that a programmer creates and changes. In a team, the challenge is not only to write code: people also need to coordinate which copy they are changing and how their changes reach the shared project.

Before work begins, agree on one shared location for the project, who may make changes, how changes will be identified, and who will review them. A version-control tool can record saved versions and help team members share changes. A shared folder can also be used, but the team must take particular care not to replace another person’s file without checking.

Keep the project’s original files in the agreed shared location. Before changing a file, make sure you have the latest team version. Work on a clearly identified change, then save it as a new version rather than disguising it as the old one. The team should be able to find the previous state if the new one causes trouble.

A version record is useful when it answers three practical questions: what changed, who made the change, and when it was saved. Write descriptions that distinguish changes, such as “Add input check to registration form,” rather than vague labels such as “Update.”

Agree on the shared location and team process before editing.
Identify the version being changed and keep earlier saved states available.
Use specific descriptions so team members can understand the history.

2. Make changes in a controlled way

A safe team workflow separates a person’s proposed change from the shared version that everyone relies on. A contributor first checks that they are working from the current shared code. They make a focused change, inspect what they changed, and explain it to the team. The change is then reviewed and added to the shared version according to the team’s agreed process.

Keep each proposed change focused. For example, if you are correcting a message shown to the user, avoid also renaming unrelated files in the same change. A focused change is easier for another person to review, and a problem is easier to trace back to its source.

When a tool reports that two people changed the same part of a file, treat this as a conflict to resolve, not as permission to accept either copy without checking. Compare both changes with the intended program behaviour. Ask the contributors for context if needed, agree on the correct combined result, and review the resolved file before saving it as the shared version.

Do not treat a saved version as proof that the program works. Review the code and follow the project’s usual checks before relying on a change. Do not replace a known-good shared version with an unreviewed edit merely to make the newest version appear complete.

Start from the current shared version and make a focused change.
Review proposed changes before they become the team’s shared version.
Resolve conflicts by comparing intent and code, not by choosing blindly.

3. Name, preserve, and restore versions

Version labels and descriptions help people recognize saved states. If the tool supplies version history, use it to see earlier changes and their descriptions. If the team is using copies in a shared folder, choose a consistent naming pattern that identifies the project, the version, and, where useful, the date or contributor. Avoid names such as “final,” “final2,” and “reallyfinal,” which do not reliably show which copy is current.

Keep a known-good version identifiable. Before a substantial change, confirm that the current shared version is saved and that the team can find it. Preserve the source code in the agreed location and do not make an unrelated cleanup that removes earlier versions or useful records.

If a change introduces a problem, stop adding further changes that depend on it. Identify the last known-good version, compare it with the problem version, and agree whether to correct the new version or restore the earlier code. Tell the team what was done so members do not continue from different copies.

Access should match the project’s needs. Share the project with the intended team members, and avoid sending source files through informal channels when doing so could create competing copies. A team should know which location is authoritative and how to report a change made outside it.

Choose labels and descriptions that make versions distinguishable.
Know where the last known-good version is kept.
When a problem appears, coordinate before editing or restoring another copy.

4. A repeatable team routine

A simple routine reduces avoidable confusion: check the shared version; make one focused change; inspect and describe it; ask for review; then add the agreed change to the shared version. Afterward, make sure the team knows that the shared version has changed. If the team’s chosen tool uses different names for these actions, follow the tool’s instructions while keeping the same purpose: protect the shared work and make changes understandable.

The routine depends on communication as well as tools. Tell collaborators when you plan to change a shared file, especially if your work overlaps with theirs. If you discover that your local copy is behind, do not silently replace the shared file with it. First compare what has changed and coordinate how to combine the work.

For practice, use a small, non-critical project copy and follow the team’s stated process. A practice copy is for learning the workflow; it should not be mistaken for the team’s authoritative source. The short scenarios below show how to choose sensible actions without relying on any particular software.

Use a consistent routine from checking the current copy through notifying the team.
Communicate before overlapping edits and when the shared version changes.
Keep practice copies distinct from the authoritative project.

Worked example

Two contributors edit the same file

Mina changes a program’s welcome message. At the same time, Omar updates a nearby input instruction in his own copy. Their shared tool indicates that both edits affect the same file. What should they do?

Pause before replacing anything
Neither contributor should overwrite the other’s work. The notice means that their changes may need to be combined carefully.
Compare the intended changes
Mina and Omar review the changed text and explain what each edit is meant to accomplish. They check that both intended improvements can be retained without making the instructions confusing.
Agree, review, and save
They agree on the combined wording, inspect the resulting file, and save it through the team’s normal review process with a clear description. The team is told which version is now shared.

Answer: They coordinate, compare the edits, agree on the combined result, review it, and save it as the shared version. They do not accept one copy blindly.

Check: The response protects both contributions while ensuring the shared copy has an agreed, reviewed result.

Worked example

Choose a useful version description

A team has just saved a change that checks whether a user entered a name. Which description is more useful: “Update” or “Check that a name was entered”? Explain why.

Compare what each description tells a reader
“Update” does not identify the purpose of the saved change. “Check that a name was entered” tells a teammate what was changed without requiring them to open the file first.
Use the specific description
The team saves the version with the specific description. If later work causes a problem, this record gives a clearer clue about which change to inspect.

Answer: “Check that a name was entered” is more useful because it identifies the change’s purpose.

Check: A descriptive record helps teammates understand the version history; it does not by itself prove the change works.

Worked example

Recover after a harmful change

After a new change is shared, the team notices that a previously working part of the program is no longer present. They can identify an earlier version that contained it. What is a safe next step?

Stop dependent edits
The team pauses changes that rely on the problem version, reducing the chance that more work will have to be repeated.
Compare with the known-good version
The team identifies the missing part and reviews the differences between the earlier known-good version and the current one. They decide whether to correct the current version or restore the earlier code and reapply appropriate changes.
Coordinate the recovery
After review, the team saves the agreed result using its normal process and informs everyone which version to use. Contributors check that they are continuing from that same shared version.

Answer: Pause dependent work, compare the current and known-good versions, agree on a correction or restoration, review the result, and tell the team which version is authoritative.

Check: The earlier version is a recovery point, not a reason to restore without checking whether later useful changes must be retained.

Common mistakes and how to avoid them

Editing an old local copy and replacing the shared file without checking.

Correction: Check that your copy is current. Compare changes and coordinate before updating the shared version.

Using vague labels such as “final” or “update.”

Correction: Describe the purpose of the change so teammates can distinguish and understand saved versions.

Accepting a conflict result without reviewing it.

Correction: Compare the contributors’ intended changes, agree on the combined result, and inspect it before saving.

Assuming that a saved or reviewed version must be correct.

Correction: Version history helps track and recover changes; it does not replace appropriate review and project checks.

Lesson summary

Agree on one authoritative shared location and a team process before editing.
Work from the current version, make focused changes, and describe them clearly.
Review changes and resolve conflicts with the contributors rather than overwriting blindly.
Keep a known-good version available and coordinate recovery so everyone continues from the same source.

Check your understanding

Question 1

Your copy may be older than the shared project. What should you do before saving your changes over the shared file?

Replace the shared file quickly so your work is not lost.
Check the shared version, compare changes, and coordinate how to combine them.
Rename your copy “final” and ask everyone to use it.
Delete the shared file so the team has only one copy.

Show answer and explanation

Check the shared version, compare changes, and coordinate how to combine them.

Checking and comparing first protects other contributors’ work and helps the team agree on the current version.

Question 2

Which version description is most informative?

Changed stuff
Version
Add check for an empty username
Final, probably

Show answer and explanation

Add check for an empty username

It identifies the purpose of the change, making the saved version easier to recognize.

Question 3

A conflict appears because two contributors changed the same file. What is the best response?

Accept the first change shown without reading it.
Ask one contributor to delete their work immediately.
Compare the intended changes, agree on a result, and review the file.
Save both files with identical names in the shared location.

Show answer and explanation

Compare the intended changes, agree on a result, and review the file.

A conflict requires careful comparison and an agreed, reviewed resolution; blindly choosing or duplicating files does not establish a reliable shared version.

Question 4

What does a known-good earlier version provide?

Proof that every later change is correct.
A reference point that can help the team investigate or recover from a problem.
Permission to ignore current collaborators’ changes.
A guarantee that no source code can be lost.

Show answer and explanation

A reference point that can help the team investigate or recover from a problem.

An earlier working state can support recovery, but the team still needs to check which later changes should be kept.

Key terms

Source code: The written instructions that make up a computer program.
Version: A saved state of a project’s source code.
Version history: A record of saved versions and, when recorded, who made changes and what they changed.
Conflict: A situation in which changes from different copies need to be compared and resolved before creating a reliable shared version.
Known-good version: A saved state that the team identifies as a useful working reference or recovery point.

Continue through ICS4U

View the complete ICS4U Ontario Grade 12 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 12 Computer Science (ICS4U), expectation B1.7. It is a study resource, not an official curriculum publication.

Before publication, content is checked for structure, mathematical or chemical notation, calculations, course boundaries, and readability. Errors can still occur, so corrections are welcomed.

Official curriculum reference

Report a correction or ask a question