Version Control, Configuration and Change Management

Introduction

Software is rarely created by one person working on one file. Teams modify source code, tests, documentation, infrastructure definitions, libraries, build scripts, and deployment settings at different times and often from different locations. Without disciplined control, a project can lose changes, introduce incompatible versions, or release software that cannot be reproduced.

Version control, configuration management, and change management provide the organizational and technical foundation for reliable team-based development. Version control records the history of files and supports collaboration. Configuration management identifies the complete set of items that form a product and controls their versions. Change management ensures that proposed changes are evaluated, approved, implemented, and verified. Together, these practices improve traceability, quality, recovery, and release confidence.

This chapter concentrates on distributed version control, especially Git, and connects it with branching, pull requests, baselines, dependency management, build tools, release identification, and configuration audits.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose and operation of distributed version control.
2. Use a Git repository, commits, branches, remotes, and tags appropriately.
3. Select a branching strategy suitable for a development team.
4. Describe an effective pull-request workflow and review criteria.
5. Establish baselines and identify configuration items.
6. Manage dependencies and create reproducible builds.
7. Identify releases using tags, version numbers, and build metadata.
8. Conduct a configuration audit and evaluate change-control evidence.

1. Configuration Management as a Software Engineering Discipline

A configuration item is a product, document, tool, or other component placed under configuration control. Examples include source files, automated tests, database schemas, API specifications, container definitions, compiler settings, deployment scripts, and user documentation. A configuration is the collection of identified items and their relationships at a particular point in time.

Configuration management normally includes five related activities:

A source-code repository alone is not necessarily a complete configuration-management system. If the repository contains code but not the dependency lockfile, build instructions, database migration scripts, or deployment configuration, another developer may be unable to reproduce the delivered system.

Configuration status and traceability

Status accounting answers questions such as:

• Which files and dependencies comprise release 2.4.1?
• Which change request introduced a security fix?
• Which tests were executed for a particular build?
• Which person approved the change?
• Which environment received the release?

Traceability links requirements, work items, commits, reviews, builds, test results, and releases. It does not require every organization to use the same tool, but it requires consistent identifiers and records.

2. Distributed Version Control

In a distributed version-control system (DVCS), each complete clone normally contains the repository history, not merely the latest snapshot. Git is the most widely used example. Developers can commit locally, inspect history, create branches, and compare revisions without continuous access to a central server. A remote service is still useful for collaboration, backup, review, and automation.

Important Git concepts include:

• Working tree: Files currently checked out for editing.
• Index or staging area: The proposed contents of the next commit.
• Commit: An immutable recorded snapshot with metadata and a parent relationship.
• Branch: A movable reference to a line of development.
• Remote: A named reference to another repository, commonly called origin.
• Merge: Combining histories from two lines of development.
• Rebase: Replaying commits onto a different base; it creates new commit identities.
• Tag: A named reference, usually used to identify a significant revision such as a release.

A simplified workflow is:

git clone <repository-url>
git switch -c feature/payment-validation
# edit files
git add src/ tests/
git commit -m "Validate payment response"
git push -u origin feature/payment-validation
# open a pull request

The command git add does not publish a change; it places selected content in the staging area. git commit records it locally. git push transfers commits to a remote repository. This distinction is important because a successful local commit is not automatically available to the team.

Good commits

A useful commit has a focused purpose, a descriptive message, and a reviewable size. A commit should not combine unrelated formatting, a database redesign, and a bug fix merely because they were made on the same day. Small, coherent commits make reviewing, reverting, and tracing easier.

A practical message describes the result rather than the activity. “Handle expired access tokens” is more informative than “Changes made.” Teams may use a convention such as:

fix(auth): reject expired access tokens

Commit history is not a substitute for design documentation. Complex decisions should also be recorded in an issue, decision record, or architecture document.

Merge and rebase

