Before We Start
As a beginner developer, especially a self-taught, one concept that’s essential and yet seems a little scary at first is Version Control. Personally, I think it’s because of how intimidating it sounds that in recent times, it’s been more commonly referred to as ‘Git’. A harmless three-letter word, that shouldn’t cause any more scares, right?
Though I’ve been building web applications for a while, I’ve shied away from thoroughly exploring Git until recently, when I got the opportunity to go through what I call the most thoughtful beginner-friendly git training. The knowledge I acquired, I think is worth sharing. Therefore, in this tutorial which is the first of a three-part series, we’re going to learn the concept of git and the basic terminologies to know for every beginner.
Understanding Git
Version Control or Git can be defined as managing and tracking changes to code. It helps track different versions of a file as well as collaborate with others.
Consider the following analogy.
Nana and Esi are planning a party at their house this weekend. To cut costs, they’ve decided not to hire a caterer to cook, they’ll do it themselves. While gathering recipes for appetizers, they remember their friend Ama makes the best samosas. They reach out to Ama who informs them that her recipes are stored on her Github. The idea is not to copy Ama’s recipe entirely but to use it as the foundation to create their own versions.
Below are some of the most commonly used Git terminologies:
- Repository: Popularly known as Repo. It's a folder that contains all of a project’s files and version history. In this case, Samosa Recipes is the name of Ama’s repo
- Project owner: One who sets up the project, and manages permissions on GitHub or GitLab. Ama is the project owner
- Contributor: One who adds their input to the repository. Generally, they have to be given the necessary permissions by the project owner. Nana and Esi are the contributors
- Fork: Breaking off a separate project from the main project. Nana and Esi notice a typo in Ama’s recipe and decide to help her out by making the necessary correction but first, they have to fork her repo.
- Clone: A full copy of the repo on a contributor’s local computer. Before the typo can be fixed, Nana and Esi need to get a copy of the project onto their computers.
- Upstream repository: The main or original repo. Ama’s repo
- Downstream repository: The contributor’s clone of the main repo. Nana and Esi’s repo (after cloning)
- Branch: An independent copy of the files that you can make changes on. The default is either main or master.
- Checkout: Switches to a different branch.
- Commit: Saves changes from a clone to the branch. Nana and Esi do this to save the changes they’ve made.
- Pull request: A merge request from a contributor to the project owner. Popularly known as pr. Nana and Esi create a pr asking Ama to add their corrections to her repo.
- Review: The project owner checks the changes for quality and test pass before approving the pr. Ama goes through their pr to check if it’s good enough and free of errors.
- Merge: When changes from the downstream repo get added to the upstream repo. After reviewing, Ama is convinced with the suggested correction and adds to her repo.
Summary
I hope that with this analogy, you’ll understand git better and be more comfortable in conversations where the basic terminologies are used. Thank you Alyssa, Deanna, Rob and The Good Docs Project (Best open source project for Technical writers) for teaching me Git in an unforgettable way.
In the next tutorial, we’ll learn the essential git commands, using a real-world open-source contribution as the case study.
Thanks for reading 👋🏾. I hope you found this helpful.