Skip to content

IGB-DOC-006

Git Workflow Standard

Document ID : IGB-DOC-006

Version : v1.0

Status : Draft

Owner : IGB Engineering

Last Update : 2026-08

Revision History

Version Date Description
v1.0 2026-08 Initial Draft

Purpose

This document defines the operational Git workflow used by IGB Engineering to implement the version-control governance requirements established by IGB-DOC-005.

The purpose of this standard is to provide a controlled and repeatable workflow for:

  • development;
  • review;
  • integration;
  • branch management;
  • commit management;
  • merge operations;
  • release preparation; and
  • repository-state control.

This standard defines operational procedures.

It shall not override the governance requirements established by IGB-DOC-005 or higher-level engineering governance.

Scope

This standard applies to engineering repositories using Git within the IGB Engineering Platform where controlled engineering artifacts are maintained under version control.

The scope includes, where applicable:

  • repository initialization;
  • repository structure;
  • branch creation and usage;
  • development changes;
  • commit creation;
  • review preparation;
  • merge and integration;
  • tag creation;
  • release preparation;
  • repository synchronization;
  • history preservation;
  • controlled rollback;
  • branch cleanup; and
  • repository workflow traceability.

This standard does not define product-specific engineering requirements.

Product-specific requirements shall remain governed by the applicable architecture, specification, configuration-management, and engineering-control documents.

Authority

IGB-DOC-006 is subordinate to the applicable IGB engineering governance hierarchy.

IGB-DOC-005 defines the governing version-control policy.

IGB-DOC-006 defines the operational Git workflow used to implement that policy.

Where a conflict exists between this standard and IGB-DOC-005, IGB-DOC-005 shall take precedence.

Where a conflict exists between this standard and IGB-DOC-001, IGB-DOC-001 shall take precedence within its defined authority.

No repository-local workflow shall silently override a higher-level controlled requirement.

Definitions

Git Repository

A repository containing version-controlled engineering artifacts and their associated revision history.

Working Tree

The local filesystem state containing the currently checked-out repository content.

Branch

A Git development line used to isolate and organize controlled changes before integration.

Commit

A recorded Git change set representing a specific repository state transition.

Merge

An authorized integration operation that incorporates changes from one development line into another.

Tag

A persistent Git reference identifying a specific repository state.

Protected Branch

A branch subject to repository controls that restrict unauthorized modification or integration.

Release Revision

The repository revision designated as the source of a controlled release.

Canonical Repository

The repository recognized as the authoritative source for the controlled engineering content within its defined scope.

4. Repository Initialization

A Git repository shall be initialized only when an applicable engineering repository or controlled development activity requires version control.

Repository initialization shall establish, where applicable:

  • repository identity;
  • canonical repository location;
  • default branch;
  • repository access control;
  • applicable repository ownership;
  • applicable documentation structure;
  • applicable engineering governance references; and
  • required repository configuration.

The repository shall not be initialized as an uncontrolled duplicate of an existing canonical engineering repository.

Where an existing repository already serves as the canonical repository for the applicable engineering scope, a new repository shall not be created solely to establish an alternative authority.

Repository initialization shall preserve the relationship between the repository and the applicable engineering program, architecture, specification, or governance baseline.

5. Repository Structure

The repository structure shall remain consistent with the applicable documentation architecture, engineering architecture, and repository governance requirements.

Controlled artifacts shall be maintained in their designated repository locations.

Repository structure shall support:

  • deterministic artifact location;
  • canonical artifact identification;
  • separation of controlled and temporary content;
  • traceability;
  • review;
  • integration;
  • release preparation; and
  • historical reconstruction.

Repository-local directories shall not be created in a manner that establishes a competing authority for an existing controlled artifact.

Where repository structure changes affect controlled artifact locations, the change shall be reviewed and dispositioned through the applicable engineering change-control process.

6. Branch Creation and Usage

Branches shall be created when isolation of development activity is required.

A branch shall have a defined engineering purpose.

Branch usage shall maintain a clear relationship between:

  • development activity;
  • affected artifacts;
  • review activity;
  • integration target;
  • resulting revision; and
  • applicable change or issue context.

Branches shall not be used to establish competing permanent authorities for the same controlled artifact.

The authoritative state of a controlled artifact shall remain associated with the applicable controlled integration branch or canonical repository state.

Temporary development branches may be deleted after successful integration when their historical information remains recoverable through the repository history.

Where a branch is associated with a formal engineering change, requirement, defect, review, or decision, the applicable traceability reference should be preserved.

