From Local Git to Live EC2 Deployment — My DevOps Week 3 Journey (DMI Cohort 2)
Author: Manjay Verma
Program: DevOps Micro Internship (DMI) — Cohort 2
Week: 3 — Git & GitHub Workflow
🌟 Introduction
As part of the DevOps Micro Internship (DMI), Week 3 focused on mastering Git, GitHub collaboration workflows, and deploying a real static website on AWS EC2 using Nginx.
This week transformed my understanding of:
Version control systems
Branching strategies
Open-source contribution workflow
Production-style deployment on Linux servers
This blog documents my complete hands-on journey.
Part 1: Setting Up Git Locally
Created a Project Repository
I created a project named:
CodeTrack
Initialized Git:
git init
🔍 What I Learned
Git tracks changes using snapshots.
.git directory stores commit history.
Version control prevents accidental loss of code.
🔹 Part 2: Git Identity Configuration
Configured Git identity locally and globally:
git config user.name "Manjay Verma"
git config user.email "..."
🔍 Key Learning
Local config applies per repository.
Global config applies system-wide.
Enterprise environments prefer local config.
🔹 Part 3: Staging, Committing & Clean History
Created:
index.html
style.css
Performed staged commits:
git add .
git commit -m "Initial commit: Add index and style files"
Then made a small change and committed separately.
🔍 What I Learned
Clean commit messages improve collaboration.
Small commits are easier to review.
Commit history tells the project story.
🔹 Part 4: Branching Workflow (Feature-Based Development)
Created feature branch:
git checkout -b feature/contact-page
Added:
contact.html
Updated index.html
Merged back to main:
git merge feature/contact-page
🔍 Key Learning
Feature branches isolate development.
Main branch remains stable.
This is industry-standard Git workflow.
🔹 Part 5: GitHub Collaboration Workflow
Steps followed:
Forked upstream repository
Cloned my fork
Added upstream remote
Created feature branch
Pushed to origin
Created Pull Request
git remote add upstream
git push origin feature/update-readme
🔍 What I Learned
Difference between origin and upstream
Why forks are required in open-source
How Pull Requests enable collaboration
🔹 Part 6: Deploying to AWS EC2 (Production-Style)
Launched instance in:
Asia Pacific (Mumbai)
Using:
Ubuntu 22.04
t2.micro (Free Tier)
Security Group (SSH + HTTP)
Connected via SSH:
ssh -i codetrack-key.pem ubuntu@
Installed Nginx:
sudo apt update
sudo apt install nginx -y
Deployed static site to:
/var/www/html/
🌍 Live Deployment Result
My website is now live on AWS EC2 using Nginx.
This gave me hands-on experience with:
Linux server management
Security Groups
Public IP configuration
Service management using systemctl
🔥 Production-Level Checks Performed
sudo systemctl status nginx
curl localhost
netstat -tulpn | grep 80
🔍 What I Learned
Always verify services are running.
Always test port bindings.
Deployment is not complete until verified.
🚧 Challenges Faced
❌ SSH Connection Timeout
Fixed by correcting Security Group inbound rules.
❌ GitHub 403 Permission Error
Fixed by properly forking repository and setting correct origin.
❌ "origin does not appear to be a git repository"
Fixed by adding remote URL.
Each issue strengthened my troubleshooting skills.
🎯 Key DevOps Concepts Practiced
Git internals
Branching strategy
Clean commit hygiene
Fork & PR workflow
Linux server configuration
Nginx deployment
Security best practices
🧠 My Biggest Takeaway
DevOps is not just about tools — it’s about:
Clean workflow
Reproducibility
Verification
Security awareness
Professional documentation
This week moved me closer to real-world DevOps engineering practices.
🚀 What’s Next?
Next goals:
Automate deployment using CI/CD
Use GitHub Actions
Attach custom domain
Deploy using Docker
🙌 Acknowledgment
Thanks to the DevOps Micro Internship (DMI) program and mentors for structured hands-on guidance.
Top comments (0)