Fear of Pull Requests (PR)
It is challenging to read and understand someone else’s code as everyone has their implementation style; however, this is also a very important skill to have because in real-world development collaboration between multiple developers is the norm. Growth happens outside our comfort zone, and this couldn’t be any truer! Although this activity of reading someone else’s code and contributing to it was truly intimidating, this also helped me take the first steps towards building such an important skill – reading, understanding and contributing to other people’s codes.
Before this, I used to see PRs as a scary, intimidating, impossible-to-do kind of activity. I used to think, well there is no way am I going to contribute to someone else’s code and then have it approved. After creating my first pull request and seeing the branch get successfully merged, I felt accomplished. I did not break any part of the code while adding a new feature!
Now, I am not saying that this was easy, and I am completely over my fear of PRs. I am not. I still fear them. However, sitting and doing nothing about things I fear won’t take me anywhere. I need to go out there and practice. More and more.
What I Did
Part of this week’s challenge was to pick a repository of our choice and start adding functionalities to support markdown files. I picked palpatine – which is an awesome minimalistic static site generator (SSG) written in C++. palatine SSG was only accepting .txt files as input to generate an html site, so I decided to add markdown support to it.
The Steps Performed
- I filed an issue in the palpatine GitHub repo – I wrote a short descriptive message to what I wanted to do.
- I forked and cloned the repo on my local machine.
- I created a branch with the command git checkout -b issue-6
- I started working on the code and making commits to the branch I created and not to the main branch.
- After writing, I tested and tested my code. Multiple times. With different markdown sample sets that I created.
- I updated the README according to the changes made (i.e. support of markdown, etc.)
- I created a pull request.
Things I Learned
I was able to use the issues tab on GitHub to communicate with my lab partner and used Slack if I had to ask some specific questions. I did not encounter any major problems during the process of adding a markdown feature. Through Slack was able to send screenshots to my partner whenever I needed quick suggestions or feedback.
I also learned that being able to understand other people’s style of coding and being able to write code to almost mimic their style is an important skill in itself.
It was great working with Batuhan for this lab again! He was prompt at working on my static site generator Rwar and added markdown support to it as well. He asked me questions whenever he had any through Slack and the entire process went smoothly. Batuhan had previous experience with pull requests and I was able to ask him questions regarding creating branches and PRs.
Looking Forward
Due to time constraints, hours of debugging, and four other heavy courses this semester (one of which includes building a game in Unity), I could only add one markdown feature support for Palpatine SSG. As much as I wished I added more features, I just could not manage time for it. In fact, I was paranoid about adding just one feature. I dreaded breaking something in the code so much.
Another thing I want to improve going forward is making more commits. I understand that the commits should have been made more often and told a story – however, since this was my first experience in contributing to someone else’s code it just did not go as perfectly as I wanted it to.
Useful Links
| Links | palpatine | rwar |
|---|---|---|
| Repo |  |
 |
| Pull Request | Samina's PR | Batu's PR |
| Issue | Issue#6 to Palpatine | Issue#6 to rwar |
Top comments (10)
It looks like your post and experience is from a class assignment. In the spirit of learning, here is a tip related to PRs and associated Issues on GitHub.
If you are submitting a PR that fully addresses an Issue, then in the PR description somewhere, you can link the PR to the Issue using the
Closeskeyword. For example, in your case the Issue was 6, so you could have put the following somewhere in the body of the PR:Closes #6(exactly like that with no space between#and the6). Then when your PR is merged, the merging will automatically close the linked Issue as completed. Whereas, in this case it looks like Batu manually closed the Issue after merging, and the Issue that Batu's PR addressed is still open in your repository.The benefit of linking with
Closesis that it helps ensure addressed issues don't remain inadvertently open, and also helps document intent and motivation of PRs since it also sets up hyperlinks between the two.Anyway good job beginning contributing to open source.
I didn’t know that, and I’ve been using issues and PRs for an over decade!
I'm not sure how long the feature has existed, but it's very useful. There are a few other keywords other than
Closesthat work too. List is in the docs here: docs.github.com/en/issues/tracking...It claims to work if issue is in different repo than the PR as well, but I haven't tried that. Docs don't indicate any constraints on the other repo. I'm assuming there must be though like perhaps same owner.
As others have commented, you don't need to be afraid of submitting PRs. If you read contributing guidelines for the project you're contributing to and follow them, then you can't really do anything wrong. Your PR will either be merged if it works, or you'll get a change request from a review.
🎉🎊🎉🎊
Do not be afraid to break in development, most importantly be more careful.
Congrats 👏
Congratulation and keep it up
🎊 🎊 🎊 🎊
Add to the discussion
Dont be affraid of developing new software ma'am. There is absolutely no need to. Unless you are repo owner, or have merging rights, you will not screw up code tree.