7. Working Tree Control

Engineering changes shall be made within a controlled working tree associated with the applicable Git repository and branch.

Before beginning controlled development activity, the working tree should be synchronized with the applicable integration target.

Developers shall review the working-tree state before committing changes.

Unintended modifications shall be identified and resolved before a controlled commit is created.

Temporary files, generated artifacts, credentials, secrets, and unrelated local content shall not be intentionally committed to controlled repository history.

Where generated content is itself a controlled engineering artifact, its inclusion shall be governed by the applicable repository and engineering requirements.

8. Commit Creation

Commits shall represent meaningful engineering changes.

A controlled commit should provide sufficient information to determine:

  • what changed;
  • why the change was made;
  • the affected engineering context; and
  • the resulting repository state.

Commit messages shall be sufficiently descriptive to support repository history review.

Where a change is associated with a formal:

  • engineering change;
  • requirement;
  • defect;
  • issue;
  • review;
  • architecture decision; or
  • other controlled engineering record,

the applicable traceability reference should be preserved in the commit or associated review record.

A commit shall not be intentionally used to conceal, obscure, or misrepresent an engineering change.

Large unrelated changes should not be combined into a single commit when doing so would materially reduce traceability or reviewability.

9. Commit Review

Controlled commits shall be reviewed as required by the applicable engineering workflow, change-control process, or repository governance.

Commit review shall determine, where applicable:

  • the intended engineering change is identifiable;
  • the affected artifacts are identifiable;
  • the commit is consistent with the applicable engineering context;
  • required traceability references are present;
  • unintended or unrelated changes are not included;
  • repository naming and structural requirements remain satisfied; and
  • the resulting repository state is suitable for the intended integration activity.

Commit review shall not by itself constitute engineering approval, baseline approval, or release approval unless the applicable governance process explicitly assigns such authority to the review.

Where a commit is found to contain unintended, incomplete, unauthorized, or materially unreviewable changes, the commit shall not be integrated into a controlled branch until the applicable disposition has been completed.

Review records shall remain traceable to the affected commit or repository state where required by the applicable engineering governance.

10. Merge and Integration

Changes shall be integrated into a controlled branch only after the applicable review and integration requirements have been satisfied.

Merge operations shall preserve the traceability of the integrated changes and the resulting repository state.

Before a merge is performed, the responsible party shall verify, where applicable:

  • the source branch is identifiable;
  • the target branch is identifiable;
  • the intended changes have been reviewed;
  • required traceability references are available;
  • required validation has been completed;
  • no unauthorized changes are included;
  • the merge does not intentionally bypass applicable repository controls; and
  • the resulting repository state is suitable for continued engineering activity.

A merge shall not be performed when known unintended, unauthorized, incomplete, or materially conflicting changes remain unresolved.

Where merge conflicts occur, the conflicts shall be explicitly resolved and the resulting state shall be reviewed before the merge is considered complete.

The resolution of a merge conflict shall not silently discard controlled engineering changes.

Where a merge introduces a material engineering change, the resulting repository state shall remain traceable to the contributing commits and applicable engineering records.

A successful merge shall establish a reproducible repository state that can be identified through Git history.

Protected or controlled branches shall be subject to the applicable repository protection and approval requirements.

Direct modification of a protected branch shall not be used to bypass required review or integration controls.

11. Tagging and Release Identification

Git tags shall be used to identify controlled repository states where persistent revision identification is required.

A tag shall identify a specific repository commit and shall not be used as a substitute for the repository history.

Controlled release tags shall be created only for repository states that have satisfied the applicable review, validation, approval, and release requirements.

A release tag should provide sufficient information to identify:

  • the applicable release;
  • the associated repository state;
  • the release context; and
  • the relationship to the applicable engineering baseline or release record.

Tags used for controlled releases shall be persistent references to the approved repository state.

A controlled release tag shall not be moved to a different commit after release unless the applicable change-control and release-management process explicitly authorizes the modification.

Where a released repository state requires correction, a new controlled revision or release shall be established rather than silently modifying the historical release reference.

Tag names shall follow the applicable repository naming convention and shall remain deterministic and machine-readable.

Release tags shall not contain ambiguous or misleading identifiers.

Where a tag is associated with a formal engineering release, baseline, configuration, or other controlled record, the applicable traceability reference should be preserved in the associated release record.

Annotated tags should be used where additional release metadata is required.

A tag shall not be created solely to imply approval, baseline status, or release authority when the applicable governance process has not granted such status.