A merge preserves the histories of both branches and may create a merge commit. A rebase changes the apparent base of commits by replaying them. Rebasing a private feature branch can make its history easier to read, but rebasing commits already used by others can disrupt their work because commit identities change. A general professional rule is: do not rewrite shared history unless the team has explicitly agreed and understands the consequences.

3. Branching Strategies

A branching strategy defines how a team separates, integrates, and releases work. It should reflect delivery frequency, product risk, team size, and deployment capability.

Trunk-based development

In trunk-based development, developers integrate small changes frequently into a main branch, often using short-lived branches or direct commits subject to review. Incomplete functionality is hidden behind feature flags where necessary. This approach reduces long-lived divergence and encourages continuous integration.

Feature branching

A feature branch isolates a change until it is ready for review. It is suitable for teams that require pull requests or need temporary isolation. Its main risk is excessive branch lifetime. As a branch becomes old, the probability of conflicts and integration surprises increases.

Release branches

A release branch can stabilize a version while new work continues elsewhere. Only selected fixes are accepted into it. This can be useful for products with formal testing or maintenance releases, but it adds coordination and merge overhead.

Gitflow-style branching

Gitflow-style models use long-lived branches for development, releases, and hotfixes. They can suit products with scheduled releases and multiple supported versions, but may be unnecessarily complex for continuously deployed web systems. No branching strategy is universally best; the appropriate strategy is the simplest one that satisfies the product's release and governance needs.

Branch protection

Protected branches can require successful automated tests, at least one review, signed commits, or an up-to-date branch before merging. Protection is valuable, but it must not become a substitute for engineering judgment. Emergency procedures should be documented and audited rather than relying on informal administrator access.

4. Pull Requests and Code Review

A pull request (PR) is a formal proposal to merge changes from one branch into another. It creates a collaboration point for discussion, automated checks, review, and evidence of approval.

An effective PR normally contains:

1. A concise description of the problem and solution.
2. A reference to the requirement, defect, or change request.
3. Test evidence and known limitations.
4. Notes about database, security, configuration, or operational effects.
5. A manageable set of changes.

Reviewers should examine correctness, maintainability, security, performance where relevant, test adequacy, error handling, backward compatibility, and consistency with project standards. Review comments should address the artifact rather than attack the author. A reviewer who identifies a serious risk should explain the reason and propose a path to resolution.

Automated checks commonly include compilation, unit tests, static analysis, formatting, dependency vulnerability scanning, and deployment validation. Automation provides repeatable evidence, but it cannot fully assess business meaning, usability, or architectural consequences.

5. Baselines and Change Control

A baseline is an approved reference configuration that can be changed only through an authorized process. A baseline may represent an approved requirements specification, a tested software version, or a production deployment configuration.

A typical change-control process is:

1. Record a change request with its reason and scope.
2. Analyze impact on cost, schedule, architecture, security, quality, and compliance.
3. Decide whether the change is approved, rejected, deferred, or returned for more information.
4. Implement the change in a controlled branch or work item.
5. Review and test it.
6. Update affected documentation and configuration records.
7. Establish or revise the baseline when acceptance criteria are met.

A small team may perform these activities through an issue, PR, and release checklist. A safety-critical or regulated organization may require a formal change-control board and signed records. The principle is the same: the authority to change a baseline must be clear, and the evidence must be recoverable.

Baselines are not frozen forever. They are stable reference points. If a defect is found, a corrective change can be approved, verified, and incorporated into a new baseline.

6. Dependency Management

A dependency is an external component required by a system, such as a library, runtime, operating-system package, container image, plugin, or build tool. Dependencies create productivity benefits but also introduce security, licensing, compatibility, and availability risks.

A dependency declaration should distinguish:

• Direct dependencies: Explicitly required by the project.
• Transitive dependencies: Required by another dependency.
• Runtime dependencies: Needed when the application executes.
• Development dependencies: Needed for testing, linting, or building.

