My First GitHub Pull Request

Samina Rahman Purba - Sep 23 '22 - - Dev Community

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

  1. I filed an issue in the palpatine GitHub repo – I wrote a short descriptive message to what I wanted to do.
  2. I forked and cloned the repo on my local machine.
  3. I created a branch with the command git checkout -b issue-6
  4. I started working on the code and making commits to the branch I created and not to the main branch.
  5. After writing, I tested and tested my code. Multiple times. With different markdown sample sets that I created.
  6. I updated the README according to the changes made (i.e. support of markdown, etc.)
  7. 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

. . . . . . . . . . . . . . . . . . . . .
Terabox Video Player