Git, version control, change control and SCM are often treated as four names for the same thing. SCM governs the complete controlled set, change control authorises a requested change, and version control records its implementation states. Software Configuration Management: A Worked Example maps the full SCM process. In CR-042, the decisive boundary is approval, repository evidence and baseline creation. Connect these distinctions to broader GATE CS exam preparation without treating every commit as a baseline.
SCM is the umbrella, not another name for Git
Software Configuration Management identifies controlled artefacts, authorises changes, records their states, and checks that a release contains approved versions. SCM contains change control and uses version control. A version-control tool supplies history and collaboration mechanics, not approval decisions.
Term | Question it answers | LibraryPortal example |
|---|---|---|
SCM | Are the approved requirements, code, tests and guide consistent? | Check the complete controlled set |
Change control | Should CR-042 be accepted? | Analyse, authorise, reject or defer it |
Version control | Which commits implemented it? | Trace the branch and commits |
Release management | Which approved set becomes v1.5.0? | Select the audited release set |
A team may keep every source file in Git and still have weak SCM if requirements, database scripts, test evidence and approvals remain outside control.
SCM vocabulary that keeps questions precise
A configuration item is an artefact under control, such as SRS 1.4, commit a13c9e2, schema 7, or test result 128/128 passed. A version is an identified artefact state. A repository records controlled states; a branch, such as change/CR-042, isolates work.
A baseline is a formally reviewed and approved reference set, such as BL-1.4. A release is an approved set delivered for use, here tagged v1.5.0. A commit records one repository state. Many commits may occur between baselines, and a tag alone proves neither approval nor readiness.
Organisations use version and revision differently. The durable distinction is controlled artefact state versus formally approved baseline or release.
Four SCM activities and where change control fits
SCM has four connected activities:
Configuration identification produces a CI register naming the requirements, code, schema, tests and guide under control.
Change control produces an approved, rejected or deferred change record.
Status accounting maps the request to its branches, commits, reviews, tests, baselines and release.
Configuration audit checks that the release contents match the approved records and baseline definition.
The sequence is log request -> describe reason and acceptance criteria -> analyse impact -> authorise, reject or defer -> implement on a controlled branch -> review and test -> audit -> establish the next baseline. Approval may come from a Change Control Board or another named role.
Approval precedes controlled implementation; verification and audit precede the new baseline. Logging a request is not permission to edit production code.
Worked SCM example: CR-042 from BL-1.4 to v1.5.0
LibraryPortal baseline BL-1.4 contains SRS 1.4, commit a13c9e2, schema 7, and 128/128 passing tests. Its rule is permit renewal when completedRenewals < MAX_RENEWALS, with MAX_RENEWALS = 2. CR-042 asks for three completed renewals. At count 2 the request must pass; at count 3 it must fail.
Impact analysis finds changes to the service constant, validation message, one UI label, SRS 1.5, four boundary tests for counts 0, 1, 2, 3, and one guide paragraph. Schema 7 stays unchanged. The illustrative estimate is 5 developer-hours + 3 test-hours + 1 documentation-hour = 9 hours. Impact is medium because behaviour changes without stored-data or schema migration. In this LibraryPortal scenario, the nine-hour estimate is an impact-analysis record, not a standard SCM duration.
CR-042 is approved. Branch change/CR-042 starts at a13c9e2. Commit f31ac20 changes the rule and UI; 8b42d11 adds four tests, SRS 1.5 and guide updates. PR #184 is reviewed, CI reports 132/132 passed because 128 + 4 = 132, and merge commit c60de44 lands on main.
Audit checks the SRS, code, tests and guide. The team creates tag v1.5.0 and baseline BL-1.5 {SRS 1.5, c60de44, schema 7, 132/132 tests}. BL-1.4 remains recoverable, not overwritten.
Release and count | Result |
|---|---|
| allow second renewal |
| reject third |
| allow third |
| reject fourth |
The illustrative minor release is 1.4.0 -> 1.5.0. Semantic-version labels are a team convention, not SCM's definition.
Version control inside the approved SCM workflow
The branch isolates CR-042 work. Two commits separate implementation from tests and documentation. PR #184 supplies review evidence, c60de44 integrates the work, and v1.5.0 names the release point.
Reverting c60de44 creates a new commit that undoes its effect while preserving shared history. Merely moving a local pointer is not the same controlled recovery action.
Traceability is CR-042 -> branch -> f31ac20 and 8b42d11 -> PR #184 -> 132/132 result -> c60de44 -> v1.5.0 -> BL-1.5. A missing link leaves the SCM audit trail incomplete.
SCM traps and failure modes
SCM and version control are identical -> False. Version control is one mechanism used within SCM.
Every commit creates a baseline -> False. A baseline requires formal review and approval.
A baseline can never change -> Misleading. Preserve the old baseline and establish a controlled new one.
A tag proves the build passed audit -> False. It names a point but supplies neither approval nor test evidence.
Logging CR-042 authorises coding -> False. The request must pass the defined decision step first.
Watch the off-by-one condition too. With completedRenewals < 3, substitute count 2: 2 < 3 is true, so the third renewal is allowed. Substitute count 3: 3 < 3 is false, so the fourth is rejected.
Register unversioned requirements as configuration items. Replace direct edits on main with the authorised branch and review path. An undocumented emergency change needs the organisation's retrospective record and audit trail. A tag without reproducible inputs needs the exact CI set and build evidence.
Answering SCM questions under exam conditions
Use three steps. Identify the layer: governance, approval, repository history or release. Find the artefact or decision evidence. Then eliminate absolutes such as “every commit” or “never changes” unless the definition supports them.
Ordering drill: after logging a request, place impact analysis -> authorisation -> implementation -> verification -> new baseline. Classification drill: approve CR-042 is change control, 8b42d11 is version control, CR-042 -> PR #184 -> v1.5.0 is status accounting and traceability, and comparing BL-1.5 with approved records is configuration audit.
Exam questions commonly turn these distinctions into ordering, classification and absolute-statement traps. Use MCQ, MSQ or NAT? Knowing the Question Type Is Half the Battle in GATE for question-format technique and GATE CS Subject Weightage: Where Your Study Hours Actually Pay Off to plan revision without inferring a fixed SCM weightage from one paper.
The short version and next study step
SCM = umbrellachange control = decide and authoriseversion control = record and integrate statesbaseline = formally approved reference setaudit and status accounting = prove what changed and what was released
CR-042 becomes BL-1.5 after approval, two traceable commits, 132/132 tests and audit. Redraw both diagrams, then explain why a13c9e2, c60de44, v1.5.0 and BL-1.5 are related but not interchangeable.
For a course whose live curriculum includes SCM, continue with Zero to Hero. For a broader GATE CS path, GATE Guidance by Sanchit Sir is the wider option.