Use a manifest to declare intended dependencies and a lockfile to record resolved versions where the ecosystem supports it. The manifest expresses acceptable constraints; the lockfile supports repeatable installation. Both should normally be reviewed and version-controlled.

Version constraints must be understood. A range may permit a future update that introduces incompatibility. Pinning every dependency can improve repeatability but increases maintenance effort. A balanced policy may pin production resolutions, update on a schedule, test updates automatically, and document exceptions.

Dependency management should also include:

• vulnerability monitoring and timely remediation;
• software bill of materials (SBOM) generation where required;
• license review;
• trusted package sources;
• verification of package integrity;
• removal of unused dependencies;
• support-lifecycle monitoring.

A dependency scanner finding is not automatically proof of exploitability, but it requires investigation. Teams should record risk acceptance or remediation decisions rather than silently ignoring alerts.

7. Build Tools and Reproducible Builds

A build transforms source and other inputs into outputs such as binaries, packages, documentation, or container images. Build tools define tasks, dependencies among tasks, and the commands used to execute them. Examples include Maven and Gradle for Java, npm scripts for JavaScript, MSBuild for .NET, and Make for general-purpose workflows.

A good build is:

• automated;
• repeatable;
• observable through logs;
• independent of an individual's undocumented workstation settings;
• validated by tests;
• able to fail clearly when required inputs are absent.

Reproducibility means that the same identified inputs and build procedure produce equivalent outputs, subject to documented environmental assumptions. Exact byte-for-byte reproducibility may require controlling timestamps, operating-system details, compiler versions, locale, and dependency sources. For diploma-level projects, the practical starting point is to document the runtime, build tool, dependency lockfile, commands, and environment variables.

Build pipelines commonly contain stages such as:

source checkout → dependency resolution → compile/package → tests
              → static/security checks → artifact storage → deployment

An artifact should be treated as an output of a particular source revision and build environment. Rebuilding an identical source revision later may not produce an identical artifact if dependencies are floating or the toolchain has changed. Therefore, release records should identify both source and build inputs.

8. Release Identification and Versioning

A release is an identified set of software made available to users or another environment. Release identification should be unambiguous. Common mechanisms include Git tags, semantic version numbers, build numbers, artifact digests, and release notes.

Semantic Versioning uses the form MAJOR.MINOR.PATCH for public APIs: increment MAJOR for incompatible changes, MINOR for backward-compatible functionality, and PATCH for backward-compatible bug fixes. This convention is useful only when the project defines what compatibility means. It does not replace testing or release notes.

A release record should ideally include:

• product and release version;
• source-control commit or tag;
• build identifier and toolchain;
• dependency-lockfile revision;
• test results;
• deployment environment;
• known issues and rollback instructions;
• approvers and release date.

For example, a release might be identified as v2.3.1, built from a signed tag, with artifact digest sha256:... and pipeline run 1842. The tag identifies a source position; the digest identifies the exact stored artifact. These are related but not interchangeable.

9. Configuration Audits

A configuration audit provides evidence that a product and its records are complete, consistent, and compliant with the approved configuration. Two useful forms are:

• Functional configuration audit: Determines whether the product performs the required functions and satisfies acceptance criteria.
• Physical configuration audit: Determines whether the delivered product and documentation correspond to the approved item list and version records.

An audit may sample commits, PR approvals, tags, build logs, dependency files, deployment manifests, and test reports. Typical questions include:

1. Can the release be traced to an approved change?
2. Are all source and configuration files under control?
3. Was the artifact built from the identified revision?
4. Are third-party components recorded and licensed appropriately?
5. Do production settings match the approved baseline?
6. Can the system be restored or rolled back?

Audit evidence should be factual and reproducible. A checklist that is signed without supporting records is weak evidence. Audits should identify nonconformities, responsible owners, due dates, and verification of corrective action.

10. Applied Case: Campus Appointment Service

Background

This illustrative case concerns a student team developing a web service that allows learners to book appointments with academic advisers. The team has four developers, one tester, and a faculty product owner.

