BYTE2BUILD
Sign In
☀

Git & GitHub from Scratch: A Practical Guide to Version Control Mastery

In IT industries, during the software build lifecycle or in any modern project, code and configuration files are constantly modified. It is very important to track what was updated, why it was updated, and who made the update. This helps in troubleshooting issues, rolling back to a previous version, or releasing a properly tested and stable version.


Instead of copying files repeatedly and emailing them to the team to maintain records, managing changes in a controlled and systematic way is called a Version Control System.


Git is a modern distributed Version Control System that tracks changes in code and configuration files efficiently. It maintains a complete history of modifications, allows safe rollbacks, and enables structured collaboration across teams. In today’s software development and DevOps environments, Git is not just a tool, but a foundational skill for managing change with confidence.

 

Before directly exploring Git, let us first understand how files were versioned manually. Earlier, developers used tools like diff to compare changes between files and patch to apply those changes to another file. This method allowed tracking differences and updating files without rewriting everything, but it was manual, less structured, and difficult to manage at scale.


Diffing File:

In Linux, to compare files efficiently and accurately, the diff command is used.


Examples:


bash
⧉ 
cat b2b_v1.txt ;
cat b2b_v2.txt ;
diff b2b_v1.txt b2b_v2.txt



The output highlights the differences between the two files.

Byte2Build@localhost:/$ cat b2b_v1.txt ;

Application Name: Byte2Build

Version: 1.0

Environment: Development

Debug Mode: Enabled

Database: MySQL

Maintainer: Byte2Build Team

Timeout: 30

Byte2Build@localhost:/$  cat b2b_v2.txt ;

Application Name: Byte2Build

Version: 2.0

Environment: Production

Debug Mode: Disabled

Database: PostgreSQL

Maintainer: Byte2Build Team

Timeout: 45

Logging: Enabled

Byte2Build@localhost:/$  diff b2b_v1.txt b2b_v2.txt

2,5c2,5

< Version: 1.0

< Environment: Development

< Debug Mode: Enabled

< Database: MySQL

---

> Version: 2.0

> Environment: Production

> Debug Mode: Disabled

> Database: PostgreSQL

7c7,8

< Timeout: 30

---

> Timeout: 45

> Logging: Enabled



The above commands first display the contents of b2b_v1.txt and b2b_v2.txt, allowing us to review both versions manually. 

The diff command then compares the files line by line and highlights the differences.



In the output, lines starting with < belong to the original file, and lines starting with > belong to the modified file. Indicators such as 2,5c2,5 and 7c7,8 show which line ranges were changed (c stands for changed).


The diff command compares two files at a time. If multiple comparisons are required, it must be executed separately for each pair of files.


For clearer and more readable output, the unified diff format is commonly used:


bash
⧉ 
diff -u b2b_v1.txt b2b_v2.txt


Output :

Byte2Build@localhost:/$  diff -u b2b_v1.txt b2b_v2.txt

--- b2b_v1.txt 2026-02-24 09:07:45.784000000 +0530

+++ b2b_v2.txt 2026-02-24 09:08:12.111000000 +0530

@@ -1,7 +1,8 @@

 Application Name: Byte2Build

-Version: 1.0

-Environment: Development

-Debug Mode: Enabled

-Database: MySQL

+Version: 2.0

+Environment: Production

+Debug Mode: Disabled

+Database: PostgreSQL

 Maintainer: Byte2Build Team

-Timeout: 30

+Timeout: 45

+Logging: Enabled


The -u option stands for unified format. It displays differences between files along with a few lines of surrounding context, making the output easier to read and understand. This format is widely used in patches and version control workflows.

Lines starting with - were removed from the original file.( --- represents the original file (b2b_v1.txt).)

Lines starting with + were added in the modified file.( +++ represents the modified file (b2b_v2.txt).)

