If you are a product manager, you must have heard developers using certain Github terminologies in your daily standups or refinements which might confuse you if you don’t have a technical or programming background. Well, don’t worry. In this article, I article I will walk you through the popular GitHub terminologies which developers use. After this article, you will be able to understand the technical jargon being used by developers. I will try to keep everything as simple as possible so that everyone can understand them. I have added the official documentation link for each section in case you want to dive even deeper into the topics. This is a quick start guide for GitHub terminologies for Product Managers. Following are the popular technical Github terms used by developers.
Github
Github is like online storage where code is saved and developers can coordinate with each other when they have this common online storage. It is necessary to have centralised code storage so that all the developers can access it to work on the project simultaneously. Consider it as an online storage drive for code.
Repository
So now you have online storage called Github. But you can have different folders in storage. Similarly, Github has the option to create a repository where you can store all files from a project. Developers use a repository to store files, documentation from one project. However, if the project is too big, sometimes developers divided it into multiple parts and can have a separate repository for each part.
Clone
Okay Ashish, so I get it that repositories are used for storing the project files online. But won’t that still create a problem if two developers edit the same file online together simultaneously? Yes, it will. That’s why developers don’t do it. Developers copy all the files from these main online source repositories to their local machine (their work laptop). This project which is available on their local device is called “Clone” since it has been copied from the main online Github repository.
Branch
Well, coding is fun, but it can be risky sometimes. Right? And developers are smart people. They know how to mitigate risk. So they create different versions of the project in the same folder. Consider it like they make two folders in the repository. One with the main project. The other one is to work around and play with code. So all the changes they make in this other folder doesn’t affect the main project. These different versions are called branches. The branch with the main project is called the Master branch.
Commit
You start seeing a boy/girl. But that doesn’t mean anything unless you commit. Well, it’s the same logic here also. When developers work on a project they make changes in files. All the changes they make needs to be saved. This process of saving changes in code is called commit. Moreover, Github keeps a record of each of these changes and who made them.
Merge
Merge is the process of applying changes from one repository to another. Usually, developers merge their repository with the master repository when they are finished with the coding task. Marge can be performed with Pull Request which we will talk about in the next point.
Pull Request
Pull request is the process of submitting the branch which developers have worked upon to be merged with the master branch. A senior developer or the person in charge of reviewing the code make sure everything is okay, before accepting the request. Once the request is accepted, the two branches are merged.
Code Review
When developers make a pull request, the senior developer needs to check if the code is correct, clean, following standard practice, etc. This process of ensuring that everything with the changes made by developers is okay and not gonna cause any problem in future is called Code Review.
Merging Conflict
Sometimes, while merging two or more branches, some problem arises. For example, it can happen when multiple branches try to edit the same file. Developers need to resolve these conflicts by going through the git log and determining its cause.
Following is a rough diagram to explain how developers play with Github
I hope this article helps you in getting started with Github and make it look less scary and daunting. Github is a fascinating tool and in my opinion it will help you a lot if you read more about it from Github official documentation.