Git VCS - Components and Commands

Git is the most popular version control system used by software engineers in managing application code and shared collaborative tasks. Its popularity in the DevOps ecosystem is borne from the need to manage application configuration as part of the Infrastructure as Code concept. -Nana

Git Commands and components

Git init - initialization is the first command in git used to initialize a working directory to become a Git repository. Safe to use when an existing repository is not cloned.

.git - this is an invincible folder in a git repository which contains all the information about the repository. It has information about the branches, the history, the log, the remote endpoint, the email associated with the connected repositories, etc. the .git directory is what signifies that a working directory is a Git repository.

Git add - this is a command used to add files to the staging area so that Git can be aware that such a file exists in the current working directory. To add all the files with a single command, $ git add . or $ git add <name of the file>

Git commit - Git commit pushes files or code present in a working directory but untracked by git. Through git commit, Git gets to see those files, get information about them, track them and makes them ready to be moved from the staging area to another repository. To make a commit after adding files to the staging area, $ git commit -m “<give a detail of what you are committing to git>”

Git diff - gives you the difference or a comparison of what you have in your working directory and the change committed in the staging area. Git diff will show you the file and the changes made. Command $ git diff. To make a comparison between two commits in the same repository, $ git diff <commit ID of one of the commits you are comparing> <commit ID of the second commit you are comparing>

Git restore - this is used to discard or undo the changes committed into a repository and restore it to its original form. There are two concepts used to restore commit changes made in Git. Revert and Reset - these are two concepts in Git which although serving almost the same purpose, are performing a little function distinct and unique to each other.

  • Reset - Git reset is used to perform a rewind restore, which returns the git commit to its former state. When the commit changes to be revoked are still in the local repository, Git reset is more appropriate to use. To undo changes made in the history and inside the files in the commit, $ git reset --hard <commit ID>. To reset the history of the commit $ git reset --soft <commit ID>.

  • Revert - Git revert discards the present commit and returns to the state of the prior commit. Git revert is more effective at reversing changes which have already been committed and pushed to a remote repository. To revert the changes made in the latest commit in the remote repository $ git revert HEAD and $ git push to make the changes reflect in the remote repository. The best practice is that code commit should not be too large so that it is easily reversible.

Git log - through this log, Git shows the commit history in the order through which they were made with detailed information about a commit's identity presented in a hashed value, the time such commit was made, the developer who made the commit, and the commit message. With the $ git log you can see a complete log of the activities within that working directory. To display the log of a particular author or developer working in the same share git directory, $ git log --author “<author’s name or email>”. Also, to show see a more detailed log about a particular commit, $ git log copy the ID of the commit and use $ git show <commit ID> to see a more detailed history.

Commit History - this is a log of all the commits, made in a repository.

Git Status - Git status gives information about a working directory, the branch, added files, untracked files and commits. Through $ git status, you can identify the files where you made changes.

Git Tracking - through $ git status, Git shows us the segregations between tracked files and untracked files. Git begins tracking files the moment they are added to the staging area. Files which are being tracked are represented in green colour while the files which are in the working directory but are not being tracked by Git are presented in red colour.

Working Directory - a working directory is the directory where Git is initialised. When new changes are made, these changes stay within the working directory, before being added to the staging area.

Staging Area - this is where the work-in-progress changes are saved. From the staging area, a commit can be made. To add files to the staging area, $ git add <name of the file>

Git branch - In Git, branches are code versioning, an independent line of development. The default branch in Git is the main branch, also called the master branch. shows the default branch of the working directory. From the main or master branch, other branches are created.

It is more ideal that the slave branches which are formed from the main branch should be the branch where all of the work is supposed to be done. Branching allows developers to submit changes to the master branch in segments to avoid issues or conflicts in the main/master branch.

It is safe to create a new branch for new features, code changes, or bug fixes.

Branch commands

  • To create a new branch from the main branch - $ git branch <name of new branch>

  • To view the current branch you are working on $ git branch

  • To switch from the main branch to another branch - $ git checkout -b <branch name>

  • To delete a branch $ git branch -d <branch name>

  • To list out all the branches - $ git branch -a

  • To rename a branch $ git branch -m <name of branch> <new name of the branch>

Merging - this is an integration of the changes made in an intermediate main branch and its sub-branches into the main branch after the changes have been tested, reviewed and validated.

Git stash - through git stash, we can save the changes we are making in our working directory temporarily to enable us to work on new features.

Git Stash commands

  • To make a stash - $ git stash

  • To a stash with details about the stash - $ git stash save “<write about the stash>”

GitHub/GitLab- a remote server for hosting and collaborating on git repositories. Both platforms are websites where developers not only collaborate to work on the same project, but these websites also store, manage, and track the changes made in the codes and make them readily available for other people to have access to these codes in their public repositories.

Git Hook - Git hooks are automated shell scripts that git executed before or after any git actions such as commit, push, pull, etc. What the hook does is prompt activities as a follow-up to automate the git development lifecycle. Git hooks can be used to protect the git repository from mistakes, automate manual processes, collect data about git activity etc.

Gitignore - gitignore is a file that tells Git which files to ignore when a project is being committed to a remote Git repository. Though present in the working directory, Git ignores those files and excludes them from the Git history.

Git repository - A Git repository is a folder which contains all the files, logs, configurations, and history created and managed by Git. The repository is where the code lives. A remote repository is a central shared repository where a collaborating team or the public can fetch the source code of a project. A repository can also be local within an individual's machine. The local repository is where the code is developed.

Git push - Git push takes the changes made in a local machine and uploads them into a connected remote server or repository to have a copy of the local repo in the remote server to be made available to the public or other members working in the same project.

Git pull - Git pull fetches and extracts commits from a remote git repository or server and promptly refreshes the local repository to have the same copy. Through the $ git pull command, we download and integrate changes from a remote server into our working directory.

Git clone - git clone is a command line Git tool which is used to download or make a copy of a remote repository into a local machine. Cloned Git repositories are not to be initialized. To clone a remote repository, $ git clone <repository URL>

SSH key - SSH public key is used for authentication to enable the Git client to connect the local Git repository with a remote repository so that both pull and push requests can be made within the connected repositories.

Merge conflict - Merge conflict is a variation that occurs when developers who are working in the same code base make changes conflicting changes in the same line in the same file. When there is a merge conflict, Git may not be able to fix the conflicting changes alone, it would require manual intervention from the parties involved to resolve the conflict and commit the new change. The best practice to avoid such merge conflicts is to push and pull often, a practice in DevOps known as Continuous Integration so that Git would not have to merge huge changes that would conflict with the existing code base.

Git client - This is a user interface or a command line interface where Git is executed. Through the git client, we can execute commands to interact with either the remote or the local git repository.

Git Config Commands

The first command in Git is the configuration. This configuration is to provide Git with the right information about the user, usually a username, and an email.

$ git config –global user.name “<provide a name>”

$ git config –global user.email “<provide an email>”

Check your configuration

$ git config -l

Creating a working directory

Use the mkdir to create a folder where you shall store the code files

$ mkdir git_directory

To enter into the directory

$ cd git_directory

Initialize the working directory created becomes a git repository.

$ git init .

Where the dot (.) signifies that the current working directory is the repository to be initialised.

(note: git init is mainly for new projects.) to check the initialization, use $ la -a If the working directory was successfully initialized, a .git hidden file should be present.

Article inspiration: Techworld with Nana, DevOps Bootcamp... Anshul on Udemy, DevOps Master Class.