5 exercises — understand the workflow culture and terminology around Git, branches, and collaboration.
Git culture expressions in this set
blameless postmortem — reviewing failures without punishing people
CODEOWNERS — a file defining who must review certain code
code freeze — a period where only critical changes are merged
protected branch — a branch with enforced rules before merging
upstream / downstream — the source repo vs. those that derive from it
0 / 5 completed
1 / 5
A team runs a "blameless postmortem" after an outage. What does this mean?
A blameless postmortem examines an incident to find the systemic contributing factors and improve them, deliberately avoiding finger-pointing. The reasoning is practical: if people fear blame, they hide details and the organisation fails to learn, so failures recur. It assumes people acted reasonably given what they knew and asks how the system allowed a reasonable action to cause harm. The culture contrast is "git blame culture," where the focus is on who wrote the bad line rather than why the system let it ship.
2 / 5
A repository has a "CODEOWNERS" file. What does it do?
A CODEOWNERS file (supported by GitHub and GitLab) maps paths in the repo to the people or teams responsible for them. When a pull request touches those paths, the owners are automatically requested as reviewers, and the branch can require their approval before merging. It encodes responsibility and ensures the right experts review changes to sensitive areas (e.g. the auth module or the payments code), rather than relying on people to remember who to ask.
3 / 5
A team announces a "code freeze" before a major release. What does this mean?
A code freeze is a window — often the days before a release — when the team stops merging new features and accepts only essential, low-risk fixes. The goal is to stabilise the release candidate so last-minute changes do not introduce new bugs. A related term, "feature freeze," stops new features but may still allow bug fixes. Freezes are a trade-off: they reduce risk but also slow delivery, so teams keep them as short as possible.
4 / 5
The main branch is a "protected branch". What does this imply?
A protected branch has rules enforced by the platform before anything can land on it: typically requiring pull-request review, passing status checks (CI), up-to-date branches, and disallowing direct pushes or force-pushes. Protecting main ensures every change is reviewed and tested, preventing accidental or unreviewed code from reaching the branch that ships to production. It is a foundational safeguard in team Git workflows.
5 / 5
A contributor is asked to "submit the fix upstream". What does upstream mean here?
In Git/open-source culture, upstream is the original source repository from which your copy (a fork or clone) is derived; downstream are the projects that pull from it. "Submit the fix upstream" means contribute it back to that source repo (via a pull request) so the whole community gets the improvement, rather than keeping it only in your fork. "Contributing back upstream" is a core open-source value — it prevents fixes from being lost in isolated forks and keeps the shared project healthy.