Understanding remotes and PR reviews

Aryan KhuranaAryan Khurana
6 min read

Table of contents

Introduction

This week my open-source development course at Seneca, we were tasked with working on one of our classmates’ CLI tools, specifically implementing a TOML-style configuration file. This feature allows users to configure the CLI tool with specific defaults. If these defaults are not present in the configuration file, the tool will fall back to its in-program defaults.

The idea behind this activity was to get accustomed to the practice of reviewing changes when someone else makes a pull request (PR) to your project. This week, the focus was more on being a maintainer than a contributor.

For this task, my classmate Fahad worked on my repository, GitHub Echo, while I worked on my friend Harshil's repository, ResumeEnhancer, similar to what I did last week.

I submitted a PR to Harshil’s project, and Fahad submitted a PR to mine. Here are some important links.

Now it is time to use Git and GitHub, and in this blog, I’ll walk you through the workflow of testing changes that someone made in their own fork and created a branch on your repository. How do I use his branch to test changes since his branch is in his fork and not in my main repository?

Testing Flow Walkthrough

Step 1: Clone Your Repository

The first thing I did was clone my own repository and run git pull once to ensure everything was updated. This command fetches any new changes from the remote repository and merges them into your local branch.

Step 2: Check Remotes

Next, I ran the following command to see what remotes I had:

git remote -v

What are Remotes?

Remotes are versions of your project that are hosted on the internet or another network (GitHub in this case). They allow you to collaborate with others and keep your work synchronized. Each remote is identified by a name, typically origin for your main repository and other names for any forks or additional repositories you may want to interact with.

Step 3: Add a Remote for Fahad’s Fork

Next, I needed to add my friend Fahad’s fork of my repository as a remote. This is necessary because I want to access the changes he made in his fork without having to clone his repository separately. This can be done using the following command:

git remote add fahad-clone git@github.com:Fahad-Ali-Khan-ca/github-echo.git

After adding this remote, I ran git remote -v again, which showed the following output:

Step 4: Fetch Changes from Fahad’s Fork

Now, using git fetch will download all the commits and branches from the remote repository to your local repository, but it will NOT merge anything (i.e., it's safe to do this on any current branch). This means that everything in Fahad’s repository is now copied to your local repository, but your working directory remains unchanged.

Step 5: Check Out Fahad's Branch

As you can see in the picture below, Fahad is using his branch issue-46 to work on the changes for my repository, so that is where I want to be.

I use the following command to create a new local branch called farad-pr-test that tracks Fahad’s original issue-46 branch:

git checkout -b fahad-pr-test fahad-clone/issue-46

This command does two things:

  1. Creates a new local branch called fahad-pr-test.

  2. Sets it to track Fahad’s issue-46 branch from his fork, allowing me to test his changes seamlessly.

I also ran the following command to see whether I have all the branches,

git branch --all

Step 6: Test the Changes

Now, it is time for me to test the changes and evaluate whether they work as intended.

Fix #1: Adding the TOML Dependency

The first issue I encountered was that my classmate had not added the TOML dependency to my Poetry environment. To resolve this, I made the necessary change directly on the fahad-pr-test branch.

Fix #2: Linting Errors in README.md

Next, I noticed some linting errors in the README.md documentation that Fahad had modified. I corrected these errors to ensure consistency and clarity in the documentation.

Fix #3: Configuration File Warning

Fahad is a really smart guy, and everything he implemented worked perfectly. However, one thing that bothered me was that if the user did not have a configuration file in their home directory, the program would not issue a warning. To improve the user experience, I added a feature that alerts users when there is no configuration file present and informs them that the default values are being used.

Additionally, I formatted all the code using Ruff, which had not been done previously. This not only improved code readability but also ensured adherence to coding standards.

Step 7: Merge my changes with his

Once I completed all the necessary changes, I proceeded with the following steps to ensure that my modifications were properly recorded and shared with my classmate Fahad:

  1. I used the command git add to add all the modified files to the staging area.

  2. After staging the changes, I committed them to the local branch fahad-pr-test with a descriptive commit message.

     git commit -m "Fix: Add TOML dependency, resolve linting errors, and add configuration file warning"

  3. Push Changes to GitHub: With my changes committed locally, I then pushed the fahad-pr-test branch to my GitHub repository using the command:

     git push origin fahad-pr-test

    This command uploads my local branch and its commits to the remote repository on GitHub.

  4. After pushing the branch, I navigated to Fahad's fork on GitHub and opened a pull request (PR) to merge my changes into his original pull request. This step allows me to propose my modifications for review and integration into his branch.

  5. In the PR description, I provided a detailed explanation of the changes I made, highlighting the addition of the TOML dependency, resolution of linting errors, and the implementation of a warning for the missing configuration file. This context is essential for Fahad to understand the purpose of my contributions.

  6. After submitting the PR, I waited for Fahad to review my changes.

Here is a screenshot of what this looked like:

Once the merge was complete, we noticed that the Continuous Integration (CI) tests were failing due to some lines being redefined, which indicated that the merge wasn't perfect. Fahad promptly addressed the issue on his end, reviewed the code, and made the necessary adjustments to resolve the conflicts. After committing his changes, the CI checks were re-run and passed successfully. With the tests passing, I merged his pull request into my main branch, successfully integrating the improvements, including the TOML dependency, linting fixes, and the new configuration file warning into the project.

On the other end, Harshil had also tested the changes I made in my pull request on his repository. After verifying that everything worked as intended, he merged my PR into his project successfully and closed it.

Conclusion

This experience significantly boosted my confidence and helped me become more comfortable with various Git commands and workflows.

There's a lot more planned, so I look forward to sharing my journey with you in the next update! 👋

0
Subscribe to my newsletter

Read articles from Aryan Khurana directly inside your inbox. Subscribe to the newsletter, and don't miss out.

osd600open source

Written by

Aryan Khurana
Aryan Khurana