Contributing To An Open Source by A First-Timer (Part 2)

Ayu is a tech blogger, open source contributor & maintainer, and tech community enthusiast based in the Netherlands. She loves photography and iced coffee!
Search for a command to run...

Ayu is a tech blogger, open source contributor & maintainer, and tech community enthusiast based in the Netherlands. She loves photography and iced coffee!
No comments yet. Be the first to comment.
Hi friends π, I've been writing tech blog posts for a few years now. If you don't know me yet, English is my second language. My mother tongue is Indonesian, and I'm also surrounded by Dutch every da

I frequently receive messages from enthusiastic contributors who have completed 2 or 3 high-quality pull requests (PRs) in just 1 month. Theyβre proactive, their work is top-tier, and theyβve handled

A few months ago, I shared a story about building an automated open source portfolio using just my smartphone and an AI assistant while on vacation. My main goal was to stop the "spreadsheet struggle"

Recently, I read Bekah Hawrot Weigelβs blog post, "When 'Local' Went Global: The Pandemic Era of International Communities." As someone active in many online communities, I found it a bit sad, but I agree with her points and think they apply to open ...

Hacktoberfest is almost over. How has your contribution journey been so far? Are you confident about contributing to open source projects, or are you still struggling to find your way? If you're new to open source and still feel overwhelmed, that's c...

Hello Fellow Codenewbies π
In the previous post, we have committed our changes.
So now it's the time to push our changes, right?
The answer is not yet.
Remember that we are working with an open-source, where more contributors work on various things for the repo.
Maybe when we worked on our changes, a pull request was merged.
If so, the original repo now has new updates than what we have cloned.
It is good practice to ensure that we have an up-to-date repo before pushing our changes by syncing our fork repo.
Before we sync our fork repo, we must configure a remote that points to the upstream repo.
upstream Repo In GitList our current configured remote repo for our fork
git remote -v
If we haven't configured a remote that points to the upstream repo, we will get:
origin <fork-repo-url> (fetch)
origin <fork-repo-url> (push)
Add a new remote upstream repo that will be synced with the fork
git remote add upstream <original-repo-url>
original-repo-url is the HTTPS URL of the original repo we fork.
Check if the new upstream has now been added.
git remote -v
Now we should get:
origin <fork-repo-url> (fetch)
origin <fork-repo-url> (push)
upstream <original-repo-url> (fetch)
upstream <original-repo-url> (push)
Fetch
We will fetch all the data from the up-to-date repo by running this command:
git fetch upstream
Navigate to our local default (main) branch
git checkout main
Merge the updated repo to our local default branch
git merge upstream/main
There is a way to complete both git fetch and git merge.
git pull upstream main
git fetch can be considered the "safe" option, while git pull can be considered unsafe.
You can read more explanations about them here.
Navigate to our feature branch and push our changes
git checkout <branch-name>
git push
When I contributed to the open-source, there was no update on the upstream repo. I could just push the changes after running git fetch upstream and git merge upstream/main without updating the feature branch. But what if there were changes on the upstream repo? I researched and found this article along the way. I created a new repo, and I've tried it out myself.
π
Suppose there are changes in the upstream repo. After navigating to the feature branch and before pushing our changes, we need to update our feature branch.
git checkout <branch-name>
git merge main
git push
There is a possibility that we will get this error after we did git push:
fatal: The current branch <branch-name> has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin <branch-name>
We can copy-paste the instruction and run the command.
However, this practice is not recommended because this option has been deprecated.
One recommended way to push:
git push -u origin <branch-name>
And here comes the last step, creating a Pull Request.
upstream repo on GitHubpull request by clicking on the green button of "New Pull Request".Now our pull request has been submitted, and we just need to wait for the owner/maintainer to review our changes and merge them.
Working with open-source could be intimidating for a beginner or a self-taught like me, who never collaborates and contributes to it.
I always thought I could "break" somebody else's repo if I made a mistake.
But how it works is the owner/maintainer of the repo will review our pull request before merging it. They will tell us when there is something that we need to fix before they merge our pull request.
And whenever we encounter some troubles, errors, or conflicts, we can always communicate it to the owner/maintainer. They will help us walk through it.
So it's actually not as scary as I imagined before.
Through this experience, I also learned that even when we are working in our own repo, it would be a good practice to create a new branch to work on features.
Note:
This post is one of my TIL notes based on my experience contributing to Virtual Coffee's open-source.
Your experience or steps that you should / would take could differ from what I had.
Thank you for reading!
Last but not least, you can find me on Twitter. Let's connect! π