Historical tags shall remain preserved when required for engineering traceability, auditability, or historical reconstruction.

The repository shall retain sufficient Git history to determine the commit identified by each controlled release tag.

Deletion or rewriting of controlled release tags shall be prohibited unless explicitly authorized through the applicable engineering change-control or repository-governance process.

12. Release Preparation

A release shall be prepared from an identifiable and controlled repository state.

Before release preparation begins, the responsible party shall verify, where applicable:

  • the intended release revision is identifiable;
  • the applicable integration branch is identifiable;
  • required changes have been integrated;
  • required reviews have been completed;
  • required validation has been completed;
  • required engineering approvals have been obtained;
  • applicable configuration and dependency information is available;
  • required release documentation is complete;
  • no known unauthorized changes are included; and
  • the repository state is suitable for release.

Release preparation shall preserve traceability between the release, the repository revision, the applicable engineering baseline, and the associated engineering records.

The release source revision shall remain reproducible from the canonical repository history.

Release artifacts shall be generated from the designated release revision and shall not be substituted with artifacts generated from an unidentified or uncontrolled repository state.

Where release artifacts are generated automatically, the applicable generation process shall remain identifiable and reproducible where required.

Release preparation shall not modify controlled engineering content solely to conceal, bypass, or circumvent applicable review, validation, approval, or change-control requirements.

Any release-specific changes introduced during release preparation shall be treated as controlled engineering changes and shall remain traceable to the resulting release revision.

Before release publication, the responsible party shall verify that the release identifier, repository revision, release tag where applicable, and associated release records are mutually consistent.

A release shall not be considered controlled solely because a Git tag has been created.

Release approval and release authority shall remain governed by the applicable engineering governance and release-control process.

Historical release records shall remain preserved to support auditability, reproducibility, and engineering traceability.

13. Repository Synchronization

Repositories shall be synchronized with their applicable canonical or controlled remote repository as required to maintain an accurate and recoverable engineering state.

Synchronization shall preserve the relationship between:

  • the local repository state;
  • the applicable remote repository;
  • the applicable branch;
  • the contributing commits; and
  • the resulting repository state.

Before synchronization, the responsible party shall verify, where applicable:

  • the intended remote repository is identifiable;
  • the intended branch is identifiable;
  • the local working tree has been reviewed;
  • unintended local changes are not included;
  • required commits have been created;
  • required validation has been completed; and
  • synchronization will not unintentionally overwrite controlled engineering changes.

Changes received from a remote repository shall be reviewed for compatibility with the local engineering state before they are integrated into a controlled branch.

Repository synchronization shall not be used to bypass applicable review, approval, configuration-management, or change-control requirements.

Where synchronization results in conflicts, the conflicts shall be explicitly identified and resolved before the affected controlled branch is considered synchronized.

The resolution of synchronization conflicts shall preserve controlled engineering changes and shall remain traceable to the contributing repository states.

Where a repository contains multiple remotes, the canonical or authoritative remote shall remain explicitly identifiable.

Local repository state shall not be treated as authoritative solely because it differs from the canonical repository state.

Where remote synchronization is unavailable, controlled development may continue only in accordance with the applicable engineering workflow, provided that the resulting repository state remains recoverable and traceable.

Repository synchronization records shall be preserved where required to support engineering traceability, auditability, or historical reconstruction.

14. History Preservation and Controlled Rollback

Git history shall be preserved as a controlled engineering record of repository state transitions.

Controlled engineering history shall not be intentionally rewritten, deleted, or obscured when such action would materially impair traceability, auditability, reproducibility, or historical reconstruction.

History-rewriting operations, including but not limited to force-push, rebase of controlled shared history, commit replacement, or history deletion, shall be restricted in accordance with the applicable repository governance and change-control requirements.

Controlled branches shall not be subjected to history rewriting solely to simplify, conceal, or alter the historical representation of an engineering change.

Where history rewriting is technically required for an authorized repository-management activity, the applicable authorization, affected repository state, and resulting state shall remain traceable.

Rollback shall be performed only when required to restore or establish an authorized repository state.

A controlled rollback shall identify, where applicable:

  • the repository or branch affected;
  • the state being restored;
  • the reason for rollback;
  • the initiating engineering record;
  • the commits or revisions affected;
  • the resulting repository state; and
  • any required follow-up action.

Rollback shall not be used to erase evidence of an engineering change.

Where a rollback removes or reverses a previously integrated engineering change, the repository history and applicable engineering records shall remain sufficient to determine that the change occurred and was subsequently reversed.

