DEV Community

Sheng-Lin Yang
Sheng-Lin Yang

Posted on

OSD600Lab2-How to contribute a feature to a repository

Write a blog post about the process of contributing a code change to another project. In your post, include links to everything you discuss (e.g., the project repo, your issue, your pull request). Discuss what you did, the changes you made for your feature, and the process of getting your work accepted. What problems did you have? What did you learn? What would you do differently next time?

Talk about the technical aspects: How did file timestamps work in the language you were working with? What challenges did you face integrating with the existing codebase? How did you handle edge cases?

I created an issue and opened a pull request after finishing the first version of my code for repopal.

However, the initial implementation wasn’t very good. As a result, we communicated through comments on the GitHub Pull Request. All of the comments were related to an optional feature in the CLI tool: the --recent or -r flag, used like tool-name . --recent, tool-name . -r, or tool-name . --recent 5.

In my first commit, I thought the code was ready for a pull request, but I hadn’t tested it with many different files and folders. When replacing . with src, for example, the command failed due to a path error. I debugged the issue, fixed the path handling, and submitted a second pull request.

Then, I encountered another problem with the --recent option. If a number was provided (rather than using the default), the days calculation was incorrect. I modified the code again to fix the issue.

Eventually, I resolved all the problems, got approval, and successfully merged my pull request into the repository.

Through this experience, I learned how to contribute to a repository by creating an issue and opening a pull request. I also learned how to use several Git commands I hadn’t used before this course, such as git push fork <branch-name>, git fetch origin pull/7/head, and git checkout FETCH_HEAD.

Therefore, I believe that next time, I’ll be able to confidently contribute to another repository using the Git command-line tools I’ve learned.

If your repo received a pull request, please also talk about what it was like to get a submission. How much did you need the author to change? How did that process go? What did you learn about code review?

From this experience testing the optional command-line feature, I became curious about how it worked. I noticed that if I didn’t provide a number, it defaulted to 7 days. However, I wanted users to be able to specify a number so they could retrieve files or folders modified within a custom number of recent days.

Additionally, the author of the repository made the process smooth—we didn’t need to spend much time communicating through the GitHub Pull Request.

I also learned about code review and how everyone has different coding styles and ideas. This made it a bit challenging for me to understand how the code worked in the project. I spent a lot of time trying to understand the existing code, and then I asked the author to help improve the feature. In the end, everything worked out well, and I was able to merge the pull request into my project.

Top comments (0)