DevOps-3: Version Control System [Git] - Outline

• Part-1: Version Control System
  • 3.1.1. Overview
  • 3.1.2. Types of Version Control System
  • 3.1.3. Tools for Version Control System
• Part-2: Git
  • 3.2.1. Introduction to Git
  • 3.2.2. Git Repository
  • 3.2.3. Life Cycle of Git and Git Workflow
  • 3.2.4. Download
  • 3.2.5. Installation
  • 3.2.6. Git Configuration Levels
  • 3.2.7. Configuration
  • 3.2.8. Git Commands
  • 3.2.9. Create a Git Repository
  • 3.2.10. Git Workflow
  • 3.2.11. Track Changes between Stages
  • 3.2.12. Steps to Revert to Earlier Commits in Git
  • 3.2.13. Delete Files from Git
  • 3.2.14. Ignoring Files in Git
  • 3.2.15. Rename files in Git
  • 3.2.16. Assignment
• Part-3: Operations in Git
  • 3.3.1. Branching in Git
  • 3.3.2. Merging in Git
    • 3.3.2.1. Fast Forward Merge in Git
    • 3.3.2.2. Recursive Merge
    • 3.3.2.3. Resolving Marge Conflict in Git
    • 3.3.2.4. Resolving Merge Conflicts on File Modifications
  • 3.3.3. Stashing in Git
  • 3.3.4. Rebasing in Git
  • 3.3.5. Cloning in Git
  • 3.3.6. Assignments
  • 3.3.7. Demo - Deploy file to Github via Git
  • 3.3.8. Project

Part-1: Version Control System

3.1.1. Overview

Version Control System helps to work on a big software development project that consist of:

• Technical Concepts
• Collaboration between different team members
• Frequent Changes

A Version Control System allows users to keep track of the changes in software development project and enables them to collaborate on those projects.

Purposes of using Version Control System:

• Records changes to a set of files
• Tracks every individual change by each contributor
• Facilitates a smooth and continuous flow of changes to the code
• Supports a developer’s preference and is flexible to use.

Different ways in which a version control system streamlines your project:

• Allows easy issue tracking
• Provides a complete long-term change history of every file with large file storage
• Facilities easy branching and merging
• Helps in tracing each change made to the software
• Tracks the status of each step in the pipeline
• Allows developers to tell each other about different changes pushed to a GitHub repository
• Gives real-time insights into the codebase
• Offers unlimited free private and public repositories

Some benefits of version control system are:

3.1.2. Types of Version Control System

Types of Version Control System are,

1. Local Version Control System: It’s maintaining track of files within the local system.
2. Centralized Version Control System: It’s using a central server to store all the files, and all the changes in the files are also tracked under the centralize server.
3. Distributed Version Control System: It’s moves from the client-server approach of the centralized version control system to a peer-to-peer approach.

3.1.3. Tools for Version Control System

Some of the preferred tools for Version Control System are:

Part-2: Git

3.2.1. Introduction to Git

Git is a type of Version Control System (VCS) that makes it easier to track changes to files. Git allows multiple developers to work together and supports non-liner development. Git is a version control system. It has a distributed architecture. It provides a flexible environment to work collaboratively and securely. You can create and manage remote repository using Git. Git facilitates the branching and merging of files within the main repository. Git allows every user to have a copy of the project files locally, thus making the files in the server secure.

Git is a software that runs locally. So, files and their history are stored on your computer. You can use GitHub to store a copy of the files and their revision history. Git enables you to collaborate more easily with other developers.

Git can merge the branches so that different people can work on different parts of the same file and later merge them.

Purpose of using Git,

• Tracks changes in the source code
• Uses distributed version control tool for source code management
• Allows multiple developers to work together
• Support non-liner development because of its several parallel branches

Benefits of using Git,

• Has flexible environment
• Keeps the files in secure server
• Create and manage remote repositories
• Facilitates branching and merging

3.2.2. Git Repository

A git repository contains all the project files and the entire revision history.

Characteristics of Git Repository,

3.2.3. Life Cycle of Git and Git Workflow

The three different file states of Git are:

• Committed
• Modified
• Staged

Each state relates to a specific Git section,

• Working Directory [Untracked file, Modified files, Staged files, committed files]: It is the local physical directory, where you make changes to your files.
• Staging Area: It is place where Git keeps a reference of all modifications to be sent in the next commit.
• Git directory(repository) [Modified files, Staged files, committed files]: It is the repository which stores all files in a compressed form.