Problem

The first prototype used shared folders and manual deployment. Developers overwrote files, the test environment used different library versions from the production environment, and the team could not determine which code was running when a booking defect was reported.

Analysis

The team identified three principal causes: no authoritative repository, uncontrolled dependencies, and no release evidence. The absence of a baseline also meant that a change to appointment rules could be deployed without explicit approval.

Approach and solution

The team created a Git repository with protected main, short-lived feature branches, and mandatory pull requests. Each PR referenced a product-owner issue and required automated tests. The project added a dependency manifest and lockfile, and the continuous-integration pipeline ran installation, tests, static analysis, and packaging in a documented container environment.

A release checklist required a version tag, test report, database-migration review, and rollback plan. The team adopted a rule that production deployments used only tagged artifacts, not uncommitted workstation files. Configuration values such as database credentials were moved to a secret-management system rather than stored in the repository.

Outcome

When a duplicate-booking defect appeared, the team traced it from the user report to an issue, PR, commit, build, and release tag. They reverted the affected artifact, corrected the defect on a feature branch, and produced a new patch release. The team also discovered that a transitive library had a security advisory and updated it through a reviewed dependency change.

Learning points

The main improvement did not come from Git commands alone. It came from linking version control with review, dependency resolution, build evidence, release identification, and auditability. A repository becomes valuable when team behavior and automation make its records trustworthy.

11. Challenges, Governance, and Professional Practice

Version-control practices have limitations. A commit history can be technically complete yet fail to explain a business decision. Automated tests can pass while requirements remain misunderstood. A lockfile improves reproducibility but does not guarantee that a dependency is secure. Excessive process can slow delivery and encourage workarounds.

Security and governance require additional care. Never commit passwords, private keys, access tokens, or personal data. Repository permissions should follow least privilege. Branch-protection rules, review requirements, and release permissions should be periodically reviewed. Logs may contain personal or confidential information and should be retained according to organizational policy and applicable law.

AI-assisted coding tools can generate code, tests, and commit messages, but generated output remains the team's responsibility. Developers must review licensing implications, security behavior, data exposure, hallucinated APIs, and test quality. AI tools should not be granted unrestricted access to confidential repositories or secrets. Their use should be governed by the same review, testing, and approval requirements as human-authored changes.

Best-practice checklist

• Keep one authoritative repository for each product.
• Commit coherent changes and write meaningful messages.
• Keep branches short-lived unless a documented reason exists.
• Protect important branches and require review.
• Automate tests and build validation.
• Version-control manifests, lockfiles, build definitions, and deployment configuration, while excluding secrets.
• Tag releases and retain build evidence.
• Record dependency, license, and vulnerability decisions.
• Define baselines and approval authority.
• Audit both the delivered artifact and the records supporting it.
• Practice restoration and rollback rather than assuming they will work.

Chapter Summary

Version control records the evolution of software and enables multiple developers to work safely. Distributed systems such as Git support local commits and branching while remote repositories provide collaboration and governance. Branching strategies should be selected according to delivery needs, and pull requests combine human review with automated quality checks.

Configuration management extends beyond source code. It identifies configuration items, establishes baselines, controls changes, reports status, and audits the delivered configuration. Dependency manifests and lockfiles help control external components, while build tools automate repeatable production of artifacts. Releases should be identified by tags, versions, build records, and, where appropriate, artifact digests. Configuration audits verify that the recorded, approved, and delivered states agree. Effective practice combines technical tools with clear responsibilities, security controls, professional judgment, and evidence-based change management.

Key Terms

Configuration item: A component placed under configuration control.

Configuration management: Identification, control, status accounting, and auditing of a system's configuration.

Version control: Management of successive revisions of files and related artifacts.

Distributed version control: Version control in which repository history is available in each full clone.

Commit: A recorded snapshot of repository content and its metadata.

Branch: A movable reference representing a line of development.

Merge: Integration of histories from different branches.

