Learning evidence
A readable commit history, small branch, reviewable pull request and contribution record
LEARNING PATHWAY
Git, Open Source and Teamwork
Connects repositories, commits, branches, diffs, merges, issues, pull requests, licences and open-source contribution to real teamwork.
CENTRAL QUESTION
How can a team produce changes without loss, in a form that is understandable and reversible?
Completion evidence for this pathway is a readable commit history, small branch, reviewable pull request and contribution record. Page count or time spent alone does not demonstrate competence.
The intended capstone is a small open-source artefact developed by two people through an issue–branch–commit–review–merge cycle. It should connect the lessons in one artefact and retain failed tests as evidence.
Capstone
A small open-source artefact developed by two people through an issue–branch–commit–review–merge cycle
Return trigger
When adding a feature, fixing a bug, onboarding a teammate, choosing a licence or needing to restore a version.
LESSON MAP
12 items from concept to evidence
Code Review and Constructive Feedback
Lesson · Constructive review evaluates the change against purpose, tests, readability, safety and project rules while respecting the contributor. This lesson includ
Open page →Complete Git History Project
Project · This project develops a small application through a complete Git history that demonstrates planning, implementation, testing, review and recovery. This les
Open page →From File Versions to Git
Lesson · Git records a graph of project states and changes so learners can compare versions, explain decisions and recover without multiplying anonymous files. This
Open page →Issues, Tasks and Bug Reports
Lesson · A useful issue separates observed behaviour, reproduction steps, expected result, environment, evidence and acceptance conditions. This lesson includes a w
Open page →Merging Changes and Understanding Conflicts
Lesson · Merging combines histories, while a conflict asks a person to decide how overlapping changes should coexist. This lesson includes a worked example, practic
Open page →Open-Source Documentation Project
Project · This project prepares a small documentation contribution to an open-source project without claiming acceptance before maintainers review it. This lesson in
Open page →Open-Source Licences and Responsible Contribution
Lesson · Responsible open-source contribution requires licence awareness, project rules, respectful communication, scoped changes and verifiable authorship. This le
Open page →Repositories and the First Commit
Lesson · A repository begins with a clear boundary, useful structure, ignored generated files and an initial commit that establishes a reproducible starting point.
Open page →Undoing Changes and Recovering Versions
Lesson · Safe recovery depends on understanding whether the goal is to discard local edits, restore a file, create a reversing commit or move to an earlier state. T
Open page →Using Branches for Safe Experiments
Lesson · A branch creates an independent line of development for a focused experiment, feature or repair without destabilising the main tested line. This lesson inc
Open page →Writing Meaningful Commit Messages
Lesson · A meaningful commit message describes the change as an action and explains the reason or consequence when context is not obvious. This lesson includes a wo
Open page →Git and Open Source Quiz
Quiz · A 12-question interactive assessment for Git, Open Source and Teamwork, with explanations and a newly shuffled option order on every start. This lesson inc
Open page →FOUR-WEEK PLAN
Place lessons in a production cycle
No week closes with reading alone. Use one session for concept and example, a second for practice, and a short third session for testing and explanation. Do not accelerate when a prerequisite is missing.
| Week | Focus | Evidence to produce |
|---|---|---|
| 1 | Code Review and Constructive Feedback, Merging Changes and Understanding Conflicts, Undoing Changes and Recovering Versions | A readable commit history, small branch, reviewable pull request and contribution record |
| 2 | Complete Git History Project, Open-Source Documentation Project, Using Branches for Safe Experiments | A small open-source artefact developed by two people through an issue–branch–commit–review–merge cycle |
| 3 | From File Versions to Git, Open-Source Licences and Responsible Contribution, Writing Meaningful Commit Messages | Error log and second version |
| 4 | Issues, Tasks and Bug Reports, Repositories and the First Commit | Quiz result, misconception and next application |
COMMON TRAPS
They look fast but weaken learning
- Putting every change in one commit
- Missing the fetch–merge distinction behind pull
- Deleting conflict markers without reading them
- Assuming reuse permission without a licence
DEEPENING
Deepening evidence in Git, Open Source and Teamwork
The pathway's distinctive question is: How can a team produce changes without loss, in a form that is understandable and reversible? A first response may be a definition, but completion requires a readable commit history, small branch, reviewable pull request and contribution record. If input, method, limits and review date are unclear, the result is not traceable even when it looks strong.
Start with two different activities among Open-Source Licences and Responsible Contribution, Using Branches for Safe Experiments, Writing Meaningful Commit Messages, Code Review and Constructive Feedback. In one, explain the concept in your own words; in the other, perform an application, measurement or user test. The two activities should not close with the same type of evidence. This distinction shows that Git, Open Source and Teamwork has been tested through different forms of production.
Later connect Merging Changes and Understanding Conflicts, Open-Source Documentation Project, Complete Git History Project, Repositories and the First Commit to the capstone: A small open-source artefact developed by two people through an issue–branch–commit–review–merge cycle Keep failed tests as well as successful ones. For every error, record conditions, expected result, actual result, possible cause and the single change made.
Check these traps separately: Putting every change in one commit; Missing the fetch–merge distinction behind pull; Deleting conflict markers without reading them; Assuming reuse permission without a licence. Reading a trap is insufficient; find an example from your own work and state which evidence made the problem visible.
Return rule: When adding a feature, fixing a bug, onboarding a teammate, choosing a licence or needing to restore a version. Do not delete the previous record; add a date, changed tool or source, new evidence and the next mini trial. Progress is therefore tracked through the quality of explanation, application and correction—not the number of pages completed.
MICRO QUIZ
Test the reasoning behind the module
1. How can a team produce changes without loss, in a form that is understandable and reversible?
The answer must produce evidence, not only a definition: A readable commit history, small branch, reviewable pull request and contribution record.
2. What should happen to the first failed test?
Keep it with conditions, expected result, actual result and the correction.
3. Does reading a source prove that practice occurred?
No. Sources define method and limits; practice evidence must be produced separately.
4. When should the module be reopened?
When adding a feature, fixing a bug, onboarding a teammate, choosing a licence or needing to restore a version.
5. What does the capstone connect?
A small open-source artefact developed by two people through an issue–branch–commit–review–merge cycle
OFFICIAL / PRIMARY SOURCES
Verify technical detail in current sources
Git Reference
Primary or institutional source for method and technical limits.
Open source →Git tutorial
Primary or institutional source for method and technical limits.
Open source →Open Source Guides
Primary or institutional source for method and technical limits.
Open source →