Navigating Git

I’m a regular Git user, but this in-class exercise exposed a few gaps in my workflow and helped me build a clearer mental model. For example, I rarely use git init because I usually start by cloning an existing repository. I also realized I’ve been relying on git add . too often simply because it’s convenient. After this week, I see why it should be used with caution: it’s easy to accidentally include unwanted files or unrelated changes, and that makes reviews and rollbacks harder.

Project evaluations and reflections

The projects I looked at varied a lot in size and activity level. Large projects like LangChain and Python are extremely active and fast-paced—issues can appear within the last hour and quickly attract multiple comments. Smaller projects tend to have fewer contributors and slower response times. In general, most communities felt welcoming, although I did notice that some maintainers in Neovim communicate more abruptly than others.

One consistent challenge is that many large projects are difficult to enter as a beginner. Some don’t have many “good first issues,” and even when those labels exist, the issues can still be confusing without more context. Some projects require substantial domain knowledge (for example, scikit-learn), and for ecosystems like React or JavaScript, it helps to already be a regular user of the library to contribute effectively.

What excites me most about contributing to open source is the idea of improving projects I genuinely use and care about—making even small changes that have real impact for other users. I’m also excited about collaborating with people who share similar interests, learning how to navigate a new codebase together, and improving through code review and discussion.

A few challenges feel very real:

1) Finding the right project — something active, beginner-friendly, and still realistically doable within the semester.
2) Understanding the codebase and issues — many projects have complex structures and workflows that are hard to grasp alone, especially at the beginning.

I plan to overcome them by asking questions, and prioritize tasks that are well-defined, testable and doable. I will also collaborate with my groupmates so we can all talk about our understanding of the codebase or a specific issue.