INFO1111 Chap.9 Collaboration, Git and Version Control
Collaboration, Git and Version Control
This chapter covers the Week 4 collaboration lecture and the Week 5 tutorial in which teams set up their repositories and project boards. It starts with the research side of collaboration: where to find information, the six REVIEW criteria for judging a source, referencing, and the rules of academic integrity.
It then explains why professional collaboration needs traceability, accountability, security and version control, and how Git provides it through commits, staging, branches, merges and remote repositories. A worked session shows a branch, a merge conflict and its resolution.
The chapter explains forks and clones, the six-step forking workflow that ends in a pull request, and the project-management methods the lecture lists, with Kanban boards on GitHub. It connects all of this to the Skills Foundation assignment, where the tasks in your report must match the tasks recorded in the project GitHub.
What this chapter covers
- 01
Finding information and the REVIEW criteria
- 02
Referencing and academic integrity
- 03
Collaboration for students and for professionals
- 04
Why version control exists
- 05
Git's commits, staging, branches and remotes
- 06
Resolving a merge conflict
- 07
Forks, clones and pull requests
- 08
Kanban boards and matching tasks to your report
Worked example · free
Planning checking tasks on a project board
- +1Break the work into small, checkable tasks, one requirement per issue, each with its set-up, inputs and expected result.
- +1Assign by skill: give the new member a short learning task on the test tool first, linked as a dependency of their checking task.
- +1Balance the load so no member holds more than two checking issues, and order tasks by their dependencies.
- +1Make the board and the report match exactly: same tasks, same owners, same order.
Key terms
- Version Control
- A system that records changes to files over time so that earlier versions can be recovered and parallel work combined.
- Commit
- A saved snapshot of staged changes in a Git repository, with a message describing it.
- Branch
- A separate line of development in a repository that can later be merged back into the main line.
- Merge Conflict
- A stop in a merge when two branches changed the same lines, requiring a person to decide the result.
- Fork
- A personal server-side copy of someone else's repository, linked to the original so changes can be proposed back.
- Pull Request
- A proposal to merge changes from a branch or fork into another repository, reviewed by its maintainers.
- Kanban Board
- A board that shows tasks as cards moving through columns such as Backlog, In Progress and Done.
Collaboration, Git and Version Control FAQ
What does REVIEW stand for when judging a source?
Relevance, Expertise of the author, Viewpoint of the author or organisation, Intended audience, Evidence and When published. Each letter is a question to ask before you rely on the source.
What is the difference between a fork and a clone?
A fork is a copy of someone else's repository on the server under your account, linked so you can propose changes back. A clone is a copy on your own machine.
Why do merge conflicts happen?
Two branches changed the same lines in different ways, so Git cannot decide which change should win. You edit the file to the intended result, then stage and commit it.
What must my GitHub board contain for the Skills Foundation assignment?
The evaluation tasks from Part 4 of your report, allocated to group members, with sensible dependencies. The rubric checks that the board and the report match.
What counts as a breach of academic integrity in collaboration?
Copying or paraphrasing without acknowledgement, recycling your earlier published work, fabricating data, submitting someone else's work as your own, or knowingly helping another person to be dishonest.
Exam move
Practise Git on a scrap repository rather than reading about it: initialise, commit three times, branch, change the same line on both branches, merge and resolve the conflict, then check the result with the log. Do it twice until you can explain each command's effect on the four areas, working files, staging, local repository and remote. Learn REVIEW by applying it to two sources you are using in another unit.
For the group project, set up the board early, create one issue per task with an owner and a dependency, and update it whenever the plan changes, since the Advanced assignment asks you to document those changes. Before submitting the Skills Foundation report, place it beside the board and tick off every task in both directions.
Working through Collaboration, Git and Version Control in INFO1111? Sia is AskSia’s AI Computer Science tutor — ask any INFO1111 Collaboration, Git and Version Control question and get a clear, step-by-step explanation grounded in how INFO1111 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