A rollback shall produce a repository state that is identifiable and reproducible through the applicable Git history.

Where rollback is performed on a controlled branch, the resulting state shall be reviewed before the branch is returned to normal controlled operation.

Where a rollback affects a released, baselined, or otherwise controlled repository state, the applicable release, baseline, configuration-management, and change-control processes shall govern the disposition.

A new corrective revision or release shall be established where required rather than silently rewriting an established historical state.

Repository history shall remain sufficiently complete to support engineering audit, traceability, reproducibility, and historical reconstruction.

15. Branch Cleanup and Lifecycle Control

Branches shall be managed throughout their lifecycle in accordance with their defined engineering purpose.

A development branch shall remain identifiable from creation through integration, closure, or authorized disposal.

Branch cleanup shall be performed only after the applicable development activity has been completed, integrated, abandoned, or otherwise dispositioned.

Before a branch is deleted, the responsible party shall verify, where applicable:

  • the branch purpose has been dispositioned;
  • required changes have been integrated or otherwise dispositioned;
  • required reviews have been completed;
  • required engineering records have been preserved;
  • required commits remain recoverable through repository history;
  • no controlled engineering changes exist only on the branch; and
  • deletion will not remove a required engineering record or controlled repository state.

Branches containing unreleased or otherwise controlled engineering changes shall not be deleted solely for repository housekeeping.

Where a development branch is abandoned, the reason for abandonment and applicable engineering disposition should remain traceable where required.

Where a branch contains engineering work that is intentionally not integrated, the applicable disposition shall identify whether the work is:

  • cancelled;
  • superseded;
  • transferred to another development line;
  • retained for future development; or
  • otherwise dispositioned under the applicable engineering process.

Merged development branches may be deleted when their required historical information remains recoverable through the canonical repository history.

Deletion of a branch shall not delete or rewrite the commits that are required to preserve engineering traceability.

Protected or controlled branches shall not be deleted or renamed except through the applicable repository-governance and change-control process.

The lifecycle status of controlled branches should remain consistent with the applicable repository workflow and engineering records.

Stale branches shall be periodically reviewed where repository governance requires lifecycle maintenance.

Branch cleanup shall not be used to conceal, obscure, or remove evidence of an engineering change.

Where branch naming or lifecycle rules are established by a higher-level repository or engineering standard, those requirements shall take precedence over local cleanup practices.

16. Repository Workflow Traceability

Git workflow activities shall remain traceable to the repository state and applicable engineering records.

Where required by the applicable engineering process, the repository workflow shall preserve traceability between:

  • the engineering activity;
  • the affected repository;
  • the applicable branch;
  • the contributing commits;
  • the review or approval activity;
  • the resulting repository state; and
  • the applicable engineering record.

Traceability information shall be sufficiently complete to support reconstruction of the relevant engineering workflow.

Where a change is associated with a formal engineering record, the relationship between the repository change and that record shall be preserved.

Repository history, branch history, commit history, merge history, tag history, and applicable release records shall be used as evidence of repository state transitions where required.

Workflow traceability shall not depend solely on local developer memory or undocumented repository practices.

Where automated repository controls generate workflow evidence, the generated evidence shall remain associated with the applicable repository state where required.

Repository workflow traceability shall support engineering review, configuration management, auditability, reproducibility, and historical reconstruction.

Where traceability information is unavailable or incomplete, the affected repository state shall be reviewed and dispositioned in accordance with the applicable engineering governance process.

17. Repository Workflow Compliance and Verification

Repository workflow activities shall be performed in accordance with this standard and the applicable higher-level engineering governance requirements.

Repository workflow compliance shall be verified where required by the applicable engineering process, repository governance, configuration-management process, or release process.

Verification shall determine, where applicable:

  • the repository is identifiable;
  • the canonical repository location is identifiable;
  • the applicable branch is identifiable;
  • the repository state is reproducible;
  • required commits are present;
  • required reviews have been completed;
  • required integration activities have been completed;
  • required tags or release identifiers are correctly associated with the intended repository state;
  • required traceability information is available;
  • controlled history has been preserved;
  • applicable branch lifecycle requirements have been satisfied; and
  • no known unauthorized or uncontrolled repository changes remain unresolved.

Repository workflow verification shall be performed using objective repository evidence where practical.

Repository evidence may include:

  • Git status;
  • Git log;
  • Git diff;
  • Git branch information;
  • Git tag information;
  • merge history;
  • commit metadata;
  • review records;
  • release records;
  • configuration-management records; and
  • applicable automated verification results.

