Profile Applicability:
 Level 1

Description:
 Require that all commits merged into the main branch follow a linear history without merge commits, typically enforced through rebase or squash merging strategies. This ensures a clean, understandable commit history that simplifies auditing, debugging, and code review processes.

Rationale:
 Maintaining a linear history reduces complexity in the repository’s commit graph, making it easier to trace changes, identify issues, and audit code evolution. It prevents confusing merge commits and helps maintain consistency in the codebase’s version history.

Impact:
 Pros:

  • Simplifies commit history and improves readability.

  • Facilitates easier debugging and audit trails.

  • Enhances collaboration with clear change lineage.

Cons:

  • May require additional developer discipline to rebase branches.

  • Could cause conflicts that need resolution during rebasing.

Default value:
 By default, repositories may allow merge commits, resulting in a non-linear commit history.

Audit:
 Review merge strategies configured in the repository settings. Inspect commit history to ensure merges follow a linear pattern without unnecessary merge commits.

Remediation:
 Configure repository branch protection rules to enforce rebase or squash merges only. Educate developers on linear history best practices and provide guidelines on rebasing workflows.

References:

  1. GitHub About Merge Methods: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-merge-methods-on-your-repository

  2. Atlassian Git Tutorials - Understanding Merge Strategies: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

  3. CIS Controls v8, Control 6 - Maintenance, Monitoring, and Analysis of Audit Logs: https://www.cisecurity.org/controls/maintenance-monitoring-and-analysis-of-audit-logs/