This post kicks off my DevOps Micro Internship (DMI) DevOps Diary — a series where I document my hands-on journey learning how real DevOps teams work in production-style environments.
I’m starting with something foundational but often misunderstood open-source collaboration using Git and GitHub.
What this first entry is about
For this assignment, I didn’t build a feature or deploy an app. Instead, I focused on process— the same workflow engineers use daily when collaborating on shared codebases.
Here’s what I worked through:
Forked an upstream repository (no direct write access)
Cloned my fork locally
Configured origin (my fork) and upstream (original repo)
Created a feature branch instead of working on main
Made a single, scoped documentation change
Synced with upstream to avoid conflicts
Opened a Pull Request back to upstream
Small change. Real workflow.
Why these matters in DevOps
From a DevOps perspective, this wasn’t just about Git commands — it was about risk reduction and system safety:
Forks protect shared repositories
Feature branches isolate changes
Clean commits simplify reviews
Pull Requests enforce accountability
These same principles show up later in infrastructure-as-code, CI/CD pipelines, and production deployments.
What I learned
Open-source contribution is structured and repeatable
Collaboration skills are as important as technical skills
Clean Git history is a professional signal, not a nice-to-have
What’s coming next in the series
This assignment lays the groundwork for what’s next in DMI:
automation, deployment workflows, and production-level DevOps practices.
Each diary entry will build on the last — moving from how teams collaborate to how systems are deployed, monitored, and maintained.
🔗 GitHub fork for this entry:
https://github.com/Treasurematrix/devops-micro-internship-interviews
📖 Full walkthrough with screenshots:
https://medium.com/@chiomanwosu2019/from-fork-to-pull-request-my-first-open-source-contribution-dmi-249fc80b4652
Top comments (0)