A successful repository command or automated check shall not by itself constitute engineering approval, baseline approval, or release approval unless the applicable governance process explicitly assigns such authority.

Where verification identifies a nonconforming repository state, the affected state shall be reviewed and dispositioned through the applicable engineering governance, configuration-management, review, or change-control process.

Known nonconforming repository states shall not be represented as compliant solely because the repository remains technically usable.

Where corrective action is required, the resulting repository state shall remain traceable to the identified nonconformity and the applicable corrective activity.

Repository workflow compliance records shall be retained where required to support engineering review, configuration management, auditability, reproducibility, or historical reconstruction.

Compliance with this standard does not remove the requirement to comply with IGB-DOC-005 or other applicable higher-level engineering governance requirements.

18. Repository Integrity and Verification

The integrity of a controlled Git repository shall be verified as required to ensure that the repository state remains complete, consistent, recoverable, and traceable.

Repository integrity verification shall consider, where applicable:

  • repository working-tree state;
  • branch state;
  • commit history;
  • merge history;
  • tag references;
  • remote synchronization state;
  • controlled artifact presence;
  • repository structure;
  • applicable release or baseline references; and
  • required engineering workflow records.

Before a controlled repository state is accepted for integration, release preparation, baseline establishment, or other controlled engineering activity, the responsible party shall verify that the repository state is suitable for the intended purpose.

Verification shall identify, where applicable:

  • uncommitted changes;
  • unexpected working-tree modifications;
  • unresolved merge conflicts;
  • missing or inconsistent repository references;
  • unauthorized branch or tag changes;
  • unexpected divergence from the applicable canonical repository;
  • missing controlled artifacts; and
  • other conditions that may materially affect repository integrity.

Where automated verification tools are available, they should be used to provide repeatable repository-state verification.

Typical verification activities may include, where applicable:

  • git status;
  • git diff;
  • git diff --check;
  • branch verification;
  • commit-history inspection;
  • tag verification;
  • remote-state verification; and
  • repository-specific validation or integrity checks.

Verification results shall be reviewed when they identify conditions that may affect the controlled repository state.

A repository shall not be considered verified solely because Git commands execute successfully.

Where repository integrity cannot be established with sufficient confidence, the affected repository state shall be reviewed and dispositioned through the applicable engineering governance, configuration-management, or change-control process.

Repository integrity verification shall not modify controlled engineering history solely to eliminate evidence of an existing repository condition.

Where corrective action is required, the correction shall be implemented as a controlled repository change and shall remain traceable to the condition that initiated the correction.

The resulting verified repository state shall remain reproducible through the applicable Git history and associated engineering records.

Repository integrity verification records shall be preserved where required to support engineering review, auditability, reproducibility, configuration management, or historical reconstruction.

19. Git Workflow Change Control

Changes to controlled Git workflow practices shall be managed through the applicable engineering change-control process.

This standard shall remain the authoritative operational reference for Git workflow within its defined scope.

A repository-local workflow shall not establish requirements that conflict with this standard or applicable higher-level engineering governance.

Changes to repository workflow configuration shall be controlled where the change may affect:

  • repository authority;
  • branch protection;
  • commit requirements;
  • merge controls;
  • release identification;
  • tag management;
  • repository synchronization;
  • history preservation;
  • traceability;
  • workflow verification; or
  • engineering configuration control.

Repository workflow configuration changes may include, where applicable:

  • branch-protection rules;
  • merge requirements;
  • required reviews;
  • commit policies;
  • repository hooks;
  • automation rules;
  • CI/CD controls;
  • tag policies;
  • remote configuration;
  • access controls; and
  • repository-management automation.

A workflow change shall identify, where applicable:

  • the affected repository;
  • the affected workflow or control;
  • the reason for the change;
  • the initiating engineering record;
  • the proposed change;
  • the responsible party;
  • the required review or approval;
  • the implementation state; and
  • the resulting repository state.

Changes affecting controlled repositories shall be reviewed before implementation where required by the applicable engineering process.

Workflow changes shall be validated after implementation to confirm that the resulting repository behavior remains consistent with the applicable requirements.

Where a workflow change affects controlled engineering history, repository authority, release control, or configuration management, the applicable configuration-management and change-control requirements shall also apply.

Temporary workflow changes shall have a defined purpose and disposition.

Temporary repository controls shall not become permanent workflow requirements solely through continued use without appropriate review and authorization.

Emergency workflow changes may be implemented when necessary to protect repository integrity, security, availability, or controlled engineering activity, provided that the applicable emergency-change process is followed.

