Dark Mode
Image
  • Wednesday, 21 February 2024
DevOps-3: Version Control System [Git]

DevOps-3: Version Control System [Git]


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

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:

benefits of version control system

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. benefits of version control 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. benefits of version control system
  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. benefits of version control system
3.1.3. Tools for Version Control System

Some of the preferred tools for Version Control System are:

benefits of version control system

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.

Introduction to Git

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.

Introduction to Git

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,

Git Repository

3.2.3. Life Cycle of Git and Git Workflow

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:

Life Cycle of Git and Git Workflow

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.

Git Workflow Git Workflow Git Workflow

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

Git Workflow

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

Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow

 

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.

Git Workflow Git Workflow

 

Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow

 

3.2.12. Steps to Revert to Earlier Commits in Git

Git Workflow

 

Git Workflow Git Workflow Git Workflow Git Workflow

 

3.2.13. Delete Files from Git

Git Workflow

 

Git Workflow

 

Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow

 

3.2.14. Ignoring Files in Git

How to ignore files in Git,

Git Workflow

 

Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow Git Workflow

 

3.2.15. Rename files in Git

Git Workflow

 

Git Workflow Git Workflow Git Workflow Git Workflow

 

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

Operations in Git

 

3.3.1. Branching in Git

 

Operations in Git

 

Operations in Git

 

Operations in Git

 

Operations in Git Operations in Git Operations in Git

 

3.3.2. Merging in Git

Operations in Git

 

Operations in Git

 

Operations in Git Operations in Git Operations in Git Operations in Git Operations in Git

 

3.3.2.1. Fast Forward Merge in Git

Operations in Git

 

Operations in Git

 

Operations in Git Operations in Git

 

Operations in Git

 

Operations in Git

 

3.3.2.2. Recursive Merge

Operations in Git

 

Operations in Git

 

Operations in Git

 

Operations in Git

 

Operations in Git Operations in Git Operations in Git

 

3.3.2.3. Resolving Marge Conflict in Git

Operations in Git

 

Operations in Git Operations in Git Operations in Git Operations in Git Operations in Git

 

3.3.2.4. Resolving Merge Conflicts on File Modifications

Operations in Git Operations in Git Operations in Git Operations in Git

 

3.3.3. Stashing in Git

Operations in Git

 

Operations in Git Operations in Git Operations in Git Operations in Git Operations in Git Operations in Git

 

3.3.4. Rebasing in Git

Operations in Git

 

Operations in Git

 

Operations in Git

 

Operations in Git

 

Operations in Git Operations in Git Operations in Git

 

3.3.5. Cloning in Git

Operations in Git

 

Operations in Git Operations in Git Operations in Git

 

Operations in Git

 

Operations in Git Operations 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

Project in Git

 

  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

 

 

Comment / Reply From