The following diagram states the workflow of Git:

3.2.4. Download

Git is available to download for Windows, Linux and Mac

https://git-scm.com/

3.2.5. Installation

Download Git from above link and install it by installer file. After install you can check the git version,

git –version
        

Method-1: Installing Git on Mac:

1. Download Git from http://git-scm.com/download
2. Execute the installer: Select default settings
3. Execute “git --version” to verify your installation

Method-2: Installing Git on Mac:

Use the package manager Homebrew(brew.sh)

1. Brew install git
2. git –version

Installing Git on Linux:

On Debian based distribution like ubuntu:

1. apt-get install git
2. git –version

On Fedora:

1. yun install git (up to Fedora 21)
2. dnf install git (Fedora 22 or later)
3. git --version

3.2.6. Git Configuration Levels

1. System Levels (--system): It is the top most level.
   Command: “git config -system”
   Save to: etc/gitconfig
2. Global Level (--global): it is the next level after system level
   Command: “git config -global”
   Save to: ~/.gitconfig(on Windows OS it would be User/…)
3. Local Level (--local): It is the last level and it is the user repository level.
   Command: “git config -local”(Or Just ‘git config’)
   Save to: .git/config

NOTE: Local overrides Global and Global override System Level.

User settings in Git are mainly defined at Global level because they correspond to user level settings for all repositories.

3.2.7. Configuration

To following settings needs to be configured for all commits:

1. User.name [git config –global user.name “Your Name”]
2. User.email [git config –global user.email “you@example.com”]

NOTE: Yellow mark is level name. user.name and user.email are mainly configured to associate commit actions to a particular person.

Configure Git at a global level and choose a color of the UI to define the configuration of the editor.

git config –global color.ui “auto”
        

git config –global core.editor “’ C:\Program Files\Sublime Text\sublime_text.exe’”
        

For information related to the number of configurations:

git config –list
        

Output:

diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager-core
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
user.email=mamunbd.ruet@gmail.com
user.name=bdstar
        

To check the configuration level,

git config –global user.name            
        

You can change level to system for the above command

git config –system user.name            
        

3.2.8. Git Commands

Global Settings in Git: It is important because Git commit uses this information.

git config –global user.name “Your Name”
git config –global user.email email@mail.com
        

Create a new repository:

git init
        

Clone an existing repository:

git clone [url]
        

Check the status:

git status     
        

Add changes to the staging area:

git add file-name
        

Add changes to the staging area

git add -A
        

Remove files

git rm [file-name]
        

Commit changes to the local repository

git commit -m “your message”
        

Pulling changes form a remote repository

git pull [branch_name] [remote_url]
        

Push changes to a remote repository

git push origin [branch_name]
        

Push changes to a remote repository

git push –all
        

Connect to a remote repository

git remote add origin [server]
        

3.2.9. Create a Git Repository

1. To create an empty directory

   CMD:

   mkdir [directory-name]
               

   Example,

    
   mkdir myProjectDirectory
               

2. Next go to myProjectDirectory folder the command is following,

   cd myProjectDirectory/
               

3. Convert the directory into repository

      
   myProjectDirectory> git init
               

   Here, git init command creates a hidden directory that stores all the metadata required for it to function. It will be initialized an empty Git repository in your project directory by .git hidden folder.

   git init [directory-name]
               

   This command create and initialized git repository in the same time.

4. To get repository status

   myProjectDirectory> git status
               

   Its show the which branch you are and list the file changes in your repository. Git status shows that you are in branch master and there are no files to commit. The branch master is created by default.

5. To check number of file content inside the git repository,

   myProjectDirectory>ls -ls
   myProjectDirectory>ls -lrt  
               

6. Check the content of the hidden directory using:

   myProjectDirectory>ls -la
               

3.2.10. Git Workflow

Git maintains 3 snapshots of a file in separate directory.

While committing, it is important to add a message string using the -m flag. If missed, a default editor opens asking for comments.

To restrict the output to one-line, execute: 1git log –oneliner, this will display the information in a single line.

3.2.11. Track Changes between Stages

Tracking is the ability to identify changes between the different versions of the same file, spread across various repositories.

3.2.12. Steps to Revert to Earlier Commits in Git

3.2.13. Delete Files from Git

3.2.14. Ignoring Files in Git

How to ignore files in Git,

3.2.15. Rename files in Git

3.2.16. Assignment

Assignment-1:

• In a newly created repository, demonstrate the ability to change a file from untracked status to tracked.
• Later unstage the file so that it becomes "untracked" again.

