Git, GitHub, and EC2: A Practical Walkthrough from Local Repo to Live Deployment

Overview

Most Git and deployment issues don’t come from advanced problems, they come from skipped steps, assumptions, and rushed workflows. This post walks through a complete, end-to-end setup using Git, GitHub, and AWS EC2, focusing on how these tools are actually used in team environments.

Rather than abstract theory, this guide shows the exact commands, decisions, and checks involved in moving from a local repository to a live Nginx deployment, and finally to contributing changes through a pull request. Along the way, I’ll point out where things commonly break, why certain steps matter more than they appear, and how to structure work so it’s reviewable, reversible, and safe.

If you already use Git and Linux, this is meant as a practical reference and a reinforcement of good habits such as clean commits, verified state, isolated branches, and predictable deployments,because those are the details teams rely on long after the tools stop feeling new.

• Initializing the Project and Git Repository
• Configuring Git Identity (Local vs Global)
• Verifying Repository State Before Working
• Creating Project Files
• Adding Starter Content
• Tracking and Staging Files
• Creating the First Commit
• Making a Controlled Change
• Deploying to EC2 with Nginx
• Branching Workflow: Adding a Contact Page
• Verifying Branch Isolation
• Merging the Feature Branch
• Inspecting Commit History
• GitHub Collaboration: Forks and Remotes
• Syncing with Upstream
• Creating a Pull Request to Upstream
• Final Notes

Initializing the Project and Git Repository

First, create your project directory and initialize Git.

To confirm Git is actually tracking this directory:

You should see a .git folder. Without it, Git isn’t tracking anything,no commits, no branches, no history. Every Git workflow depends on this being present.

Configuring Git Identity (Local vs Global)

Local (Repo-Specific) Identity

In professional environments, repositories often require specific commit identities. I configured a local Git identity for this project.

This ensures commits in this repo don’t accidentally use a different identity.

Global Identity

For personal or non-restricted repositories, a global identity is convenient.

Local config always overrides global config. That precedence matters more than people think.

Verifying Repository State Before Working

Before creating files, always confirm:

• You’re in the right directory
• Git is active
• You’re on the expected branch

Most Git mistakes come from skipping this check.

Creating Project Files

I created two basic frontend files:

Verify they exist.

This might seem trivial, but confirming file creation avoids silent errors,especially when working across multiple terminals.

Adding Starter Content

I copied starter HTML and CSS from a remote repository and pasted it into my local files using VS Code. This mirrors real-world scenarios where teams provide templates or base layouts.

At this stage, nothing is tracked yet.

Tracking and Staging Files

Check the current status:

You should see both files listed as untracked.

Stage the files:

verify staging

Staging is how you control exactly what goes into a commit. Professionals don’t commit blindly.

Creating the First Commit

Create a clean initial commit:

Verify commit history

Clear commit messages make history readable and useful months later.

Making a Controlled Change

I modified the homepage content in index.html, then checked status:

Stage only the modified file:

Commit the change:

Multiple small commits are easier to review and easier to roll back.

Deploying to EC2 with Nginx

SSH into the Server

Note-chi.pem is the name of my key.pem
Install and Verify Nginx

Copy Files from Local Machine

Since the files weren’t zipped, I transferred them individually:

Move Files to Nginx Web Root

Set Permissions

Validate Configuration

Verify Locally on Server

Then access the site in a browser:

Branching Workflow: Adding a Contact Page

Let's talk about branching workflows!

Create and Switch to Feature Branch

Add New File contact.html, edit with VS code editor not nano and Commit

Update index.html Separately by adding the contact page link

Each logical change gets its own commit.

Verifying Branch Isolation

Switch back to main branch:

contact.html should not exist here. This confirms isolation before merging.

Merging the Feature Branch.

Verify files exist and render correctly in the browser.

Inspecting Commit History

If the history looks linear, that’s likely due to a fast-forward merge. This is expected unless --no-ff is used.It should be in a graph format.

GitHub Collaboration: Forks and Pull Requests

Add Remotes

Verify

Sync with Upstream

Push Feature Branch

Then open a pull request from your fork to the upstream repository.

Creating a Pull Request to Upstream

Once the feature branch is pushed to your fork, the final step is opening a Pull Request (PR) to the upstream repository. This is where your changes are reviewed and (if approved) merged.

Verify Your Branch Is Pushed

First, make sure your feature branch exists on GitHub:

The -u flag sets the upstream tracking branch so future pushes don’t require extra arguments.

Open the Pull Request on GitHub

1.Go to your fork on GitHub

1. Switch to your feature branch (feature/contact-page).

2. Click Compare & pull request

   (If you don’t see it, go to Pull Requests → New Pull Request manually.)

Confirm PR Target Settings

This part matters more than people think. Double-check everything:

• Base repository: pravinmishraaws/devops-micro-internship-interviews
• Base branch: main
• Head repository: your fork
• Compare branch: feature/contact-page

A surprising number of PRs fail review simply because they target the wrong repo or branch.

Add a Clear PR Title and Description

PR Title-docs: add contact page
PR Description-This PR adds a contact page and links it from the homepage.
Changes were made on a feature branch and verified before merge.
The goal here isn’t verbosity ,it’s clarity. Reviewers should understand what changed and why in under 10 seconds.

Create the Pull Request

Click Create Pull Request.

At this point:

• Your code is isolated
• The change is traceable
• Reviewers can comment line-by-line
• The main branch stays protected

This is the core of how teams collaborate safely at scale.

Why This Step Matters in Practice

In theory, PRs are just a formality.

In practice, they’re where most quality control happens.

PRs are used to:

• Catch unintended changes
• Enforce standards
• Share context
• Prevent direct pushes to protected branches

Teams that skip or rush PRs usually pay for it later — in broken releases or messy rollbacks.

Final Thought

From local commits → feature branches → deployment → pull requests, this workflow isn’t about tools. It’s about reducing risk while moving fast.

Once you internalize this flow, you stop “using Git” and start working with teams.