loading...
Cover image for Contributing To An Open Source by A First-Timer (Part 2)

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

adiatiayu profile image Ayu Originally published at adiatiayu.hashnode.dev Updated on ・4 min read

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 are working on various things for the repo.
Maybe when we were working on our changes, there is a pull request that has been merged.
If so, the original repo now has new updates than what we have cloned.

it is good practice to make sure that we have an up-to-date repo before we push our changes by syncing our forked repo.

EDIT

Before we sync our fork repo, we must configure a remote that points to the upstream repo in Git.

Configure Remote That Points To The upstream Repo In Git

  • List our current configured remote repo for our fork
git remote -v
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode
  • Add a new remote upstream repo that will be synced with the fork
git remote add upstream <original-repo-url>
Enter fullscreen mode Exit fullscreen mode

original-repo-url is the HTTPS URL of the original repo that we fork.

  • Check if the new upstream has now been added.
git remote -v
Enter fullscreen mode Exit fullscreen mode

Now we should get:

origin <fork-repo-url> (fetch)
origin <fork-repo-url> (push)
upstream <original-repo-url> (fetch)
upstream <original-repo-url> (push)
Enter fullscreen mode Exit fullscreen mode

From Syncing To Pull Request

We will fetch all the data from the up-to-date repo by running this command:

git fetch upstream
Enter fullscreen mode Exit fullscreen mode
  • Navigate to our local default (main) branch
git checkout main
Enter fullscreen mode Exit fullscreen mode
  • Merge the updated repo to our local default branch
git merge upstream/main
Enter fullscreen mode Exit fullscreen mode

📝 Additional Note (With Caution)

There is a way to complete both git fetch and git merge.

git pull upstream main
Enter fullscreen mode Exit fullscreen mode

Caution

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
Enter fullscreen mode Exit fullscreen mode

EDIT

When I contributed to the open-source, there was no update on the upstream repo, so 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 did some research and found this article along the way. I created a new repo and I've tried it out myself.
👇

If 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
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode
  • And here comes the last step, create Pull Request
    • Go to the upstream repo on GitHub
    • Create a pull request by click on the green button of "New Pull Request"
    • Include here a reference to issues, add descriptions of our changes, and submit

Now our pull request has been submitted and we just need to wait for the owner/maintainer to review our changes and merge them.

Conclusion

Working with open-source could be intimidating for a beginner or a self-taught like me, who never collaborate and contribute to any of it.

I always thought that I could "break" somebody else's repo if I made mistake.
But how it works is the owner/maintainer of the repo will review our pull request before merging it. They will tell 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 and they will help us to walk through it.
So it's actually not as scary as I imagine before.

Through this experience, I also learned that even when we are working in our own repo, it would be good practice for us to make a habit of working on features or fixing bugs in another branch than the default branch, create our own issue, pull request and merge it.


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 be different from what I had.

Discussion

pic
Editor guide