A guide to make your first open source contribution in GitHub: the basics

Hi there! Good to see you again in the second part of this blog series on open source. In this blog, we will understand a bit about GitHub and how you can make your very first open source contribution.

Source: Google

Some Git and GitHub terminologies

A directory or storage space where your projects can live. Sometimes GitHub users shorten this to “repo.” It can be local to a folder on your computer, or it can be a storage space on GitHub or another online host.

A reference to the enhancements/changes/bugs that can be made to the code. It is a suggestion, that is open for developers to take up an solve/improvise on. Issues can be assigned or unassigned to someone. If you have been assigned an issue, the maintainer of the repo has given you the permission to work on an issue. In general, it is best practice to work on an issue after it has been assigned to you. This is done so as to avoid many people working simultaneously on the same issue.

It is the first file one should read when starting a new project. It’s a set of useful information about a project and a kind of manual. It is the first file GitHub or any Git hosting site will show when someone opens your repository.

Like we have already seen, open source allows you to work with someone else’s code. So once you have modified the code, you have to tell the owner/maintainer of the code that you have made changes. You have to request them to “pull” your modified code into their main code base.

There is going to be a main branch (main code) that is ready to be deployed or is already deployed. We should not make changes to code that is in production. Imagine writing an email using Gmail. What will happen if the “send” button changes is code suddenly when you are writing an email? Will it not be annoying? Worst case, what if that happened because someone did it by mistake? Branches are created for the exact same purpose: to create a copy of the repository that you can work with.

Forking will also a copy of the repository, but this copy is independent of the main branch. So if the main repo is deleted, the branch will be deleted, but the fork will remain. The difference between a fork and a branch is this: forking will duplicate the entire repository in a different account; branch contains differences between its parent and itself, and can be merged into another branch, carrying those differences with it along with its parent’s. A branch can be created for the entire repository, but a fork cannot be done partially.

To be continued…

I thought I would be able to finish this in 2 posts, but I guess there is a lot to cover. So move to the last and final part of this series where I teach you how to make a pull request. Link: https://medium.com/@snehhapaddy19/creatingFFyour-first-pr-pull-request-867d388ecf34