GIT for DevOps

TrainWithShubham Imran Teli Technical Guftgu

GIT (Distributed Version Control System)

GIT was introduced by Linus Torvalds in the year 2005 for managing the development of Linux Kernel and from that time it became one of the most used version control systems (VCS) used for tracking the changes made during the software development process.

There are two types of version control systems :

1. The centralized version control system

2. Distributes version control system

In a centralized version control system, there is one central Repository and all the working directories rely on that central repository. No Local repository in between. Means always needs to be connected to the network to take any action. Since everything is centralized, in case if central server fails the complete data is lost.

In distributed version control system there is one local repository between the working directories and the Central repository.

The local repository is stored in the computer so whatever we push to the GitHub will be first stored in local repository of the machine and then only get pushed to the Remote server/ central repository.

Usually, developers commit everything to the local repository first, and at the end of the day, everything is pushed to the central repository.

Mercurial can also be used instead of GIT.

Git is the software that provides the version control system. It allows multiple developers to work on the same project simultaneously.

GitHub acts as a hosting platform for Git repositories. It adds a collaborative layer on top of Git, providing features for issue tracking, project management, code review, and more.

Stages of GIT.

There are three stages of GIT.

1. working directory

2. Staging area

3. Local Repository

First, we create a directory in our system and then use the git init command to initialize repository.

After running git init, Git creates a hidden subfolder within our project that houses the internal data structure required for version control. This subfolder is named .git. It contains the configuration files, object database, and other metadata required for version control.

Once the repository is initialized, we can start tracking changes to your project's files. You do this by adding files to the staging area using git add and then committing them using git commit.

To add the changes from working directory to the staging area we use git add . command (. is used to represent the current directory and its sub-directories)

from the staging area to the local repository we can use the commit command i.e. git commit -m "commit message" (-m is used to provide the commit message along with the commit command)

The git status command is used to display the current state of our Git repository. It provides information about which files have been modified, which files are staged (ready to be committed), and which files are untracked. Untracked files can be added to the staging area first and then committed to the Local repository.

git log command is used to provide the latest commits related to the particular repository. It provides a chronological history of commits along with the author name, commit message, and the commit ID.

git log --one-line command is used to provide the simplified one-line commits from git logs for the repository.

once after getting the commit IDs we can use git show commitID where commitID is obtained using git log or git log --one-line command to check a detailed explanation of the commitID used.

git restore command is used to restore the changes. git restore command should be used very rarely. It can also lead to data loss. So we should be careful before using the git restore command.

git restore --source=HEAD --staged --worktree file.txt used to discard changes in the working directory and to revert the state of the file in the staging area.

git restore --staged file.txt to unstage the changes done.

git restore --source=commitID --worktree file.txt this command is used to restore the file to the particular commitID mentioned in the command.

git config --global user.name "username" command is used to set the global name configuration for the GIT user. This name is associated with the Git commits and is used to identify as author of the changes.

The git config --global user.email "email address" command is used to set the global email address configuration for your Git user. This email address is associated with your Git commits and is used to identify you as the author of the changes.

git config -l is used to check the details of user name, and user email.

git remote add origin <central git URL> is used to add a remote repository named "origin" to the local repository. This step done to connect local repository to the central repository hosted on Git Hub or Bitbucket.

After adding the remote, you can use the git push command to push your local changes to the central repository like git push -u origin master. -U is used to set up the tracking of the linkage of the remote branch to local branch.

git remote -v to check url and user name for the remote url.

git branch command can be used to see all the available branches.

git branch branchname can be used to create a new branch

git checkout branchname can be used to checkout to another branch.

git branch -d branchname used to delete the branch specified after -d

git branch -D branchname used to forcefully delete the branch name specified after -D.

git merge branchname to merge the branch to the main branch. We use a pulling mechanism for merging the branches. The pulling mechanism means incremental updates.

git reset command is very powerfull command. It can be used to reset the changes from both the staging area and the working directory.

git reset <filename> to reset the file.

git reset . to reset everything.

git diff command is used to check the changes in the file if the file is not staged.

git diff --cached is used to check the changes in file if the file is staged.

git revert can be used to undo the existing commit. It can be used to undo the previous commit and create a new commit.

on running git revert commitID or git revert commitHash Git opens a text editor for you to provide a commit message. Review the changes that will be reverted and modify the commit message if needed.

git stash command is used to stash changes.

git stash save "message for stash" used to stash with the message

git stash --include-untracked can be used to stash the untracked files as well.

git stash list can be used to check the stash list

git stash apply command used to apply the most recent stash

git stash apply stash{2} used to stash based upon the number/index passed.

git stash pop command is used to apply the recent stash and remove it from the list.

git stash drop stash{index} command used to remove from stash list without applying it.

git stash clear command is used to clear the complete stash list.

git stash branch new-branch-name stash@{1} command used to create a new branch and apply the stash from the list.

The git stash command is a powerful tool for managing temporary changes in your working directory, allowing you to switch between branches and perform various tasks without committing incomplete work.

Imagine you are working on a new feature and suddenly a new request comes. In that case, we can stash the code we are currently working on and start a new request. Once the request is done and committed we can pull the code from the stash list using the command git stash apply stash{0} and start working on it again.

git reset commitID --hard (discards changes in both the working directory and staging area), git reset commit ID --soft (discards changes from the staging area but keeps data in the working directory)

git rebase and git merge are both used to integrate changes from one branch into another, but they do so in different ways.

git merge is used to commit changes from different branches. It creates a new commit which have two parent commits. in merge command we do not get the history of changes bewteen merge using log command. After a merge, the commit history appears as a series of separate branches that come together at the merge commit.

git rebase is used to modify the commit history by moving or combining commits from one branch onto another. Using the rebase command we get the history of changes in a linear way. After a rebase, the commit history is linear, as if the changes were made on top of the other branch from the beginning.

git push origin master / git push <remote name> <branch name> command is used to upload your local repository changes to the remote repository. It updates the remote branch with local commits.

git pull origin master <remote name> <branch name> command is used to fetch the changes from the remote repository and to the local repository and merge it to the current working brach. It's the combination of git fetch and git merge commands.

git fetch command is used to retrieve changes from a remote repository but does not automatically merge those changes into the current working branch. It's a way to sync your local repository with the changes made in the remote repository without immediately merging them into your working branch.

git clone <repository_url> command is used to create a copy of a remote git repository on our local machine. It downloads the entire repository, including all branches and commit history.