Git Version Control: separate source history from a safe deployment

Git stores source history. A repository update is not automatically a complete deployment: dependencies, assets, environment configuration and database migrations may still be required.

Prepare the repository

1. Choose an appropriate repository location and confirm who can access it.
2. Keep .env files, private keys, uploads containing personal data and database exports out of version control.
3. Connect the intended remote using the host’s supported credential method and verify its ownership.
4. Review the branch or commit that will be deployed. Do not pull an unknown branch directly into production.
5. Build and test using the application’s documented process before changing the live release.

Deploy as a controlled operation

Back up the database before migrations and distinguish a code rollback from a data rollback. Deploy generated assets and dependencies that match the same release. Keep private source folders outside the public root where possible, and block web access to repository metadata.

Do not assume a secret is safe after deleting it from the newest commit; it can remain in history. Replace exposed credentials through the appropriate secure process. Use separate deployment access rather than sharing a personal primary account. After deployment, check the public site, admin login and important write workflows, not only the Git status.