Assignment-2:

• Add two files a.txt and b.txt into a repository.
• Stage and commit these files.
• Now delete a.txt from the working directory and staged area, whereas delete b.txt from the staged area but retain in the working directory.

Assignment-3:

• After making a couple of commits, modify the global settings for name and email and make a couple of additional commits.
• View the history of the commits, which will display the old and new configurations.
• Later reconfigure Git to ignore files with .txt extension and add two files a.txt and b.txt into the repository

Part-3: Operations in Git

3.3.1. Branching in Git

3.3.2. Merging in Git

3.3.2.1. Fast Forward Merge in Git

3.3.2.2. Recursive Merge

3.3.2.3. Resolving Marge Conflict in Git

3.3.2.4. Resolving Merge Conflicts on File Modifications

3.3.3. Stashing in Git

3.3.4. Rebasing in Git

3.3.5. Cloning in Git

3.3.6. Assignments

Assignment-1:

Create a branch "featureOne" and view the commit history in this branch. Make a change to a file and merge it back into the master branch. Then, make simultaneous changes to the same file to cause conflict and do the merge again.

Assignment-2:

Clone a repository from the remote repository into the local repository. Ensure that you can view the entire commit history.

Assignment-3:

Create a branch and edit a file that you inherited from master branch. Make a commit in that branch. Before you commit a second time, stash it away. Switch to master branch and create a new branch and apply the stash in that newly created branch. Then, return to the first branch and apply the stash again, and then delete that stash entry.

3.3.7. Demo - Deploy file to Github via Git

mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git branch
* my_task
    supporttest
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git status
On branch my_task
Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   src/components/services/configs/loan_purposes/Index.js
    modified:   src/shared/common/config.js
    modified:   src/store/modules/auth/auth.js
    modified:   vue.config.js

no changes added to commit (use "git add" and/or "git commit -a")
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git add src/components/services/configs/loan_purposes/Index.js 
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git commit -m "Task #14234"
[my_task 52f3807b] Task #14234
    1 file changed, 24 insertions(+), 3 deletions(-)
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git stash
Saved working directory and index state WIP on my_task: 52f3807b Task #14234
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git status
On branch my_task
nothing to commit, working tree clean
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git checkout supporttest 
Switched to branch 'supporttest'
Your branch is ahead of 'origin/supporttest' by 271 commits.
    (use "git push" to publish your local commits)
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git pull microfin supporttest 
remote: Counting objects: 39, done.
remote: Compressing objects: 100% (39/39), done.
remote: Total 39 (delta 17), reused 0 (delta 0)
Unpacking objects: 100% (39/39), done.
From 192.168.1.15:microfin-dev-next/microfinnext-frontend
    * branch              supporttest -> FETCH_HEAD
    915801f0..9a0260ea  supporttest -> microfin/supporttest
Updating 915801f0..9a0260ea
Fast-forward
    src/components/members/member_information/View.vue               |  8 ++++----
    src/components/services/configs/loan_products/Save.js            |  1 +
    src/components/services/loans/one_time_loan_transactions/Save.js |  9 ++++++++-
    src/components/services/members/member_information/Index.js      | 25 ++++++++++++++-----------
    4 files changed, 27 insertions(+), 16 deletions(-)
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git checkout my_task 
Switched to branch 'my_task'
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git rebase supporttest 
First, rewinding head to replay your work on top of it...
Applying: Task #14234
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git push origin my_task
Counting objects: 8, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.06 KiB | 544.00 KiB/s, done.
Total 8 (delta 6), reused 0 (delta 0)
remote: 
remote: To create a merge request for my_task, visit:
remote:   http://192.168.1.15/md.mamun/microfinnext-frontend/merge_requests/new?merge_request%5Bsource_branch%5D=my_task
remote: 
To 192.168.1.15:md.mamun/microfinnext-frontend.git
    023e3a59..5d6ae824  my_task -> my_task
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ git stash apply 
On branch my_task
Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   src/shared/common/config.js
    modified:   src/store/modules/auth/auth.js
    modified:   vue.config.js

no changes added to commit (use "git add" and/or "git commit -a")
mamun@mamun-pc:/var/www/html/microfinnext-frontend$ 

3.3.8. Project

Build a branching model as depicted in this figure

1. Start with the production branch and then create a HotFix branch and Integration branch
2. Subsequently have Feature 1 and 2 branches that integrate as shown in figure
3. Ultimately integrate all features into HotFix branch and then to Production branch