Forem: Chimaobi Prince

Insightful article for beginners. Don’t sleep on it!

Chimaobi Prince — Mon, 20 Apr 2026 07:17:06 +0000

MLH Team for Major League Hacking (MLH)

Apr 17

Learning to Code: A Beginner's Guide for the AI Era

#ai #webdev #beginners

Comments

10 min read

How GitHub Pull Requests in VS Code Improved My Open-Source Workflow

Chimaobi Prince — Thu, 08 Jan 2026 17:47:15 +0000

If you contribute to open source, work in a collaborative engineering team, or operate in cloud and CI/CD-driven environments, you’ve probably felt this pain while reviewing Pull Requests:

Browser → VS Code → Browser → Terminal → Browser

I didn’t realize how much this constant context switching was slowing me down until I changed where I review Pull Requests. After adopting the GitHub Pull Requests & Issues extension in VS Code, PR reviews stopped being a distraction and became a first-class DevOps quality gate in my workflow.

In this post, I’ll share:

How reviewing GitHub Pull Requests inside VS Code improved my daily workflow

Why this matters in cloud-native and CI/CD environments

Who should consider using this setup

The Problem: Context Switching Kills Focus

Before using the extension, my Pull Request review process looked like this:

Open a Pull Request in the browser
Read code diffs
Switch to VS Code to inspect files
Go back to GitHub to comment
Repeat

This resulted in:

Lost focus during reviews
Slower feedback cycles
Harder code comprehension
Increased mental overhead

In modern DevOps workflows, Pull Requests are not just collaboration tools — they are control points that sit directly in front of CI/CD pipelines. Any friction here compounds quickly.

Pull Requests as a DevOps Control Point in CI/CD Pipelines

In cloud and DevOps environments, every Pull Request can trigger:

Continuous integration pipelines
Automated tests and linting
Security and dependency checks
Deployment workflows

This means Pull Requests are often the last human checkpoint before automation takes over.

For engineers aiming to grow into DevOps or cloud roles, mastering efficient Pull Request workflows is essential. Improving how we review PRs directly impacts:

Deployment speed
System reliability
Production stability

Treating Pull Requests as first-class workflow checkpoints is no longer optional.

What Is the GitHub Pull Requests & Issues Extension?

The GitHub Pull Requests & Issues extension brings GitHub directly into VS Code.

With it, you can:

Review Pull Requests inside the editor
Add inline comments with full code context
Checkout PR branches locally
Create and manage Pull Requests
Track assigned issues

All without leaving your development environment.

☁️ Reviewing Pull Requests with Cloud-Native Context in VS Code

In cloud-native systems, small changes can have an outsized impact — especially when services run across multiple environments.

Reviewing Pull Requests directly inside VS Code allows me to analyze changes with full system context, not just isolated diffs. I can explore repository structure, understand service boundaries, and assess how a change might affect runtime behaviour.

This is especially useful when PRs include:

Configuration files
Environment-specific settings
API integrations
Changes affecting scalability or availability

By reviewing these changes in the editor, I’m better positioned to catch issues that could lead to runtime errors, misconfigurations, or unstable deployments.

⚙️ Checking Out Pull Requests Locally as a DevOps Quality Gate

One of the most valuable features of the extension is the ability to checkout Pull Request branches directly inside VS Code.

With a single click, I can pull the contributor’s branch and run the project locally, turning PR review into an early quality gate instead of a passive check.

In practice, this allows me to:

Validate changes before they reach CI/CD pipelines
Catch issues that could break automated builds or deployments
Test application behavior in a production-aware environment
Review changes to configuration files or environment variables

For example, while reviewing a PR that modified environment variables for a service, checking out the branch locally helped me catch a missing default value that would have caused a runtime failure in staging — something CI wouldn’t have flagged until much later.

This supports a shift-left DevOps approach, catching issues earlier in the development lifecycle before they consume CI resources or cause failed deployments.

✍️ Writing Better, More Actionable Feedback

Because I review Pull Requests inside VS Code:

Feedback is clearer and more specific
Comments are written with full code awareness
Suggestions are easier to act on

Instead of vague feedback like:

“This might break something.”

I can provide targeted guidance such as:

“This function doesn’t handle null values — consider adding a guard clause to prevent runtime errors.”

