Contributing To An Open Source by A First-Timer (Part 2)
Tags: opensource, git, tutorial, beginners
Published: 2020-11-21 14:26:34

Hello Fellow Codenewbies 👋

In the [previous post](https://dev.to/adiatiayu/contributing-to-an-open-source-by-a-first-timer-part-1-2opa), 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](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

- 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)
``` 

- 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.

- 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

* [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)

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

```bash
git fetch upstream
``` 

* Navigate to our local default (*`main`*) branch

```bash
git checkout main
``` 

* 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.
You can read more explanations about them [here](https://www.atlassian.com/git/tutorials/syncing/git-pull).
<br>

* 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>

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.
However, this practice is [not recommended](https://careerkarma.com/blog/git-no-upstream-branch/) because this option has been deprecated.
One recommended way to push:

```bash
git push -u origin <branch-name>
``` 

* 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.

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](https://acompiler.com/git-best-practices/#tve-jump-17323b90fc9) 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](https://virtualcoffee.io/)'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](https://twitter.com/AdiatiAyu). Let's connect! 😊