Readme.md

Git for DevOps

Introduction

Git is software for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows.

• Now the first question that arises is, we relate to version controlling while defining Git, so what is version controlling?

  • The purpose of version control is to allow software teams track changes to the code, while enhancing communication and collaboration between team members. Version control facilitates a continuous, simple way to develop software.

• In one sentence, Git handles the Version Control System for a piece of Code which is present in local machine as well as on GitHub or GitLab.

• Now new words come into play, GitHub and GitLab

  • GitHub provides code hosting services that allow developers to build software for open-source and private projects in organizations.
  • GitLab does the same, while in addition, it has Continuous Integration/Continuous Delivery (CI/CD) and DevOps workflows built-in. (FUN FACT : GitHub is acquired by Microsoft, that's why GitLab transferred their database from Microsoft Azure to Google Cloud Provider, just competitor things, haha!)

• For our convenience as a cloud/DevOps engineer, We will work with GitLab in this case.

Basic Git Commands

Setup

• git config --global user.name “[firstname lastname]”
  (set a name that is identifiable for credit when review version history)

• git config --global user.email “[valid-email]”
  (set an email address that will be associated with each history marker)

Initialise

• git init
  (initialize an existing directory as a Git repository)

• git clone [url]
  (retrieve an entire repository from a hosted location via URL)

Stage & Snapshot

• git status
  (show modified files in working directory, staged for your next commit)

• git add [file]
  (add a file as it looks now to your next commit)

• git reset [file]
  (unstage a file while retaining the changes in working directory)

• git diff
  (diff of what is changed but not staged)

• git diff --staged
  (diff of what is staged but not yet commited)

• git commit -m “[descriptive message]”
  (commit your staged content as a new commit snapshot)

Branch & Merge

• git branch
  (list your branches. a * will appear next to the currently active branch)

• git branch [branch-name]
  (create a new branch at the current commit)

• git checkout [branch-name]
  (switch to another branch and check it out into your working directory)

• git merge [branch]
  (merge the specified branch’s history into the current one)

• git log
  (show all commits in the current branch’s history)

Share & Update

• git remote add [alias] [url]
  (add a git URL as an alias)

• git fetch [alias]
  (fetch down all the branches from that Git remote)

• git merge [alias]/[branch]
  (merge a remote branch into your current branch to bring it up to date)

• git push [alias] [branch]
  (Transmit local branch commits to the remote repository branch)

• git pull
  (fetch and merge any commits from the tracking remote branch)

• git rm [file]
  (delete the file from project and stage the removal for commit)

Rebase & Stash

• git rebase [branch]
  (apply any commits of current branch ahead of specified one)

• git reset --hard [commit]
  (clear staging area, rewrite working tree from specified commit)

• git stash
  (Save modified and staged changes)

• git stash list
  (list stack-order of stashed file changes)

• git stash pop
  (write working from top of stash stack)

• git stash drop
  (discard the changes from top of stash stack)

The Purpose

Infrastructure as Code

Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes.

With IaC, configuration files are created that contain your infrastructure specifications, which makes it easier to edit and distribute configurations. It also ensures that you provision the same environment every time. By codifying and documenting your configuration specifications, IaC aids configuration management and helps you to avoid undocumented, ad-hoc configuration changes.

Version control is an important part of IaC, and your configuration files should be under source control just like any other software source code file. Deploying your infrastructure as code also means that you can divide your infrastructure into modular components that can then be combined in different ways through automation.

• Files can be tracked with their History of changes
• Secured and stored in one place
• Shareable for DevOps Team

CI/CD Pipeline

Continuous integration is the practice of integrating all your code changes into the main branch of a shared source code repository early and often, automatically testing each change when you commit or merge them, and automatically kicking off a build. With continuous integration, errors and security issues can be identified and fixed more easily, and much earlier in the software development lifecycle.

By merging changes frequently and triggering automatic testing and validation processes, you minimize the possibility of code conflict, even with multiple developers working on the same application. A secondary advantage is that you don't have to wait long for answers and can, if necessary, fix bugs and security issues while the topic is still fresh in your mind.

Common code validation processes start with a static code analysis that verifies the quality of the code. Once the code passes the static tests, automated CI routines package and compile the code for further automated testing. CI processes should have a version control system that tracks changes, so you know the version of the code used.

Thanks for reading till the very end.

Follow me on Twitter, LinkedIn and GitHub for more amazing blogs about Cloud, DevOps and More !