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.
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)