Skip to main content

Engineering Git & CI/CD Policy

Introduction​

These guidelines define how engineers at Sadeem Informatique design systems, write software, collaborate, and operate.
They ensure consistency, scalability, maintainability, security, and long-term reliability.
These principles apply to all engineers, all repositories, and all environments.

1. Git Basics​

All developers must be familiar with core Git commands to collaborate effectively and maintain repository health.

Common Commands​

  • git add <file> – Stage changes for commit.
  • git commit -m "message" – Commit staged changes with a message.
  • git push – Push local commits to the remote branch.
  • git pull – Fetch and integrate changes from the remote branch.
  • git merge <branch> – Merge another branch into your current branch.
  • git rebase <branch> – Reapply commits on top of another base branch.
  • git checkout <branch> – Switch to another branch.
  • git status – See the current branch status and changes.
  • git log – View commit history.
Best Practices
  • Commit often with meaningful messages.
  • Avoid committing secrets or large binary files.
  • Use git pull --rebase to keep your branch up to date with dev.
Avoid destructive commands
  • Never use git push --force on shared branches like dev or main.
  • Avoid rebasing public branches unless coordinated with the team.

2. Branching Strategy​

Never push directly to main

Direct pushes to the main branch are strictly forbidden except during controlled release procedures.

Local Branch Creation Rules​

  • Developers should never create a main branch locally.
  • Always start with the existing dev branch.
  • Local branches should be created from dev only:
    • feature/<name>
    • bugfix/<name>
    • hotfix/<name>
  • This ensures main is only updated via controlled merges and CI/CD pipelines.

Single-developer projects​

  • The developer works directly on the dev branch.
  • Changes must still go through Pull Requests before merging to main.
  • main is only updated when the work is stable, tested, and CI passes.

Multi-developer projects​

  • All developers must branch from dev.
  • Developers open Pull Requests targeting dev.
  • The Team Lead reviews commits, requests fixes if needed, and merges approved work into dev.
Promotion to production

Only the Team Lead promotes validated changes from dev to main, and only after CI passes and the branch is stable.

3. Pull Request Requirements​

Every Pull Request must include:

  • Clear and descriptive title
  • Short explanation of what changed and why
  • Reference to the related ticket/task
Keep PRs reviewable

Small, focused PRs are easier to review and reduce risk.

  • At least one approval is required before merging.
  • Do not merge your own PR unless explicitly approved for emergencies.
  • PRs must not be merged if checks are failing.

4. CI/CD Awareness​

After pushing to dev, developers must verify that pipelines complete successfully.

If the pipeline fails:

  • The developer must investigate immediately.
  • If the failure is unclear or infrastructure-related, contact the DevOps team immediately.
Never ignore failing CI

Pull Requests with failing checks must not be merged.

5. Secrets & Sensitive Data​

Never commit:

  • API keys
  • passwords
  • certificates
  • private tokens
  • .env files containing credentials

Sensitive files must:

  • Be listed in .gitignore
  • Remain untracked locally

Secrets must be stored in:

  • environment variables
  • secret managers
  • CI/CD secure variables

.env.example Tracking​

  • A .env.example file must be tracked in Git.
  • It should include all environment variable keys without real credentials.
  • This ensures developers know what variables are required without exposing secrets.

Any accidental secret commit must be reported immediately and rotated.

6. Commit Standards​

Commit messages must be clear and meaningful.

Use structured prefixes where possible:

  • feat: new feature
  • fix: bug fix
  • refactor: internal change
  • docs: documentation change

Avoid vague messages like update, changes, or fix stuff.

Each commit should represent one logical change.
Clean up commit history before merging if necessary (squash/rebase).

7. Synchronization Practices​

  • Pull or rebase from dev frequently to avoid large conflicts.
  • Resolve conflicts locally before pushing.
  • Always test locally after resolving conflicts.

8. Code Quality Expectations​

Do not push code that:

  • does not compile
  • breaks tests
  • includes temporary debug statements
  • contains commented-out legacy blocks

Run tests and linters locally when possible before pushing.

9. Branch Protection Rules (Mandatory)​

main and dev must be protected branches.

  • Force pushes are not allowed on shared branches.
  • CI checks must pass before merging.
  • Review approval is required before merging.

10. Dependabot & Vulnerability Management​

  • Enable Dependabot in all repositories.
  • Dependabot must scan for:
    • Critical vulnerabilities (e.g., RCE, remote code execution)
    • Security patches for dependencies
  • Developers must review Dependabot alerts promptly and update dependencies as needed.
  • PRs fixing vulnerabilities must go through the standard review and CI process.

11. Responsibility Principle​

Whoever pushes code is responsible for:

  • build health
  • fixing breakages
  • communicating issues early

Engineering stability is a shared responsibility across developers and DevOps.

End of Policy