Overview

GitHub is the industry standard code storage platform.

📏 Rules for GitHub

✅ Do…

• Keep a repo for every active project in GitHub
• Use GitHub Actions to implement CI/CD workflows
• Use Pull Requests for all changes
• Keep our GitHub team organized cleanly by client and project

🚫 Don‘t…

• Put Cantilever code into Public repositories

Client and Repo Management

Each client should get its own sub-group within the Cantilever team:

• Each codebase should have an independent repo within the client sub-project.
• Projects should contain:
  • Source files, not built files.
    • This means that if a build process generate CSS from LESS files, that build process should take place locally, or on the production server as part of a deployment process, but those built files should not be in the repo
  • Directories for environment-specific content, not the content itself.
    • The best example is for Images that are uploaded through the WordPress CMS. The directory of /wp-content/wp-uploads should be present and committed to the repo, but the contents of that directory should not
  • Examples of environmental config files, not the files themselves.
    • For example, we would want a .env.sample file in the repo that would contain example and placeholder credentials, but we would not want the .env file itself in the repo.
  • A well-managed .gitignore file
  • A README that outlines how to build the project in a local environment
• The main or master branch should be the default branch for the repo.
• Both the Master/Main and Develop branches should be protected, writable by developers and maintainers, and protected from force-pushes.
• An active Deploy Key for the production server. If your repo is installed directly via Forge onto the server, this will be done automatically. If not, here are the docs.

User Management

All Core Team members who have anything to do with code should be in the Cantilever Development team. Contributors should be added on a per-repo level.