# How this maps to industry practice

> The course workflow next to real companies, from startups to enterprises: what is the same everywhere, what changes with size, trunk-based vs Gitflow-style branching, and the terms you will hear as an intern.

Source: https://laszlonemes.com/university/software-technology/industry-context · Author: László Nemes

Reading · Software Technology

The course workflow next to real companies, from startups to enterprises: what is the same everywhere, what changes with size, trunk-based vs Gitflow-style branching, and the terms you will hear as an intern.

7 min read `What transfers directly` `Startup vs mid-size vs enterprise` `Trunk-based vs Gitflow` `What the course leaves out` `Industry vocabulary`

This page is context, not rules. It places the course's workflow next to how software companies actually work – from a five-person startup to an enterprise with thousands of developers – so you know which habits transfer directly to an internship and which ones each company does its own way.

After this session you can

- name the practices that are the same in almost every software company
- describe how branching, review, CI and releases change with company size
- tell trunk-based development from a Gitflow-style model
- explain why the course skips squash merges, Conventional Commits and deployment

## What is the same everywhere

The course takes these one-to-one from industry practice. If they come naturally to you, you won't have to relearn them in your first job:

| Practice | In this course | In a company |
| --- | --- | --- |
| Task tracking | GitLab issues, board, milestones | Jira, GitLab, Azure DevOps, Linear; a sprint board |
| Issue → branch → MR → merge | required | required; the branch name usually carries the ticket key (PROJ-1234) |
| Protected main branch | `main` and `develop` | `main` and release branches; not even the tech lead pushes directly |
| Code review on every MR | 1 approval | 1–2 approvals; in large companies CODEOWNERS name mandatory reviewers |
| CI on every MR | build, tests, formatting, static analysis | the same, plus security scans and integration tests – sometimes hours |
| Green pipeline before merge | required | required – a red main means everyone stops and fixes it |
| Formatter and linter | Spotless / dotnet format, SpotBugs / Roslyn | the same, or Checkstyle, ESLint, Prettier, SonarQube |
| Unit tests and coverage | high coverage of the model | 70–90% expected, but what the tests check matters more than the number |
| Versioned releases | `v1.0` tags, a Releases page | Semantic Versioning, release notes, often generated |
| Status meeting | weekly session: done / next / blocked | daily stand-up, 10–15 minutes, the same three questions |
| Definition of Done | six points in the contribution rules | the same idea, extended per team |

## What changes with company size

The practices stay; their weight changes (Fig. 1). Startups optimise for speed, large companies for safety and traceability.

> **Fig. 1** · Same ideas, different weight. A startup's laxness is learned in a week; an enterprise's process is taught by the enterprise. The middle is the most useful reference point.
>
> *Diagram:* How the same practices change with company size. A startup uses GitHub flow with squash merges, one quick approval, a CI of a few minutes and deploys on every merge. A mid-size company uses Gitflow or trunk-based development, one or two approvals with code owners, a CI of ten to thirty minutes and a staging environment. An enterprise uses trunk-based development with feature flags or a strict Gitflow, two approvals including domain and security reviewers, CI that runs for hours, and release windows. This course aims at a simplified mid-size setup.

|  | Startup | Mid-size | Enterprise |
| --- | --- | --- | --- |
| Merge method | squash, for a clean history | squash or merge commit, per team | regulated; often squash plus Conventional Commits for the changelog |
| Who merges | the author | the author, or auto-merge when everything is green | a merge queue |
| Security | secret scanning | + SAST, dependency scanning | + SBOM, licence compliance, penetration tests, audit logs |
| Documentation | README + wiki | architecture decision records, Confluence | all of that + compliance documents |

## Two branching styles

The course uses a Gitflow-style model: a `develop` branch for integration, release branches, tags on `main`. Many large web companies use **trunk-based development** instead: everyone merges tiny branches into `main` daily, and unfinished features are switched off with feature flags (Fig. 2).

> **Fig. 2** · Trunk-based development merges many times a day and releases continuously. A Gitflow-style model batches work on develop and releases at fixed points – which fits milestones.
>
> *Diagram:* Left, trunk-based development: everyone merges tiny branches into main several times a day, and unfinished features hide behind feature flags. Right, the Gitflow-style model of this course: feature branches merge into develop, and develop reaches main in releases.

Milestone demos are fixed release points, so the Gitflow-style model fits the course. The habits behind both are the same: small branches, frequent merges, a protected main line, a green pipeline.

## What the course leaves out on purpose

These exist in real companies, but for three people and thirteen weeks they cost more administration than they return:

- **Conventional Commits** (`feat:`, `fix:` …) – the issue key ties a commit to its task, which is what traceability needs; the type is already in the branch name. They can be combined: `ABC-12: feat: …`.
- **Squash merges** – they would erase the individual commits that grading partly relies on. Common in companies, switched off here.
- **Two approvers, CODEOWNERS, automatic changelogs** – meaningless with three people.
- **Environments and deployment** – a desktop game has nothing to deploy. The packaged build on the Releases page is the equivalent.

## Terms you will hear

- **Trunk-based development** – Everyone merges into main daily; branches live a day or two; unfinished work hides behind feature flags.
- **Feature flag** – A configuration switch that turns finished code on or off at runtime, so it can be merged before the feature goes live.
- **Conventional Commits** – feat:, fix:, chore:, docs: prefixes, used to generate changelogs and version numbers automatically.
- **Semantic Versioning** – MAJOR.MINOR.PATCH – breaking change / new feature / fix. Mandatory for libraries, advisable for applications.
- **CODEOWNERS** – A file that says who owns which folder; their approval is required. Useless for three, essential for thirty.
- **Merge queue / merge train** – Approved MRs are re-tested and merged one by one on the latest main, so two separately green MRs can't turn main red together.
- **Monorepo** – Several applications and libraries in one repository with shared CI. Your project is one repository of a "polyrepo".
- **ADR** – Architecture Decision Record: the question, the options, the choice and why. Your design wiki is an early form of it.
- **DoR / DoD** – Definition of Ready (when a task can start) and Definition of Done (when it is finished). The course uses only the DoD.
- **Story points, velocity** – Relative estimates of tasks and the team's capacity per sprint.
- **Retrospective** – At the end of a sprint: what went well, what didn't, what to change. Worth 15 minutes after each milestone.
- **On-call, incident, postmortem** – Someone is on duty when production fails; afterwards a blameless write-up says what happened and how to prevent it.

## What a course can't simulate

- **Real users and operations.** No production, no monitoring, no customer complaints. The instructor as product owner covers part of it.
- **Long-lived code.** In a company code lives for five to ten years and others live with your decisions. In thirteen weeks that doesn't show, which is why documentation and clean code can feel pointless. They aren't.
- **Many teams on one code base.** API contracts, compatibility, deprecation. Your model–view separation is a miniature of it.
- **Time and money pressure at once.** The course has deadlines, but no paying customer.

Good to know

**Hold a retrospective**

After each milestone, take fifteen minutes as a team: what went well, what didn't, what you change for the next sprint. It is the cheapest process improvement there is.

## What you take with you

> An intern meets all of these in the first weeks: opening a branch from a ticket, writing a meaningful commit, opening an MR with a description, taking a review without taking offence, reading a red pipeline, not pushing to main, not committing secrets – and knowing that "done" isn't when the code runs, but when it is merged and green.

If any of it is still shaky, the [issue lifecycle cheat sheet](https://laszlonemes.com/university/software-technology/issue-lifecycle) and the [code review guide](https://laszlonemes.com/university/software-technology/code-review) are the two pages to practise with.