OSD600 Release 0.2 Week 1 (Updated)

Parker Chen — Fri, 10 Oct 2025 16:27:42 +0000

🔔 Prelude:
Everything's hard in the beginning

In release 0.2 week 1…

What I did

This week I mainly focused on searching for suitable open-source projects to contribute to. I haven’t started submitting any pull requests yet, but I did manage to create an issue (see link below) and am waiting for it to be assigned.

https://github.com/TemaDeveloper/library_proj/issues/17

Working on (issue/PR)

I opened an issue about setting up issue templates for a repository. Although I think it was a simple one, it still was my first time dealing with this topic, so I referred to the official GitHub documentation. I surprisingly learned that using a .yml file for the issue template allows better formatting and a cleaner layout for users filling in issue forms than the .md template.

The process has been updated, please have a check on the "Updated" section in this post

Need to know

Still waiting for feedback or assignment on my issue. Once that’s done, I plan to contribute my first PR to this project or one of the other candidates I’ve found.

Difficulties

The main challenge this week was finding the right project to start with. Some repositories are attractive and popular but have too many contributors already. It’s so hard to find available “good first issues” in those repos.

Fixes

After rewatching a previously recorded lecture, I realized I had overlooked GitHub’s advanced search feature. By also researching the GitHub official documentation, I improved my efficiency in locating suitable issues by using no:assignee, etc. I’ve already starred several projects for upcoming work.

Considerations

Some classmates shared potential projects on our team channel, and I found that exchanging ideas and experiences is really helpful. I believe active communication and collaboration will be key to achieving our release goals.

Updated

I have added templates to the repo and The PR has been merged.
https://github.com/TemaDeveloper/library_proj/pull/18

Here are some things I want to share:

Even though this PR is simple, it is somehow a little bit tricky. Because the templates will not be applied until the PR has been merged into the main repo (Github needs to read them), I have to create a new test repository in my account to test the templates.
And, this testing procedure did cause a bug: I mistakenly placed the templates in .github/workflow/ISSUE_TEMPLATES instead of the correct path .github/ISSUE_TEMPLATES in the original repo. However, in my separated test repo, the path is correct so that it didn't reflect any issue.
So after noticing the PR has been merged and the bug appeared, I still need to communicate with the owner to let him know I will create a new PR to fix the minor bug (https://github.com/TemaDeveloper/library_proj/pull/19). This cost extra time.

This little issue got me thinking about how to handle PRs whose results only show after merging... I’d like to explore this topic further.

OSD600 Lab 5

Parker Chen — Fri, 10 Oct 2025 15:41:16 +0000

🔔 Prelude:
Even more powerful commands for version control

Main Content

Write a blog post about the process of refactoring your code.

What did you focus on in your improvements? How did you fix your code so it would be better in each step?
How did your interactive rebase go? Did you find any bugs in your code while you did this? Did you break your program while changing things?
How did it go using Git to change your project's history?

What did you focus on in your improvements?

I mainly focused on looking for big code blocks to implement my improvements because it has a higher chance of discovering a function that can be exacted. At the same time, I was also looking for a chance to rename some vague variables and add comments to logic.

I used a code quality checking plugin called SonarQube (https://www.sonarsource.com/products/sonarlint/) to find potential issues in my code. Here is the showcase:

As you can see, SonarQube lists its concerns for my codebase. It’s convenient, but if you are also using Go for programming, you must have noticed that: if err != nil is basically inevitable, counting it into the complexity value is meaningless. It's still a good tool for pre-checking our code though.

How did your interactive rebase go?

Interactive rebase is surprisingly good, plus I found that GitLens (https://www.gitkraken.com/gitlens) provides a pretty UI with the IDE like VS Code.

(Reference: https://www.gitkraken.com/learn/git/problems/git-interactive-rebase)

I don’t need to be too concerned about the looking of the submit tree now because I learned how to rearrange it by "rebase." Separately creating small commits also makes the workflow clearer when we are developing. But since it will break the branch - specifically, drop some commit histories - we should always use it on our own, personal topic branch (and we’d better know what we are exactly doing).

Since I only made minor changes, I didn't confront big issues in this lab, but I do have a story to tell in the next section.

How did it go using Git to change your project's history?

Here is the concise story of using Git in my lab 5:

I created new branch
I made changes
Too smoothly! I finished all 3 targets without making a commit!
Had to pick the file that need to be committed, and saved others for later commits… Used add
In the middle of the way, noticed that the names of the local branch and the remote were different! Had to change them… (Then I deleted the remote one first, I don’t know why I did that.)
Rebase but failed! Since Git couldn’t find the remote branch…
…

Well you see, even though I finally managed to rebase my branch, the most difficult part still wasn't applying some Git commands but driving Git well from the very beginning. However, I got to know at least one thing: Git has most of the methods to help you keep the code history safe and operable (again, if you know what you’re doing there).

I feel like I only touched 30%~40% of Git's usages. It’s definitely worth investing time to learn it well.

Forem: Parker Chen