Holding all Cantilever code and managing the development workflow
GitHub is the industry standard code storage platform.
📏 Rules for GitHub
- 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
- 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.
- 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.