Emergency changes shall be documented and reviewed retrospectively where required.

Unauthorized modification of controlled workflow configuration shall be treated as a repository-control nonconformity and shall be dispositioned through the applicable engineering governance process.

A workflow change shall not be used to bypass required review, approval, traceability, configuration-management, or release-control requirements.

Where a workflow change is rejected, superseded, or withdrawn, the repository shall retain sufficient information to determine the applicable disposition where required for engineering traceability.

The resulting approved workflow state shall remain identifiable and reproducible through the applicable repository configuration and engineering records.

20. Exception and Deviation Control

Exceptions or deviations from this standard shall be controlled in accordance with the applicable engineering governance and change-control requirements.

A repository-local exception shall not be treated as a permanent modification of this standard.

Where an exception or deviation is required, the responsible party shall identify, where applicable:

  • the affected repository;
  • the affected workflow requirement;
  • the reason for the exception;
  • the applicable engineering context;
  • the initiating engineering record;
  • the scope and duration of the exception;
  • the responsible party;
  • the required review or approval;
  • the compensating controls; and
  • the required disposition.

Exceptions shall be limited to the minimum scope necessary to address the identified engineering condition.

An exception shall not be used to bypass applicable security, configuration-management, release-control, traceability, or engineering approval requirements.

Where an exception affects a controlled branch, release, baseline, or other controlled repository state, the applicable higher-level engineering process shall govern the disposition.

Temporary exceptions shall have an identifiable expiration condition or review point.

An exception shall not remain active indefinitely solely because the underlying condition has not been formally reviewed.

Where compensating controls are required, those controls shall be documented and maintained for the duration of the exception.

Emergency exceptions may be applied when necessary to protect repository integrity, security, availability, or controlled engineering activity, provided that the applicable emergency-change or emergency-governance process is followed.

Emergency exceptions shall be documented and reviewed retrospectively where required.

The use of an exception shall remain traceable to the affected repository state and applicable engineering record.

Where an exception results in a repository state that differs from the normal controlled workflow, the resulting state shall be explicitly identified.

Expired, rejected, withdrawn, or superseded exceptions shall no longer be used as justification for deviation from this standard.

Repeated use of the same exception shall be reviewed to determine whether a controlled change to the workflow or applicable engineering standard is required.

Exceptions shall not be used to conceal nonconformities, unauthorized changes, incomplete reviews, or deficiencies in repository control.

Where compliance with this standard cannot be established, the affected repository state shall be reviewed and dispositioned through the applicable engineering governance process.

The existence of an approved exception does not remove the requirement to preserve repository history, traceability, auditability, reproducibility, and configuration-management evidence.

21. Records Retention and Evidence Preservation

Git workflow records and repository evidence shall be retained in accordance with the applicable engineering record, configuration-management, documentation, and repository-retention requirements.

Records shall be retained when they are required to demonstrate:

  • repository state;
  • engineering change history;
  • review or approval activity;
  • integration activity;
  • release identification;
  • configuration state;
  • exception or deviation disposition;
  • repository workflow compliance; or
  • other controlled engineering activity.

Where applicable, retained repository evidence shall preserve the relationship between:

  • the repository;
  • the applicable branch;
  • the relevant commit or repository revision;
  • associated tags;
  • the applicable engineering activity;
  • the applicable review or approval record; and
  • the resulting controlled repository state.

Controlled release tags and other repository references used as engineering evidence shall be preserved for the applicable retention period.

Repository history required to reconstruct a controlled engineering state shall not be intentionally deleted, rewritten, or otherwise modified in a manner that materially impairs the required reconstruction.

Where a branch is deleted after successful integration, the commits and repository history required for engineering traceability shall remain recoverable where required.

Where temporary branches, local workflow records, or other transient repository information are no longer required, their disposition shall comply with the applicable repository and engineering-record requirements.

Workflow verification results, exception records, corrective actions, and other repository-control evidence shall be retained where required by the applicable engineering process.

Automated workflow evidence shall remain associated with the applicable repository state, commit, release, or engineering record where such association is required for traceability.

Repository evidence shall be protected against unauthorized modification or deletion where required by the applicable security, configuration-management, or records-management requirements.

Where repository evidence is transferred between systems, the transfer shall preserve sufficient metadata and repository references to maintain traceability.

Where a repository is archived, migrated, replaced, or otherwise removed from active engineering use, the disposition shall preserve the records required for historical reconstruction, auditability, reproducibility, and configuration management.

