Comment on the Git Exercises

This week’s Git exercises helped me move from using Git mechanically to understanding its internal model. Before this course, I often treated Git as a set of commands to memorize. Now I see it more as a structured system that manages the lifecycle of changes.

One concept that became much clearer is the three states of a file: modified, staged, and committed. The slides explain that a modified file has been changed but not recorded, a staged file is marked for the next snapshot, and a committed file is safely stored in the local Git database. This state model explains many behaviors that previously felt confusing.

The “loading dock” mental model was especially helpful for me. Thinking of the working directory as a workbench, the staging area as a filtering checkpoint, and the repository as the permanent record makes the workflow logically consistent. It also highlights why Git includes the staging step — it gives developers precise control over what enters each commit.

After practicing commands like git status, git add, and git log, I started to see Git less as a tool and more as an infrastructure layer for collaborative software development.

Thoughts on Project Evaluation

In class this week, we evaluated the p5.js project. This exercise helped me see that an open source project is not only about code quality, but also about how the project is organized and how the community supports contributors.

Overall, p5.js feels beginner friendly. It was easy to find the contributing information on the website, and the project provides clear documentation and step-by-step setup instructions. The repository also has many active contributors (700+), which shows that the project has a healthy and active community.

One thing I found especially helpful is the presence of “good first issue” labels. These lower the barrier for new contributors. From my perspective as a student who is still building experience with large codebases, this kind of guidance is very important.

However, I also noticed that some beginner issues still require familiarity with JavaScript and the project structure. So while the project is welcoming, there is still a learning curve.

What excites me most is that p5.js sits at the intersection of programming and creative coding. As someone with a technical background, I find it interesting that open source can support both engineering and artistic communities at the same time. This makes the project feel more alive compared to purely technical libraries.

Biggest Challenges

The biggest challenge I anticipate is navigating large codebases efficiently. Mature open source projects often contain many layers of abstraction, and understanding where to begin is not trivial.

Another challenge is developing good open source communication habits. Writing meaningful commit messages, participating in issue discussions, and aligning with project conventions require a different mindset than solo programming.

How I Plan to Overcome Them

To handle the codebase complexity, I plan to adopt a “small surface area” strategy. I will begin by reading documentation, mapping the repository structure, and focusing on small, well-defined issues. Tools like git log --oneline and git diff should help me understand how specific parts of the code evolved.

For the collaboration challenge, I plan to learn by observation and gradual participation. I will study how experienced contributors structure pull requests and communicate with maintainers. Over time, I hope to develop habits that make my contributions easier to review and integrate.

Overall, this week shifted my perspective: Git is not just about saving versions of files. It is a coordination mechanism that enables distributed software development at scale. Understanding this system-level view will be important as I begin contributing to open source projects more seriously.