Clear, actionable feedback improves collaboration and code quality for everyone involved.

The Biggest Benefits I Noticed

After fully adopting this workflow, I noticed:

✅ Less context switching
✅ Faster Pull Request reviews
✅ Better focus and code understanding
✅ Improved collaboration
✅ Higher confidence when approving or requesting changes

It didn’t just improve my speed, it improved the quality of my contributions.

Who Should Use This Extension?

I’d especially recommend it for:

Open-source contributors
Remote engineering teams
Backend developers
Cloud and DevOps engineers managing CI/CD workflows
Anyone who spends most of their time in VS Code

If VS Code is already your primary development environment, this extension is a simple productivity win.

Tips to Get More Value from It

A few small optimizations that made a big difference for me:

Enable Pull Request notifications inside VS Code
Use the Files Changed view instead of raw diffs
Combine it with GitLens for deeper commit insights
Use Pull Request templates to standardize reviews

CI/CD Diagram: Pull Requests in VS Code as an Early Quality Gate

Developer
↓
Feature Branch
↓
Pull Request (VS Code)
├── Code Review
├── Local Testing
├── Config Validation
↓
CI Pipeline
├── Build
├── Tests
├── Security Checks
↓
Merge
↓
Deployment (Cloud)

Pull Requests reviewed in VS Code act as an early quality gate, reducing CI failures and improving deployment reliability.

Final Thoughts

If Pull Requests are part of your daily workflow, especially in cloud-native or CI/CD-heavy environments, optimizing how you review them matters more than you might think.

Treat Pull Requests not as a checkbox, but as an engineering control point.
Small workflow changes can deliver an outsized impact on reliability, collaboration, and deployment confidence.

The "Rescue Mission": How to Lead a Team of Git Beginners Without Losing Your Mind

Chimaobi Prince — Mon, 15 Dec 2025 05:18:27 +0000

We’ve all been there. You are working on a university project. You have a team of five. You are the designated "Tech Lead", handling the backend and CI/CD. The rest of the team are enthusiastic beginners handling the frontend.

The energy is high, the Figma designs look great, but then... the Git conflicts start.

In this post, I want to share a specific workflow I use to save my team from broken code and the lessons I learnt about using AI for code reviews in a beginner environment.

The Scenario: "I Can't Wait"
It’s 11:45 PM. The sprint review is tomorrow morning. The Frontend Rookie finally sends the pull request titled 'Final Login Fix REAL v3'.

I open the PR, hoping for a miracle.

I look at the code. There’s a missing semicolon on line 42, they accidentally hardcoded their database password as ILovePizza123 instead of using the config file, and for some reason, they left echo "I AM HERE 1"; and echo "WHY IS THIS NOT WORKING"; scattered across the entire script.

I could request changes and wait for them to wake up, figure it out, and push again. But they are probably sleeping the sleep of the innocent.

I sigh, crack my knuckles, and decide to launch a Git Rescue Mission.

The Workflow: Fixing a Teammate's Branch (The Right Way)
Many beginners think you have to clone the repo into a separate folder to fix a friend's code. Please don't do that.

I use the GitHub Pull Requests and Issues extension in VS Code. It turns "fixing their code" into a 3-step process:

Checkout: I right-click their PR in the VS Code sidebar and select Checkout Pull Request.

The Localhost Test: Now, my local environment (Laragon/Docker) is running their code. I can see the "I AM HERE 1" message on my browser immediately.

The Fix & Push: I delete the debug echoes, fix the password, commit it, and hit "Sync".

Magic: This pushes the code directly to their branch on GitHub and updates the PR automatically.

I merge it. The site is saved. Everyone is happy. Until...

The Trap: The "Gemini" Conflict
This is where things get messy. As a lead, I use AI tools (like Gemini) to review code. I see a block of spaghetti HTML, I ask Gemini to refactor it, and I paste the clean version into the branch and push it.

Meanwhile, The Rookie is still working on their laptop.

They didn't know I fixed their code. They realize they forgot to capitalize a button, change one letter on their (now old) version, and push. Git explodes.

We now have a merge conflict. My "Clean AI Code" vs. their "Old Code with a Typo Fix".

The Solution: The "Base & Borrow" Technique
So, how do you solve this "logic vs. design" conflict?

