If you’re a developer, you probably have heard about GIT or SVN. Also might be heard someone say “Clone that repo” or “Create a new branch from develop” or even “Create a PR once you finish your feature”.
Well, all these terms are related to any version control system that they are using. Nowadays Git is most popular and most used Version Control System. If you are new to any of this software and confused about those terms, I am here to give you a basic understanding of some of the most used (or going to use) terms in our life.
Let’s get started!
Version Control System
First, let’s start with Version Control System. This is a software or system which keeps track of your changes based on timestamp, commits, versions, branches. And Git is the topmost version control system among all the others.
When we are about to start a new project, the first thing we do is set up our environment. Cloning is part of our very first step. Assuming the repository is already created, you were asked to clone a repo. Cloning is a process that brings code from the remote server in your repository to your local system.
Downloads a copy of the code to your local system
Fetching downloads repository changes from the remote server to your local repository. In this process, simultaneously we can download all the branches.
Fetch downloads repository changes from remote
Remote is the centralized storage or origin of the repository from where users can download, clone or fork, etc.,
Branch is a copy created from another branch or a master branch itself. This is something you cannot unuse when you are working on a git repository.
Branch is an extended copy of another branch
Checkout is a process of switching between different branches. This is the most happening scenario when you are working on multiple branches at a time either it may be a feature branch or bug fix.
Checkout === Change between branches
Pull does two of things - It downloads repository changes as well as merges the code with your local branch which you are in. It is not mandatory that you have to pull from the branch you are currently in. You can pull from any branch, it will automatically merge the code into your branch.
Pull = Fetch + Merge
Stagging a process of choosing(or allowing) which files to be saved in the commit. In some cases, we will be having some unfinished changes which we do not want to pass them in a commit. Here we ignore those files by staging only the required files.
Getting ready to be saved or commit
Unstaging is a process may or may not happen after staging. This gives an option to undo the changes happened in the staging process. To simplify, you can revert the files from the staging environment to unstage(or working) copy. This is very helpful when we accidentally add any files to the staging environment (accept it, this will happen with all of us sometimes).
Unstage environment === Working copy
Assuming you have staged all the necessary files and want to save the changes, here is where we use this commit. Commit lets you save the changes with a message and timestamp in your current branch in the local system.
Saves a copy with a message in your local system, not on a remote repository
You’re all set with your changes and committed as well and now is the time to send your changes to the remote repository. Here is where push comes into play, Push takes your local repository changes to the remote repository and makes available to anyone who has access.
Push is saving(or sending) your changes to the remote repository
Stashing is a mechanism almost similar to Committing. We have an option to save our unfinished changes in local other than committing or keeping in the unstaged environment and that is by stashing them. Assume you are working on a feature that is not finished yet and you have a defect to fix in production. Apparently we do not want to lose your unfinished copy of change, and also as it is a production defect we must resolve it ASAP. Here we using this process referred to as Stashing.
Stash allows you save an untracked copy in the local system
Pop or Unstash
Popping is a process of bringing back the stashed changes. Let’s assume we have successfully resolved production defect (which we always do) and now is the time to come back to the feature branch. Here we use this process referred to as Popping.
When we are working on any feature, we create a child branch from the base branch. And once our feature changes are complete, we merge our code into the base branch. This process is globally referred to as Merging. We can do this in two ways, either by merging ourselves or creating a pull request so that the approver can review your code and merge.
Pull Request (PR or MR)
All the branches are not accessible to everyone, few might be protected for quality or stability reasons. In such cases, when we have to merge our code into any protected branch, we create a request and assign it to the reviewer who can validate and merge. This request is also called as Pull Request or Merge Request.
If you are not a fan of command line tools, here are few GUI’s for you:
I have listed the most used and confused in this article. Hope you like it. If you have any queries please comment below.