Github

A code repository is necessary for almost all projects, to ensure that collaboration and version control can be handled smoothly, and so that code isn’t lost if equipment fails or a team member leaves a project that in process.

If you touch code for a website, there should be a Github Repository for it, and you should be committing and pushing to it regularly. Ask the PM or Solutions Manager on your project to get you added as a collaborator on the repo.

What to include or ignore in the repo

Include:

1. Custom Themes and Plugins: Any custom themes or plugins developed for the project should be included in the repository. This makes it easy to track changes, review code, and collaborate on development.
2. Configuration Files: Include configuration files that are crucial for setting up the project in a development environment, such as wp-config.php (with sensitive information removed), .htaccess, and any custom setup scripts.
3. Documentation: Documentation is key to understanding and maintaining the project. Include a README.md with project setup instructions, plugin and theme details, and any other relevant information.

Ignore:

1. Core WordPress Files: There’s no need to include the core WordPress files in your repository. These can be easily installed via the official WordPress download or with a package manager like Composer.
2. Sensitive Information: Always exclude files containing sensitive information (e.g., wp-config.php with actual database credentials, API keys). Use .gitignore to ensure these files are not accidentally committed.
3. Node Modules and Vendor Directories: For projects that use Node.js or Composer dependencies, ignore the node_modules and vendor directories. Instead, include a package.json or composer.json file so that these dependencies can be installed by others setting up the project.

When to commit and push to the repo?

Commit Often

1. After Completing a Logical Unit of Work: Ideally, developers should commit their changes to the repository after completing a logical unit of work. This could be anything from fixing a bug, adding a new feature, making a configuration change, or updating documentation. The key is that the unit of work is self-contained and doesn’t break the project.
2. Before Starting Something New: It’s good practice to commit your changes before starting a new task. This ensures that changes are compartmentalized and makes it easier to track the progress of different features or fixes.

Pushing to the Repository

1. After a Series of Commits: Pushing after a series of commits makes sense, especially when those commits collectively represent a significant change or addition to the project. This approach keeps the remote repository updated without overwhelming it with every small change.
2. When Work is Ready to Share: Push your changes to the remote repository when you’re ready for other team members to see, review, or collaborate on your work. This could be at the end of the day or when a feature branch is ready for integration or review.
3. Before Pulling Changes: It’s advisable to push your current work before pulling changes from the remote repository, especially if you expect the pulled changes to potentially conflict with your local changes. This ensures your work is safely stored remotely before attempting to merge or rebase with updates from other team members.
4. At Least Once a Day: For ongoing work, committing & pushing at least once a day is a good baseline. It ensures that changes are regularly being backed up and makes it easier for team members to stay updated with the project’s progress.