If you click "Accept Current Change" (Your Code), you delete their CSS tweaks. If you click "Accept Incoming Change" (Their Code), you bring back the bugs.

I learnt the hard way that you cannot just click a button. You have to use the Base & Borrow technique in VS Code:

The Base (Your Logic): I start by accepting my clean code as the base. This ensures the backend logic and syntax are correct.

The Borrow (Their Design): Before I hit save, I look at their code in the "Incoming Change" window. Did they change a class to btn-danger? Did they fix a typo in the header?

The Patch: I manually copy only those design tweaks and paste them into my clean block.

It takes 30 seconds longer, but it ensures we get the best of both worlds: My Working Logic + Their Polished Design.

3 Rules to Survive the Chaos
After fighting these fires for weeks, I realized that technology wasn't the problem—communication was. Here are the rules we established to stop the bleeding:

1. The "Traffic Light" System
Green Light: Before you write a single line of code, run git pull.

Yellow Light: If you are working on a file, say it in the chat ("I'm on login.php").

Red Light: If I type "FREEZE", stop typing. It means I'm fixing the server.

2. The "Stop Typing" Command
Before I enter a teammate's branch to perform a rescue fix, I send a message to the group chat:

"I am entering the [Login-Feature] branch to fix a bug. STOP working on it. Hands off the keyboard. Do not push until I say 'GO'."

3. The "Pull First" Mantra
If I do push a fix to a teammate's branch, I make them swear by this rule: Before you write a single line of code today, run git pull.

If they don't pull my fixes down to their laptop first, everything they write next is guaranteed to cause a conflict.

Conclusion: Just Because You Can, Doesn't Mean You Should
Even though I mastered the "Base & Borrow" technique, my biggest lesson was actually about restraint.

It is tempting to fix every bug yourself because it's faster. But if you fix every PR manually, your team never learns.

Sometimes, the best move isn't to checkout the branch and fix it. The best move is to leave a comment: "Line 45 is broken. You forgot the semicolon. You fix it."

It takes longer, but it prevents the conflicts—and it turns your teammates into better developers.

How to deploy a PHP application in InfinityFree

Chimaobi Prince — Tue, 25 Nov 2025 08:08:21 +0000

Step 1: Account Setup
Sign up and verify: Create an account on the InfinityFree website and verify your email address.
Create a Hosting Account: Once signed in, navigate to the client area and click "Create Account".
Choose a Domain: Select a free subdomain or use a custom domain, then click "Create Account".
Finish Setup: After the account is created, click "Finish". Note down your account details, including the username, password, and MySQL details, as you will need them later.

Step 2: Upload Project Files
Access Control Panel: From your client area, click "Control Panel" (cPanel). You may need to click "I Approve" to proceed.

Open File Manager: In the cPanel, find and click "Open File Manager".
Navigate to htdocs: Inside the file manager, open the htdocs folder. This is the root directory for your website's public files.
Upload Files:
Delete any default files present in the htdocs folder.
Click the "Upload" button. You can upload individual files or a ZIP archive of your entire project. Uploading a ZIP file and extracting it on the server is often easier for large projects.

*Step 3: Set up the Database *
If your project uses a MySQL database, follow these steps:
Go to cPanel: Return to the cPanel and find the "Databases" section.
Create Database: Click on "MySQL Databases". Give your new database a name (e.g., demo) and click "Create Database".
Access phpMyAdmin: Click the "Admin" button next to your new database. This opens phpMyAdmin.

Import Database: In phpMyAdmin, go to the "Import" tab. Click "Choose File", select your local .sql database file, and click "Go" to upload it.

Step 4: Configure Your PHP Project
Edit Configuration File: In the File Manager, locate your database configuration file (e.g., config.php, db.php, or similar). Open it for editing.
Update Credentials: Change the localhost database credentials to the new InfinityFree credentials. You can find the required details (DB Hostname, DB Name, DB Username, DB Password) in your client area under "MySQL Details":
DB Server (Hostname): This will be a specific hostname, not localhost.
DB Username: A unique username generated by InfinityFree.
DB Password: The password you set for the hosting account (or database password if you set one separately).
DB Name: The name you provided when creating the database in cPanel.
Save Changes: Save and close the configuration file.
Your PHP project should now be deployed and accessible via the domain name you selected in Step 1. You may need to clear your browser cache to see the changes.