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

Hello Fellow Codenewbies 👋

In the [previous post](https://adiatiayu.hashnode.dev/contributing-to-an-open-source-by-a-first-timer-part-1), we have committed our changes.
<br>
So now it's the time to push our changes, right?
<br>
The answer is ***not yet***.
<br>
<br>
Remember that we are working with an open-source, where more contributors work on various things for the repo.
<br>
Maybe when we worked on our changes, a `pull request` was merged.
<br>
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](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/syncing-a-fork).

#### ✏ *EDIT*

**Before** we sync our fork repo, we must [configure a remote that points to the `upstream` repo](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork).

## Configure Remote That Points To The `upstream` Repo In Git

1. List our current configured remote repo for our fork
```bash
git remote -v
``` 
If we haven't configured a remote that points to the `upstream` repo, we will get:
```bash
origin <fork-repo-url> (fetch)
origin <fork-repo-url> (push)
``` 

2. 
Add a new remote `upstream` repo that will be synced with the fork
```bash
git remote add upstream <original-repo-url>
``` 
`original-repo-url` is the HTTPS URL of the original repo we fork.

3. 
Check if the new `upstream` has now been added.
```bash
git remote -v
``` 
Now we should get:
```bash
origin <fork-repo-url> (fetch)
origin <fork-repo-url> (push)
upstream <original-repo-url> (fetch)
upstream <original-repo-url> (push)
``` 

## From Syncing To Pull Request

1. 
[Fetch](https://docs.github.com/en/free-pro-team@latest/github/using-git/getting-changes-from-a-remote-repository#fetching-changes-from-a-remote-repository) 
<br>
We will fetch all the data from the up-to-date repo by running this command:
```bash
git fetch upstream
``` 

2. 
Navigate to our local default (*`main`*) branch 
```bash
git checkout main
``` 

3. 
Merge the updated repo to our local default branch
```bash
git merge upstream/main
``` 
#### 📝 *Additional Note (With Caution)*
There is a way to complete both `git fetch` and `git merge`. 
```bash
git pull upstream main
``` 
####  ⚠ *Caution*
`git fetch` can be considered the "safe" option, while `git pull` can be considered unsafe.
<br>
You can read more explanations about them [here](https://www.atlassian.com/git/tutorials/syncing/git-pull).

4. 
Navigate to our feature branch and push our changes
```bash
git checkout <branch-name>
git push
``` 
#### ✏ *EDIT*
*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](https://remarkablemark.org/blog/2017/06/02/git-update-branch/) along the way. I created a new repo, and I've tried it out myself*.
<br>
👇
<br>
<br>
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](https://remarkablemark.org/blog/2017/06/02/git-update-branch/#merge).
```bash
git checkout <branch-name>
git merge main
git push
``` 
There is a possibility that we will get this error after we did `git push`:
```bash
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.
<br>
However, this practice is [not recommended](https://careerkarma.com/blog/git-no-upstream-branch/) because this option has been deprecated.
<br>
One recommended way to push:
```bash
git push -u origin <branch-name>
``` 

5. 
And here comes the last step, creating a `Pull Request`.
  - Go to the `upstream` repo on GitHub
  - Create a `pull request` by clicking on the green button of "New Pull Request".
  - Include here [a reference to issues](https://docs.github.com/en/free-pro-team@latest/github/writing-on-github/autolinked-references-and-urls#issues-and-pull-requests), 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 collaborates and contributes to it.
<br>
<br>
I always thought I could "break" somebody else's repo if I made a mistake.
<br>
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`.
<br>
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.
<br>
So it's actually not as scary as I imagined before.
<br>
<br>
Through this experience, I also learned that even when we are working in our own repo, it would be a [good practice](https://acompiler.com/git-best-practices/#tve-jump-17323b90fc9) to create a new branch to work on features.
<br>

---

***Note:***
<br>
This post is one of my TIL notes based on my experience contributing to [Virtual Coffee](https://virtualcoffee.io/)'s open-source.
<br>
*Your experience or steps that you should / would take could differ from what I had*.

Thank you for reading!
<br>
Last but not least, you can find me on [Twitter](https://twitter.com/AdiatiAyu). Let's connect! 😊