Rebase: Reapplication of commits onto a new base.

Pull request: A reviewed proposal to merge one branch into another.

Baseline: An approved reference configuration subject to controlled change.

Change request: A documented proposal to modify an approved product or configuration.

Dependency: An external component required by a system or its build.

Lockfile: A file recording resolved dependency versions.

Build: The controlled transformation of inputs into software artifacts.

Artifact: A produced package, binary, image, or other build output.

Release: An identified software version made available for use.

Tag: A named source-control reference, often used to identify a release.

Configuration audit: An examination of whether a product and its records match the approved configuration.

Software bill of materials: An inventory of components contained in a software product.

Review Questions

Short Answer Questions

1. What is the difference between a commit and a push in Git?
2. Define a baseline and explain why it is useful.
3. What information does a lockfile provide?
4. State two responsibilities of a pull-request reviewer.
5. Distinguish a configuration item from a configuration.

Long Answer Questions

1. Explain how distributed version control supports collaboration, recovery, and traceability.
2. Compare trunk-based development, feature branching, and release branching.
3. Describe a complete change-control process from request submission to baseline update.
4. Explain how build tools, dependency management, and release tags contribute to reproducible delivery.
5. Describe the purpose and evidence requirements of functional and physical configuration audits.

Analytical / Application Questions

1. A team frequently merges six-month-old branches and suffers repeated conflicts. Analyze the likely causes and recommend a branching and integration policy.
2. A production defect is reported, but the team cannot identify the source revision, dependency versions, or test results for the deployed system. Design a release-identification and build-recording process that would prevent this problem.
3. A dependency scanner reports a high-severity vulnerability in a transitive library that the application does not directly call. Explain how the team should investigate, assess risk, decide on action, and document the result.

Multiple Choice Questions with Answers

Question 1

Which Git operation records a change in the local repository history?

A. git push

B. git commit

C. git clone

D. git fetch

Correct Answer: B. git commit

Question 2

What is the primary purpose of a pull request?

A. To delete a remote repository

B. To replace all automated tests

C. To propose changes for review and controlled integration

D. To store passwords securely

Correct Answer: C. To propose changes for review and controlled integration

Question 3

Which item most directly supports repeatable dependency installation?

A. A lockfile

B. A screenshot

C. A code comment

D. A branch name

Correct Answer: A. A lockfile

Question 4

What does a baseline represent?

A. An untested personal copy

B. An approved reference configuration

C. A temporary editor file

D. A list of rejected commits

Correct Answer: B. An approved reference configuration

Question 5

Which practice best reduces divergence between developers?

A. Keeping branches unmerged for long periods

B. Integrating small changes frequently

C. Avoiding automated tests

D. Editing production files directly

Correct Answer: B. Integrating small changes frequently

Question 6

What does a Git tag commonly identify?

A. A significant source revision such as a release

B. A developer's password

C. An unresolved merge conflict only

D. A temporary operating-system process

Correct Answer: A. A significant source revision such as a release

Question 7

Which audit checks whether the delivered product corresponds to approved item and version records?

A. Physical configuration audit

B. Usability experiment

C. Market survey

D. Performance benchmark only

Correct Answer: A. Physical configuration audit

Question 8

A protected main branch commonly requires which combination before merging?

A. Successful checks and required review

B. Deletion of the test suite

C. A manually edited production database

D. An unrecorded emergency change

Correct Answer: A. Successful checks and required review

Question 9

Which statement about rebasing shared history is correct?

A. It never changes commit identities

B. It can disrupt collaborators because commits are recreated

C. It automatically publishes changes

D. It replaces dependency management

Correct Answer: B. It can disrupt collaborators because commits are recreated

Question 10

Which release record provides the strongest identification of the exact stored build output?

A. The developer's local folder name

B. An artifact digest linked to the source tag and build record

C. The date in a chat message

D. A branch with no commits

Correct Answer: B. An artifact digest linked to the source tag and build record