First Pull Requests

Following our release 0.1 of our static site generators, we were asked to head to a fellow classmate’s repository and create an initial Markdown Support Feature for their ssg.

Andrei and I decided to pair up again. He also blogs on medium as well. Check out his posts here.

Working with Git and GitHub

Initially, many of this week’s challenges seemed to be to work with Git and GitHub. A beginner like myself could easily get overwhelmed and confused with forking, making sure the right repository is cloned, the right branch is created, commits make sense, making sure the pull request and the issue number match, and so on. But luckily the lab is rather detailed, and soon I got more comfortable with it.

The basics of creating a pull request can be summed up into the following steps.

  1. Fork — Create your own repository from a fork of the original repository. In my example, the original is Andre’s repository, while my fork is here.
  2. Clone — Your forked repository of the code.
  3. Issue — Check out the code, then create an issue such as requesting an added feature. For example my issue for Andre’s ssg.
  4. Branch — Create a branch named after the specific issue, so everyone can tell easily what you’re working on.
  5. Coding & Committing — Write the code, test, commit, adding helpful comments.
  6. Pull Request — When its done create a pull request like this one.
  7. Contacting and Review Request — At this point, its a good idea to contact the original owner and ask for reviews.
  8. Repeat 5, 6, 7 — Until there is closure. Getting a pull request merged is definitely awesome, but its also fine if it doesn’t get accepted. The biggest take from the whole experience is improving on coding and logic.

Implemented Features

The features I’ve added for Markdown support include

  • Title parsing support for md files. Line starting with the Markdown syntax # indicates the title. This will populate the <title>...</title> and add <h1>...</h1> to the top of the <body>...</body>.
  • Header parsing support for md files. Lines starting with the Markdown syntax ## or ### will be parsed with <h2>...</h2> and <h3>...</h3> tags respectively.
  • Italic syntax support for md files. Contents surrounded by Markdown Syntax *italics* will be parsed to html <i>...</i> tags.
  • Bold syntax support for md files. Contents surrounded by Markdown Syntax **Bold** will be parsed to html <b>...</b> tags.
  • Bold and Italic syntax support for md files. Contents surrounded by Markdown Syntax ***Bold Italcs *** will be parsed with both italic and bold html tags.
  • Link syntax support for md files. Contents in Markdown Syntax [Link](url) will be parsed to html link tags with working links.

Challenges For the Lab

  • Imitating coding styles — Reading Andre’s code was not that complicated, especially since I’ve tried to find issues on his code last week. The slightly harder part is imitating his code style. Not only is he writing in another language (Python), we tend to name things differently. But it is understandable if someone wants to merge another person’s pull that the coding styles are consistent.
  • Regex — A large part of this lab was working on parsing Markdown syntax. I went with regex, and most of my time on this lab was spent on trying to figure out the right regex syntax to get the code to work right. Most of the bugs Andre found for my code was regex related. I know it’ll be too much to ask, but I’m hoping I got them mostly right. All in all, regex was the biggest challenge for me for this lab.
  • Communication and time management — I think a part of this lab wanted us to have feel for what its like asking for pull requests, communicating, getting reviews, revising code, then repeat. All of this had to be done in a one week time frame. I thought I had ample time, but didn’t realize how long these back and forths may take. Next time perhaps I’ll try to start much sooner.

Receiving a Pull Request

Andre has also created a pull request for my repository as well.

Throughout the week the lingering thought on my mind was how messy my current code was and how much work Andre must need to work through my code. My code had other issues, besides the ones found last week, and desperately needed a rework. While working on this lab, I’ve also tried to deal with some of the issues that my current code had.

Overall, working with Andre was a breeze. Since we were doing the same work, just on each other’s repositories, getting a pull request didn’t feel like too much of a surprise or a burden. Just like last week, we communicated well, and shot ideas at each other, so it was a great cooperation.

Reflection

The biggest take from this lab is time consumption. Either being reviewed for a pull request, or being the reviewer of the request, they both take a lot of time. Regardless, it also provides a very neat way to check out other people’s code, reflect on my own code, and learn something from it.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store