Overview

📏 Rules for GitHub

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.
• Subgroups and Projects should have icons that match the client and 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