Before you begin
Confirm the latest working code, required credentials, external services, and rollback path.
Keep the current production environment available until the new release is verified.
Use a controlled deployment process
GitHub gives your project a durable history outside any single builder session.
Before connecting
1. Decide which repository will be the source of truth.
2. Confirm whether the project should use the main branch or a separate migration branch.
3. Save environment variables and secrets outside the code.
4. Keep the current production app unchanged while testing.
5. Make a small test change and verify the deployment path.
6. Decide who can merge changes.
For an existing live app, use a copy or branch. Do not point production at the new build until the imported version has been tested.
After the initial setup, future releases should follow a repeatable path: make a change, review it, test it, merge it, and deploy it.
The goal is not merely to “have the code.” The goal is to know which version is live, who changed it, and how to recover if a release fails.
Common mistakes
Connecting the wrong repository or branch.
Committing credentials or secrets to GitHub.
Assuming the repository alone contains every environment dependency.
Frequently asked questions
Can I keep my current app live during deployment work?
Yes. A separate environment, copy, or branch lets you test the new version while the current application remains available.
What should a rollback plan contain?
The prior working version, the data and configuration changes involved, the person authorized to roll back, and the conditions that trigger the rollback.