Last time, I learned how to utilize git and Github to create and manage my own work. Today, I continue to learn with the git workflow by handling pull requests and issues on Github.
Creating and Resolving Issues: The Process
First, I looked picked another classmate’s repo and looked over their website. Afterwards, I determined what needed to be fixed in the website based on the requirements from my previous weeks assignment and the creator’s complaints. I filed an issue with their repository explaining the issue and waited for their approval. Once I got feedback from the repository owner, I forked the repository and cloned it onto my local machine to work on the fix. As soon as I finished, I added, committed, and pushed my changes onto Github. I submitted a pull request indicating that I wish to merge my repository that contains the issue information with the owner’s repository. I waited for the owner to accept the pull request and automatically merged since there were no conflicts.
The Bug: Fixing the Website Aesthetics
One repository I found had a webpage that seemed to have a strong emphasis on aesthetics but its textboxes were huge and did not look properly aligned on the screen. I submitted an issue, indicating that I can make the website more aesthetically pleasing by placing everything in containers so that the size and alignment may be controlled. It was a simple addition to the base html and css, using div’s. I submitted a pull request and now the webpage looks much better. Now I did not know this, but if you put something like “fixed #7” into the pull request description, Github will automatically close that issue when the pull request is accepted. Pretty neat.
The New Feature: Text Encryption
I decided to add an encryption feature to one of the repositories, which involved me incorporating into the webpage’s existing hotkey functionality. I used CDNJS cryto-js library to encrypt the text. I implemented the encryption and decryption feature and referenced them two different hot keys on the website (ctrl-e and ctrl-d, respectively). I followed the same procedure when resolving the bug issue for the new feature.
Looking Over My Own Issues And Others Pull Requests
When looking over other people’s changes for my repository, I first look at their coding style. I see if their coding style is acceptable and similar to my own, as the code will a lot cleaner if that were the case. Next, I looked at the changes themselves to see if they actually resolved the issue they were assigned. Since this repository is just for learning purposes, there was not much to worry about when other people touched my code. However, I can see these points being bigger issues when you let random people on the internet contribute to your code. The code will be a mess if there are several different styles of defining in the code or comments are just all over the place.