Search for a command to run...
Passionate about helping organizations build scalable infrastructure and DevOps solutions with cloud technologies. Experienced in designing robust systems, automating processes, and driving efficiency through innovative cloud solutions. Advocate for best practices in DevOps and cloud computing, committed to enabling teams to achieve their full potential.
No comments yet. Be the first to comment.
From StorageClass to LoadBalancer, building a fully functional MySQL-backed web application on AKS.
Learn to Use Python for OCR, Object Detection, Tagging, and Captioning with Azure AI Vision
Using Retrieval-Augmented Generation with LLM in Azure
Covers interview questions on Git, Docker, Kubernetes, Terraform, Ansible, Azure DevOps, and Azure Cloud
Efficient Microservices Deployment with Azure DevOps CI & GitOps with ArgoCD to AKS
Git is nothing but a tool for source code management, version control and collaboration of developers but not limited to developers.
Version Control:
So before deep diving into git, we encountered the term "Version Control" which simply means we can control or track each version/phase/state of file such as what the file initially was, and what modifications are done? who made the changes? the comparison between the current/changed version and the initial version and so on.
There are 2 types of version-controlling tools available in the market:
1- Centralized Version Control System(CVCS)
It is the least-used version controlling system. As the name suggests here all the files/code are stored in one place centralized which increases the risk of losing the file in a single shot if any server failure or deletion occurs by any means. No matter how many users are using the system and uploading their codes, all will be stored in one place hence greater the risk. It is not locally available, to access it we need to stay connected to the internet.
It is mostly used where security comes as a major factor for example stock exchange servers.
2- Distributed Version Control System(DVCS)
It is the most widely used version controlling system across the industry. Here all the contributor has their local copy in their system which contains an exact clone of what is available in the central repository and this feature keeps them on the safer side from unexpected losses.
Git has 3 stages which are:
Working Directory: This is the local directory that contains the untracked files which are there but have not come under git surveillance.
Staging: The staging area contains the files that are under the surveillance of git and is going to be a part of the next commit.
Git Repository: This is the area where refined/approved versions of codes are pushed.
As we are encountering a lot of jargon here, let's clear all the jargon or terminologies of Git.
Repository: It is nothing but a box on the server where all the codes or folders are stored.
There are a lot of repositories specific to one respective project/product. And GitHub, GitLab are some of the platforms where all the repositories of a particular user are created and stored.
Changes are personal to that particular repository where it is intended.
Server: It stores all repositories.
Working Directory: As the name suggests, it is the place where you make your hands dirty. The changes made here are personal to you only.
Here you can see your files and make the modifications.
Clone: It is a command that is used to make a copy of a project which is already uploaded to the repository to your local system.
Commit: It stores the changes in a special folder .git . It doesn't send your code to the remote repository but just let the git know that this piece of code will be sent to the remote repo in the next push.
When you commit, it generates a 40 charactered alphanumeric commit id.
Even if you change a single letter, comma or dot the commit id will change.
Commit is also known as SHA-1 hash.
CommitID/VersionID/Version: This ID helps to uniquely identify the change and details about who and when the changes are made.
It also helps when in case we want to revert to the changes we made.
Snapshot: It is an incremental representation of the current state of your tracked files in the form of a manifest which can be used to compare changes with the current file.
Tags: Tags assign a meaningful name with a specific version in the repository.
Once a tag is created for a particular save, it can't be changed even if you create a new commit.
Git Bash is a Command Line Interface based on Bash(Bourne Again Shell) that enables us to interact with Git through come git reserved commands. It comes by default with git when we install Git on our system. We will be firing all the commands from this CLI which looks as below. We can also make use of other terminals such as Command Prompt, Powershell, or mac terminal. Git comes pre-installed in some Linux distributions like Ubuntu.
1- Checking the version of git:
$ git --version
2- Setting the global username and email for git locally which helps to identify the author:
$ git config --global user.name "Your Name"
$ git config --global user.email "youremail@email.com"
3- Checking if the global username and email are correctly set or not :
$ git config --list you can see username and email have been specified below at the button.
4- Converting a normal folder into a local git repository:
An empty directory without git enabled looks like below
And to convert it to a git repository we need to fire the below command:
$ git init
Now it will look something like below:
ls -a is used to find the hidden file which shows a .git directory is created inside our normal folder and now the normal folder is converted to a local git repository.
5- Checking the status of the newly created local git repository:
$ git status is used to check the status of the repository which looks like the below when there is nothing inside the repository:
Now after creating some files inside the folder the status will look like the below which shows that there are some files available but are not under git surveillance or untracked by git:
6- Taking files to stagging or making them ready for commit:
$ git add fileName will make the file ready for commit.
And now you can see the changes using git status as below, the file hello.py is now ready for commit:
7- Unstagging a stagged or ready-to-commit file and bringing it back to the untracked stage:
$ git rm --cached yourFileName It will bring the stagged file back to untrackable as below:
8- Making multiple files ready for commit at a time:
$ git add . : This will apply to add command over all the files present in the directory as below:
9- Commit all the stagged files to git:
$ git commit -m "message you want to add" This will commit all the stagged files to the local repository and will make them ready to be pushed to the remote repository.
10- Restore files from being modified to track:
$ git restore fileName The "restore" command helps to unstage or even discard uncommitted local changes. It also helps to restore the deleted files in the directory.
$ git restore --staged newFile2 Restoring the file from staging by adding a flag --staged
Restoring a deleted file using the restore command.
11- Cloning a directory from a remote Repository to the Local system:
$ git clone https://github.com/rkn1999/DevOpsAssignments.git This will create a duplicate of DevOpsAssignments.git in our local system. By cloning, we will get the git-enabled repository with all the source code in our local system and start working forward.
Now after applying the command we can see that we have got DevOpsAssignments/ in our local.
12- Adding a remote repository to where the committed files will be pushed:
$ git remote add origin https://github.com/rkn1999/DevOpsAssignments.git Now the files present in our local system will be pointed toward this URL/remote repo and be ready to get pushed.
13- Checking the status of Remote Origin:
$ git remote -v It is used to check the status of whether our local is successfully pointing to the added origin or not.
14- Pushing the code/files to the repository:
$ git push origin branchName It will push the code to the specified branch name.
15- Pulling the code changed by another developer from the Remote Git repository to my Local Repository:
$ git pull origin master This will pull all the files that are modified by another developer after our last push.
There was nothing inside newFile2 earlier. In the below screenshot, you can see that I have added some text from GitHub and then pulled the changes to my local system through CLI to make sure my Local Repo is synced with the updated file.
16- Git Log to see all the operations made till date
$ git log This will show the entire log of operations you performed, and commits with their unique hash values.
