FIT2109 Chap.5 Git Collaboration and History
Git Collaboration and History
Git Collaboration and History adds movable branch labels, fixed release tags and multiple lines of ancestry to the snapshot model. The graph is formed by parent links between commits. A true merge has two parents and records the integration of diverged lines.
A fast-forward creates no integrating commit because the receiving branch can move along an existing ancestry.
Collaboration makes this graph useful evidence. A focused branch, logical commits, review discussion and a tested merge show how work was developed and integrated. Conflict markers only identify overlapping text.
The correct resolution must preserve the intended behaviour from both sides and be verified with relevant tests.
What this chapter covers
- 01
Branches as movable labels for continuing work
- 02
HEAD as the checked-out position through a branch or commit
- 03
Tags as labels that remain on selected snapshots
- 04
Common ancestors and the point where histories diverge
- 05
True merges identified by two parent commits
- 06
Fast-forward updates along one existing ancestry
- 07
Merge requests as reviewable proposals with evidence
- 08
Semantic conflict resolution followed by regression tests
Worked example · free
Classify a two-parent integration
- +1Identify r1 as the shared commit before the two lines diverged.
- +1Trace main to r2 and the feature line to f1.
- +1Observe that neither tip is an ancestor of the other.
- +1Count two parents on m1 and classify it as a true merge.
- +1Explain that the merge preserves both lines and may contain integration decisions.
- +1Explain that a fast-forward would move a label along one ancestry without a two-parent commit.
Key terms
- Branch
- A movable name pointing to a commit and normally advancing as new commits are created on that line of work.
- HEAD
- The checked-out Git position, commonly through the current branch. It does not mean the newest commit in every branch.
- Tag
- A label attached to a selected commit, often for a release. It does not automatically move when a branch advances.
- Common ancestor
- A commit reachable from both histories before their later paths diverge. It anchors comparison and merge reasoning.
- True merge
- A commit with two parents that joins diverged histories and records the integrated snapshot.
- Fast-forward
- An update where a branch label moves along an existing ancestry because there is no independent target-branch work to merge.
- Merge request
- A reviewable proposal to integrate one branch into another, supported by commits, a diff, tests and discussion.
Git Collaboration and History FAQ
How do I identify where two branches diverged?
Follow parent links backward from both tips until the histories meet. The shared commit before each line gains different descendants is their common ancestor for the scenario.
How can I prove a merge is a true merge?
Inspect the integrating commit's parents. Two parents show that it joins two histories. A bent graph alone is not proof because display tools can draw the same ancestry in different ways.
Does a release tag move with the main branch?
No. A tag remains attached to its selected commit unless someone deliberately changes it. The main branch can continue to newer commits while the tag still identifies the earlier release snapshot.
Why must conflicts be reviewed semantically?
Conflict markers only reveal overlapping text. A syntactically clean resolution can still discard validation from one branch or restore a defect from another, so verify the intended behaviours from both sides.
Assessment move
Draw several small graphs by hand and label the branch tips, HEAD and one tag. For each graph, identify the common ancestor, decide whether either tip is an ancestor of the other and count parents on the integrating commit. Explain true merge and fast-forward without using visual phrases such as curved line. Next create two disposable branches that edit different files, merge them, and inspect the resulting ancestry.
Repeat with an intentional text conflict. Resolve it by writing down the behaviour each side intended, not by choosing one block mechanically, and run tests for both. Review a branch as a proposal: are commits focused, is the description tied to behaviour, are tests named and is unrelated churn absent? The aim is to make history a source of evidence about collaboration rather than a decorative final record.
Move a branch forward after placing a tag and verify that the tag remains on its original commit. Then create one fast-forward integration and one true merge, inspect their parent structures and explain why the histories differ. During conflict practice, preserve a focused commit for the resolution so later review can isolate the integration decision from the feature changes themselves.
Working through Git Collaboration and History in FIT2109? Sia is AskSia’s AI Computer Science tutor — ask any FIT2109 Git Collaboration and History question and get a clear, step-by-step explanation grounded in how FIT2109 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
