← Back to Git Course | Chapter 9: CI/CD & DevOps | Lesson 4 of 5

Git Deployment Workflows

A deployment workflow is a moving walkway that takes your saved code all the way to the live website with no carrying by hand.

In this page:

  1. What is a Deployment Workflow?
  2. Deploying via SSH
  3. Deploying to Cloud Providers
  4. Environment-Specific Branches
  5. Rolling Back Deployments
Syntax
bash 
git push remote_name branch_name
rsync -avz -e ssh ./build_dir/ user@server:/path/to/app/

What is a Deployment Workflow?

A deployment workflow is the automated pipeline that takes a commit from your repository all the way to a running production server, replacing manual file copying or command-running with a repeatable, auditable process.

Example: What is a Deployment Workflow?

bash 
git push origin main
# triggers automated build and deploy

Deploying via SSH

Deploying over SSH means your CI job authenticates with a private key, connects to your server, and copies the updated files (often via rsync or scp) directly — a straightforward option when you control the server yourself and don't need a managed platform's extra tooling.

Example: Deploying via SSH

bash 
rsync -avz -e ssh ./dist/ user@server:/var/www/app/

Deploying to Cloud Providers

Platforms like Vercel, Netlify, or AWS Amplify connect directly to your GitHub repository and redeploy automatically on every push to a chosen branch, handling the build, hosting, and rollback machinery for you — no custom deploy script required.

Example: Deploying to Cloud Providers

bash 
git push origin main
# Vercel/Netlify auto-deploys on push

Environment-Specific Branches

Mapping branches to environments — dev deploys to a sandbox, staging to a pre-production copy, main to the live site — means merging into a branch is itself the deploy trigger, and nobody can accidentally ship unfinished work by merging into the wrong place.

Example: Environment-Specific Branches

bash 
git checkout -b staging
git push origin staging

Rolling Back Deployments

A rollback re-deploys a previous, known-good commit in place of the broken one — usually by re-running the deploy workflow against an earlier commit hash rather than force-pushing history, which keeps the real timeline of what happened intact.

Example: Rolling Back Deployments

bash 
git checkout a1b2c3d
# re-deploy this known-good commit
Related Topics

Git Workflows (GitFlow) · Git Docker Integration · GitHub Pages · Git CI/CD Pipeline Basics

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Deploying directly from a local machine instead of the pipeline, so what is running does not match main.
  2. Storing the SSH private key in the repository instead of in the CI secrets.
  3. Deploying on every push to any branch, when only main or tagged releases should reach production.
🔒

Chapter Quiz — Complete all 5 topics to unlock

0/5 topics done

Complete these topics first:

← Previous Lesson Git Docker Integration Next Lesson → GitHub Pages

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.