Retention of repository evidence shall not be interpreted as authorization to retain credentials, secrets, personal information, or other content that is prohibited by applicable security or information-management requirements.

Where retained evidence contains sensitive or restricted information, its storage and access shall comply with the applicable security and information-protection requirements.

Records required to demonstrate compliance with this standard shall remain available for the applicable engineering retention period.

At the end of the applicable retention period, repository records and evidence shall be disposed of only in accordance with the applicable records-retention and engineering-governance requirements.

The disposition of retained repository evidence shall not be used to conceal an engineering change, nonconformity, unauthorized modification, or other controlled repository event.

22. Repository Security and Access Control

Access to controlled Git repositories shall be managed in accordance with applicable engineering governance, security, information-protection, and repository-management requirements.

Repository access shall be granted only to authorized users, systems, services, or automation processes with a defined engineering purpose.

Access permissions shall be appropriate to the intended repository activity and shall follow the principle of least privilege where applicable.

Repository access controls shall distinguish, where applicable, between:

  • read access;
  • development access;
  • commit access;
  • branch-management access;
  • merge or integration authority;
  • release or tag-management authority;
  • repository-administration authority; and
  • other privileged repository operations.

Privileged repository operations shall be restricted to authorized parties.

Credentials, authentication tokens, private keys, access secrets, and other authentication material shall not be intentionally committed to controlled repository history.

Where credentials or secrets are inadvertently committed, the condition shall be treated as a security and repository-control event and shall be dispositioned through the applicable security and engineering processes.

Repository access shall be reviewed and adjusted when personnel roles, engineering responsibilities, repository ownership, or applicable project assignments change.

Inactive, obsolete, or unauthorized access shall be removed in accordance with the applicable access-management requirements.

Where repository access is provided through automation, service accounts, continuous-integration systems, or other non-human identities, the applicable identity shall remain identifiable and its permissions shall be appropriately controlled.

Automated repository operations shall not be granted broader authority than required for their defined engineering function.

Protected branches and controlled repository references shall be subject to applicable access restrictions and repository-protection mechanisms.

Direct modification of controlled branches, tags, or repository configuration shall be restricted where required to preserve engineering governance and workflow controls.

Repository administrators shall not use administrative privileges to bypass required engineering review, approval, traceability, configuration-management, or release-control requirements.

Where emergency privileged access is required to protect repository integrity, security, availability, or controlled engineering activity, the applicable emergency-access process shall be followed.

Emergency access shall remain traceable to the responsible party, affected repository state, reason for access, and resulting repository condition where required.

Repository security controls shall be reviewed when material changes are made to repository architecture, workflow automation, access mechanisms, or engineering governance requirements.

Where a repository security or access-control condition may affect the integrity or traceability of controlled engineering content, the affected repository state shall be reviewed and dispositioned through the applicable engineering and security processes.

Compliance with this clause does not replace or supersede applicable IGB security, identity, access-control, or information-protection requirements.

23. Repository Administration and Maintenance

Controlled Git repositories shall be administered and maintained in accordance with applicable engineering governance, repository-management, security, and configuration-management requirements.

Repository administration shall maintain the operational integrity and continued usability of the repository throughout its engineering lifecycle.

Repository maintenance activities may include, where applicable:

  • repository configuration maintenance;
  • branch-protection maintenance;
  • access-control maintenance;
  • remote configuration;
  • repository hooks and automation;
  • continuous-integration controls;
  • storage and availability management;
  • repository health verification;
  • archival preparation;
  • repository migration; and
  • recovery preparation.

Repository administration shall not establish an authority that conflicts with the canonical engineering repository or applicable higher-level governance.

The canonical repository shall remain identifiable throughout repository administration and maintenance activities.

Repository configuration changes shall be controlled where they may affect:

  • repository authority;
  • engineering workflow;
  • branch protection;
  • access control;
  • release control;
  • traceability;
  • history preservation;
  • repository integrity; or
  • configuration management.

Routine repository maintenance shall not intentionally modify controlled engineering history.

Repository maintenance shall not delete, rewrite, or alter controlled commits, tags, branches, or other repository references unless such action is explicitly authorized by the applicable engineering process.

Repository administrators shall periodically review repository configuration and controls where required to ensure that:

  • required branches remain protected;
  • required access controls remain effective;
  • obsolete permissions are removed;
  • repository remotes remain correctly identified;
  • workflow automation remains operational;
  • required repository references remain accessible;
  • controlled tags remain preserved; and
  • repository configuration remains consistent with applicable engineering requirements.