Unmarked lines represent unchanged content and provide context.( @@ -1,7 +1,8 @@ indicates that the old file had 7 lines and the new file has 8 lines in this section.

Patch File

When fixing bugs or updating configurations, explaining changes manually can be unclear. Instead, a diff file records the exact differences between two versions of a file.

Using the files created earlier, a patch file can be generated with:


bash
⧉ 
diff -u b2b_v1.txt b2b_v2.txt > b2b_change.patch
cat b2b_change.patch

Byte2Build@localhost:/$  cat b2b_change.patch

--- b2b_v1.txt  2026-03-05 09:37:49.237000000 +0530

+++ b2b_v2.txt  2026-03-05 09:38:38.478000000 +0530

@@ -1,7 +1,8 @@

 Application Name: Byte2Build

-Version: 1.0

-Environment: Development

-Debug Mode: Enabled

-Database: MySQL

+Version: 2.0

+Environment: Production

+Debug Mode: Disabled

+Database: PostgreSQL

 Maintainer: Byte2Build Team

-Timeout: 30

+Timeout: 45

+Logging: Enabled




The generated file b2b_change.patch contains all modifications between the two versions of the file.


These changes can then be applied automatically using the patch command:


bash
⧉ 
patch b2b_v1.txt < b2b_change.patch
cat b2b_v1.txt


Byte2Build@localhost:/$  patch b2b_v1.txt < b2b_change.patch

patching file b2b_v1.txt

Byte2Build@localhost:/$  cat b2b_v1.txt

Application Name: Byte2Build

Version: 2.0

Environment: Production

Debug Mode: Disabled

Database: PostgreSQL

Maintainer: Byte2Build Team

Timeout: 45

Logging: Enabled



The patch command reads the differences stored in the patch file and updates the original file accordingly by matching the surrounding context.


 

Using diff and patch is more efficient than sharing entire files because it shows only the exact changes, preserves file structure, works across slightly different versions, and scales well for collaborative development. This concept forms the foundation of how modern version control systems manage and apply changes between file versions.

1. GIT

GIT is a Version Control System (VCS) created in 2005 by Linus Torvalds, the developer of the Linux kerneL.   It was designed to manage large and complex software projects where many developers work simultaneously from different locations.


Although the name Git does not officially stand for anything, it is often informally expanded as Global Information Tracker, referring to its ability to track changes in project files over time.

Git follows a distributed architecture, where every contributor has a complete copy of the repository along with its full history on their local machine. This design makes Git fast, reliable, and usable even when there is no network connection.

Git can operate in several ways:

  • On a single computer, allowing developers to work offline.
  • As a server, hosting repositories for team collaboration.
  • As a client, accessing repositories using protocols such as HTTP, SSH, or the Git protocol.

Because Git does not rely on a single central server, it works well for both small personal projects and very large projects with thousands of contributors.

Git is free and open source and runs on major operating systems including Linux, Windows, and macOS. Today, Git repositories are commonly hosted on platforms such as GitHub and GitLab.

Although Git is sometimes referred to as SCM (Source Control Management), it is more accurately described as a Version Control System because it can track changes not only in source code but also in configuration files, documentation, and other project assets.

2.1 GIT Installation

 

Before using Git, it must be installed on the system. Git is available for all major operating systems including Linux, Windows, and macOS.

2.1.1 Install Git on Linux

On most Linux distributions, Git can be installed using the system package manager.


Step 1:  Check if GIT is already installed


bash
⧉ 
Git –version



If the version is 2.20 or higher, can continue or upgrade the latest version.


Step 2:

For Debian / Ubuntu based systems:


bash
⧉ 
sudo apt update
sudo apt install git

 


For Red Hat / CentOS / Rocky Linux:


bash
⧉ 
sudo yum install git

or

bash
⧉ 
sudo dnf install git

2.1.2 Install Git on Windows

Step1 : Download the installer from the official Git website:    https://git-scm.com  or 

https://gitforwindows.org




Step 2: Run the Installer

  • Open the downloaded .exe file.
  • Accept the GNU General Public License.  Git is released under the GPL version two license, which is a free software license. This means  we can look at Git's code to learn how it works, and we can even modify it to do something different.



Step 3: Select Installation Path



Step 4: Select Components

 

Keep the default options selected:

 

  • Git Bash
  • Git GUI 
  • Windows Explorer integration 
  • Git Large File Support (LFS) 

These features help manage repositories and large files efficiently





Step 5: Choose Default Editor

Select the editor Git will use for commit messages.

Common choices include:

  • Notepad++
  • Visual Studio Code
  • Sublime Text
  • Vim

Choose the editor you prefer.





Step 6: Configure PATH Environment


Git from the command line and also from 3rd-party software

This allows Git commands to run from:

  • Git Bash
  • Command Prompt
  • PowerShell




Step 7: Choose HTTPS Transport

Keep the default option:

Use the OpenSSL library.

This works well for most public Git repositories such as GitHub.






Step 8: Configure Line Ending Conversion

 

This step determines how Git handles line endings, which differ between operating systems.

 

  • Windows uses CRLF
  • Linux and macOS use LF

 

Git provides options to automatically convert line endings to maintain compatibility across different systems.

 

You will see three options:

 

A). Checkout Windows-style, commit Unix-style line endings (Recommended)

This option converts LF to CRLF when files are checked out on Windows, and converts them back to LF when committing to the repository. This works best when collaborating with developers using different operating systems.

 

B). Checkout as-is, commit Unix-style line endings

Files are kept unchanged locally, but Git converts them to LF when committing. This option is useful if you primarily use Unix-like tools or editors on Windows.

 

C). Checkout as-is, commit as-is

No conversion is performed. This option is only recommended if all collaborators use the same operating system.

 





Step 9: Choose Terminal Emulator

   

Use MinTTY (the default terminal of Git Bash)

 

MinTTY provides better command history and Unicode support.