My first usage of git remotes!

#beginners #opensource #git #github

Hello everyone!

Today, I worked on adding a new feature for my friend's command-line tool. I was implementing the support for config file. So, the users could specify all of their SSG options in a JSON formatted configuration file instead of having to pass them all as command-line arguments.

As usual, I opened an issue with the feature's description and forked his repo to work on the copy, not the original.

I opened a Draft Pull Request at first as I was still making the changes, but when I completed all the updates I changed the state to "Ready for review". I had to explain my work as the author had a few comments but at the end everything was accepted.

I also received an issue on my repo with my SSG tool. I labeled it as an enhancement as it was not a necessary part but good to have. I checked the PR and realized that there was a need for a few changes by testing the work. For that, I added them as a remote to my local repo, fetched and set a tracking branch. I contacted the author of PR through Slack and explained all necessary updates. I also summarized them in the PR itself as things to do, so I remember what to check for when everything is ready.

Generally, if the PR is about a small change viewing the "files changed" tab is enough. I can go line by line and figure out if everything is good. However, when it is something big as a new feature, testing locally is required. That is when remotes come handy.

So far - so good!

Hands-on debugging session: instrument, monitor, and fix

Join Lazar for a hands-on session where you’ll build it, break it, debug it, and fix it. You’ll set up Sentry, track errors, use Session Replay and Tracing, and leverage some good ol’ AI to find and fix issues fast.

RSVP here →