Repository maintenance shall consider repository availability and recoverability.

Where repository backup, replication, mirroring, or archival mechanisms are used, they shall preserve sufficient repository information to support recovery of controlled engineering states where required.

A repository backup or mirror shall not automatically become an alternative authoritative repository.

Where a repository is migrated to another hosting system, the migration shall preserve, where required:

  • commit history;
  • branch history;
  • tag history;
  • applicable repository metadata;
  • controlled configuration information;
  • traceability information; and
  • the identity of the resulting canonical repository.

Repository migration shall be treated as a controlled engineering activity when it may affect repository authority, history, traceability, security, or configuration management.

Before completion of a repository migration, the resulting repository state shall be verified against the source repository to the extent required by the applicable engineering process.

Where repository maintenance identifies corruption, missing history, inconsistent references, unauthorized configuration, or other material repository conditions, the affected repository state shall be reviewed and dispositioned before normal controlled operation resumes.

Repository recovery activities shall preserve the historical evidence necessary to reconstruct affected engineering states where required.

Repository administration shall not be used to conceal repository-control failures, unauthorized changes, nonconformities, or other engineering events.

Repository maintenance records shall be preserved where required to support engineering traceability, auditability, reproducibility, security review, or configuration management.

The repository shall remain suitable for controlled engineering development, review, integration, release preparation, and historical reconstruction throughout its applicable lifecycle.

24. Repository Workflow Nonconformity and Corrective Action

Where a repository workflow nonconformity is identified, the affected repository state shall be reviewed and dispositioned through the applicable engineering governance, configuration-management, change-control, or repository-management process.

A workflow nonconformity may include, where applicable:

  • deviation from this standard;
  • unauthorized repository configuration changes;
  • unauthorized branch or tag changes;
  • incomplete or missing workflow evidence;
  • failure to satisfy required review or integration controls;
  • uncontrolled modification of protected repository states;
  • loss or impairment of required traceability;
  • failure to preserve controlled repository history; and
  • other conditions that materially affect repository workflow compliance or engineering control.

The affected repository state shall be identified and preserved sufficiently to support investigation, disposition, and corrective action.

Where a workflow nonconformity is identified, the responsible party shall determine, where applicable:

  • the affected repository;
  • the affected branch, tag, commit, or repository state;
  • the nature of the nonconformity;
  • the applicable requirement;
  • the initiating engineering record;
  • the potential engineering impact;
  • the required containment action;
  • the required corrective action;
  • the responsible party; and
  • the required disposition.

Where immediate action is required to protect repository integrity, security, traceability, or controlled engineering activity, appropriate containment measures may be implemented in accordance with the applicable emergency or repository-management process.

Containment shall not be used to conceal or permanently alter the historical representation of the nonconformity.

Nonconformities shall not be concealed by rewriting repository history, deleting evidence, moving controlled tags, deleting required repository references, or otherwise altering the historical representation of the affected engineering activity.

Where corrective action is required, the corrective change shall be implemented as a controlled repository change and shall remain traceable to the identified nonconformity.

Corrective action shall address the identified condition and shall not introduce an unauthorized change to repository authority, configuration, workflow, or controlled engineering content.

Where corrective action modifies repository workflow configuration, branch protection, access control, automation, release control, or other controlled repository behavior, the applicable requirements of Clause 19 and the applicable higher-level change-control process shall apply.

Where the nonconformity results from an approved exception or deviation, the applicable requirements of Clause 20 shall also apply.

Where the nonconformity affects controlled records or repository evidence, the applicable requirements of Clause 21 shall apply.

Where the nonconformity affects repository security or access control, the applicable requirements of Clause 22 shall apply.

Where the nonconformity affects repository administration or maintenance, the applicable requirements of Clause 23 shall apply.

Following corrective action, the resulting repository state shall be verified to confirm that:

  • the identified nonconformity has been addressed;
  • required repository controls have been restored;
  • required traceability has been preserved;
  • required repository history remains recoverable;
  • applicable engineering records remain associated with the affected state; and
  • no unresolved unauthorized or uncontrolled changes remain.

The verification of corrective action shall be supported by objective repository evidence where practical.

Where corrective action is incomplete, ineffective, or introduces a new nonconformity, the affected repository state shall remain under controlled disposition until the applicable condition has been resolved.

The repository shall retain sufficient evidence to demonstrate the identification, disposition, corrective action, and verification of significant workflow nonconformities for the required engineering retention period.

Where this standard conflicts with a higher-level engineering governance requirement, the higher-level requirement shall take precedence.