Thread by @dev__adi

It's #hacktoberfest and I'm teach people how to Open Source. So I thought it would be nice to make a glossary of terms used in Open Source as a thread. I'll use Video Game analogies as much as possible. Please and RT share with people who need it. So here it goes. (1/n)

*Commit* When we commit some files we make a checkpoint and save it with a name. Just like games where we save the current progress as a checkpoint with a title. If our mission fails or we want to do something in a different way we can restart the game from any checkpoint.
(2/n)

After we commit some files, even if we delete those files from our computer, we can recover them.
But if our computer breaks and we loose all the stored data then we cannot recover our code. That's the same reason why I never got to complete GTA Vice City. (3/n)

*Staging* When we are working on a feature we are messy and we tend to change too many files but we don't want to commit all the files. The files which are added to staging will be committed only. The files which are not added won't be.

Take note that just adding a file to staging doesn't mean it can be recovered. If you delete a file which not staged or it is staged but not committed then say bye-bye to that file because it can not be recovered.

*Push* When we commit the code it is still on our local machine. If the computer broke or somebody stole it then your code is lost. To prevent that we can take help of services like GitHub etc.
When we do `git push` all the local commits we have are duplicated to GitHub. (6/n)

It's just like our photos in memory card getting synced up on Google Photos (cloud). So when we switch to another device we can recover all the photos. Similarly with GitHub we can recover all the committed code which we pushed. Although GitHub is used for much more things. (7/n)

*Repo*: It's short for repository where we store all the code for one project. Just like we play multiple games we work on multiple repos. One repo could be about your web application while other can be about some other mobile app project.
(8/n)

*Clone*: Any repo which you see on GitHub you can download it on your local machine with `git clone`. This way you get a git repo on local in which if you make changes you can upload it back to GitHub.
(9/n)

*Fork*: If you are owner of a repo then after cloning the repo in local you can push back the changes. But to contribute to somebody else's project you need to fork their project on GitHub first. By forking we mean getting a copy of their repo in your own Github account.
(10/n)

Since you are the owner of this copy you can do anything you want with it. You can delete code, modify it, make it into something else. Suppose you miss one feature in React, you can add that feature in your fork and then use your fork's code wherever you need that feature
(11/n)

*Pull Request* Most likely you want to contribute your code back to the repo you forked from. PR (short for Pull Request) is a way by which we tell that repo's owner that these are the changes I have made, please review my code.
(12/n)

If they ask for some changes you'll have to do them. The PR will keep track of all the commits you are adding. Once the reviewer is happy with PR they'll merge it. But they also have the option to reject your PR. Maybe the feature is out of the scope of their project.
(13/n)

*Issues*: We open issues on GitHub to tell the owner about bugs or request features. Before making PR to add a feature we should first open an issue to ask owner if they need that feature. That way we can avoid spending time on making PR for a feature they don't want.
(14/n)

*Branches*: They let us work on different things in parallel. We play games with different accounts where in one we could be building a boat and in another blowing cars. Both accounts are independent. If one account gets suspended we can still play with another account.
(15/n)

The default branch is called 'master'. All other branches are created from the master branch.

Common name of these branches would be-
add-share-button
fix-form-height
remove-pluto

(16/n)

*Remotes*: With git the code in local can be pushed to different GitHub repos. Similarly code from different GitHub repos can be pulled in any local branch.

When we clone a repo in local, git automatically assign the path of the GitHub repo to a variable called origin.
(17/n)

That's why we do `git push origin master` to say push the code of my local branch to the master branch of the repo which 'origin' remote is pointing to.

Commonly we set 'upstream' remote to point to the repo we forked our repo from.

(18/n)

Suppose we forked React's repo and then made some changes to a file. Now in the original React repo, new changes were made. We don't have those changes on our fork or on the clone of the fork we have locally. To get that code locally we run `git pull upstream master`.
(19/n)

People who reach the end of this thread, hope you learned something valuable. If yes, please share it forward and let others begin their open source journey.