When I first joined my Outreachy internship with the Wikimedia Commons Android app, I felt excited... and honestly, a little lost at times. Open source was a new world for me, and with it came a flood of unfamiliar terms.Code reviews, and chats, I kept hearing words that made me pause and think: “What does that mean?”

In this post, I want to share my story of how I stumbled on some of these terms, what confused me, how I found my way, and what I learned in the process. Maybe you’ll see a bit of your own journey in mine!

The first puzzle: Merge Conflict

The first time I tried to update my pull request after changes were made to the main branch, I ran into a merge conflict. I didn’t understand why Git couldn’t merge my code automatically. I started searching online, read Git’s documentation, and tried out small examples in a test repository to see what went wrong.

After experimenting for a while, I understand how merge conflicts happen when two people edit the same part of the code differently — and how to resolve them safely.

---

The mystery tool: Git Bisect

Later, while trying to debug an issue, I heard my mentor suggesting: “We can use git bisect to track this down.” Git... what?

I had no idea what git bisect was. The name itself sounded technical and complex. I found out that git bisect is like a detective tool — it helps you find the exact commit where a bug was introduced by doing a smart search between a “good” commit and a “bad” one.

Curious but unsure, I read Git’s bisect guide . Later, I discussed it with my mentor, and that helped me see how it could be applied to our project specifically. It felt good to explore on my own first, then confirm my understanding.

---

A term that made me pause: Upstream / Downstream

I first came across upstream and downstream when I tried to open my pull request. I had pushed changes to my fork but forgot to sync it with the upstream (the main project repository). As a result, things didn’t go as expected — my PR wasn’t in sync, and I had to pause and figure out what went wrong.

After some searching , I understood it: upstream refers to the main project repo, and downstream refers to my fork or local copy. Once I learned that, I realised why keeping my fork synced with upstream is so important — and I made sure to do that before opening PRs after that!

---

The quiet confusion: Patch

Unlike some of the other terms, I didn’t struggle much with patch. I came across it in discussions where people talked about submitting or applying a patch. I understood it as a small set of code changes or fixes proposed to improve a project — usually submitted through a pull request or as a diff file. It’s a simple concept but an important part of open source work.

---

*** What this taught me ***

Looking back, I see that my confusion wasn’t a sign of weakness — it was just part of learning. In the beginning, I was hesitant to ask what these terms meant. I worried that my questions were too basic, or that I should already know the answers. But once I started asking — whether it was my mentor, or even just Google — I found people were happy to help.

💡 If you’re a future intern or new to open source, here’s what I’d say:

Don’t be afraid to ask, no matter how small or basic the question feels. Everyone starts somewhere. Everyone struggles. And asking questions is how we grow.

---

👉 These terms were just the beginning of my learning journey. I’m excited to keep growing and understanding more as my internship progresses!

---