DevOps-3: Version Control System [Git]
DevOps-3: Version Control System [Git] - Outline
- Part-1: 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.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
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,
- Local Version Control System: It’s maintaining track of files within the local system.
- 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.
- 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:
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:
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:
Git is available to download for Windows, Linux and Mac
Download Git from above link and install it by installer file. After install you can check the git version,
Method-1: Installing Git on Mac:
- Download Git from http://git-scm.com/download
- Execute the installer: Select default settings
- Execute “git --version” to verify your installation
Method-2: Installing Git on Mac:
Use the package manager Homebrew(brew.sh)
- Brew install git
- git –version
Installing Git on Linux:
On Debian based distribution like ubuntu:
- apt-get install git
- git –version
- yun install git (up to Fedora 21)
- dnf install git (Fedora 22 or later)
- git --version
3.2.6. Git Configuration Levels
- System Levels (--system): It is the top most level.
Command: “git config -system”
Save to: etc/gitconfig
- 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/…)
- 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.
To following settings needs to be configured for all commits:
- User.name [git config –global user.name “Your Name”]
- User.email [git config –global user.email “email@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
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 firstname.lastname@example.org 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@example.com
Create a new repository:
Clone an existing repository:
git clone [url]
Check the status:
Add changes to the staging area:
git add file-name
Add changes to the staging area
git add -A
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
To create an empty directoryCMD:
Next go to myProjectDirectory folder the command is following,
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.
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.
To check number of file content inside the git repository,
myProjectDirectory>ls -ls myProjectDirectory>ls -lrt
Check the content of the hidden directory using:
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
- 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.
- 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.
- 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
22.214.171.124. Fast Forward Merge in Git
126.96.36.199. Recursive Merge
188.8.131.52. Resolving Marge Conflict in Git
184.108.40.206. Resolving Merge Conflicts on File Modifications
3.3.3. Stashing in Git
3.3.4. Rebasing in Git
3.3.5. Cloning in Git
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.
Clone a repository from the remote repository into the local repository. Ensure that you can view the entire commit history.
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$
Build a branching model as depicted in this figure
- Start with the production branch and then create a HotFix branch and Integration branch
- Subsequently have Feature 1 and 2 branches that integrate as shown in figure
- Ultimately integrate all features into HotFix branch and then to Production branch