Subject Name : Git and GitHub Programming

Chapter 1 : Introduction
What is version control system ?
Version control, also known as source control, is the practice of tracking and
managing changes to software code. Version control systems are software tools that
help software teams manage changes to source code over time.

Or
A version control system (VCS) is a tool used to manage changes to source code or
other documents over time. It helps developers track and manage modifications,
collaborate with others, and maintain a history of changes. Here’s a breakdown of
how it works and its benefits:

Key Functions:
1. Track Changes: Records changes to files, allowing users to see what has
been altered, who made the changes, and when they were made.
2. Version History: Maintains a history of all changes, so you can revert to
previous versions of files if needed.
3. Branching and Merging: Supports branching to create separate lines of
development, and merging to integrate changes from different branches.
4. Collaboration: Facilitates collaboration by allowing multiple people to
work on the same project simultaneously without overwriting each other’s
changes.
5. Conflict Resolution: Helps manage and resolve conflicts that arise when
multiple people make changes to the same file.
Benefits of the version control system:
● Enhances the project development speed by providing efficient collaboration,
● Leverages the productivity, expedites product delivery, and skills of the
employees through better communication and assistance,
● Reduce possibilities of errors and conflicts meanwhile project development
through traceability to every small change,
● Employees or contributors of the project can contribute from anywhere
irrespective of the different geographical locations through this VCS,
● For each different contributor to the project, a different working copy is
maintained and not merged to the main file unless the working copy is
validated. The most popular example is Git, Helix core, Microsoft TFS,
● Helps in recovery in case of any disaster or contingent situation,
● Informs us about Who, What, When, Why changes have been made.
or
Benefits of version Control systems :
The benefits of using a version control system (VCS) are extensive and
significantly impact the efficiency and effectiveness of managing software projects
or any collaborative document-based work. Here’s a detailed look at these benefits:

1. Enhanced Collaboration:

● Simultaneous Work: Multiple team members can work on the same project
simultaneously without conflicting with each other’s changes.
● Merging Changes: VCS tools manage and merge changes from different
contributors seamlessly, helping teams collaborate more efficiently.
2. Historical Record:

● Detailed History: Tracks and records all changes made to files, providing a
comprehensive history of what was changed, when, and by whom.
● Audit Trail: Useful for auditing purposes and understanding the evolution
of a project over time.

3. Backup and Recovery:

● Safe Storage: Acts as a backup by keeping copies of all versions of files,

which helps recover from accidental deletions or file corruption.
● Version Reversion: Allows you to revert to previous versions of files or the
entire project if something goes wrong.

4. Branching and Merging:

● Feature Development: Enables the creation of branches for developing new

features or experimenting with changes without affecting the main codebase.
● Integration: Merges changes from different branches into the main project
once they are tested and validated.

5. Conflict Management:

● Resolution Tools: Provides tools to detect and resolve conflicts that occur
when multiple people make changes to the same file, ensuring a smooth
integration of contributions.

6. Improved Documentation:

● Commit Messages: Allows developers to write descriptive commit

messages explaining the purpose of changes, making it easier to understand
the context and rationale behind modifications.

7. Accountability and Tracking:

● Ownership: Tracks who made each change, providing accountability and

helping to trace the origin of issues or bugs.
● Responsibility: Makes it clear who is responsible for specific changes,
which can be useful for troubleshooting and project management.
8. Code Quality and Review:

● Code Review Integration: Many VCS tools integrate with code review
systems, allowing peers to review and approve changes before they are
merged, which enhances code quality and consistency.

9. Efficient Workflow:

● Task Management: Facilitates task and issue management by linking code

changes to specific tasks or issues in tracking systems.
● Streamlined Development: Automates many aspects of the development
process, improving overall workflow efficiency.

10. Consistency Across Environments:

● Environment Sync: Ensures that code is consistent across different

development, testing, and production environments, reducing the likelihood
of environment-specific issues.

11. Support for Experimentation:

● Safe Experimentation: Developers can experiment with new ideas or

features in separate branches, minimizing risk to the stable codebase and
encouraging innovation.

12. Enhanced Productivity:

● Faster Development: By managing changes and integrating contributions

effectively, VCS tools help teams work faster and more productively.

13. Disaster Recovery:

● Recovery Mechanisms: In the event of a major issue or disaster, VCS

provides mechanisms to recover and restore the project to a stable state.

Overall, version control systems are fundamental tools that enhance productivity,
collaboration, and the overall quality of work in software development and other
collaborative environments. They provide a structured and systematic approach to
managing changes, tracking progress, and ensuring that projects are developed
efficiently and effectively.

Types of Version Control System

1) Centralize Version Contol System

2) Distributed Version Control System

Centralized Version Control System

In centralized source control, there is a server and a client. The server is the master
repository that contains all of the versions of the code. To work on any project,
firstly user or client needs to get the code from the master repository or server. So
the client communicates with the server and pulls all the code or current version of
the code from the server to their local machine. In other terms we can say, you
need to take an update from the master repository and then you get the local copy
of the code in your system. So once you get the latest version of the code, you start
making your own changes in the code and after that, you simply need to commit
those changes straight forward into the master repository. Committing a change
simply means merging your own code into the master repository or making a new
version of the source code. So everything is centralized in this model.
There will be just one repository and that will contain all the history or version of
the code and different branches of the code. So the basic workflow involves in the
centralized source control is getting the latest version of the code from a central
repository that will contain other people’s code as well, making your own changes
in the code, and then committing or merging those changes into the central
repository.

Distributed Version Control System

In distributed version control most of the mechanism or model applies the same as
centralized. The only major difference you will find here is, instead of one single
repository which is the server, here every single developer or client has their own
server and they will have a copy of the entire history or version of the code and all
of its branches in their local server or machine. Basically, every client or user can
work locally and disconnected which is more convenient than centralized source
control and that’s why it is called distributed.
You don’t need to rely on the central server, you can clone the entire history or
copy of the code to your hard drive. So when you start working on a project, you
clone the code from the master repository in your own hard drive, then you get the
code from your own repository to make changes and after doing changes, you
commit your changes to your local repository and at this point, your local
repository will have ‘change sets‘ but it is still disconnected with the master
repository (master repository will have different ‘sets of changes‘ from each and
every individual developer’s repository), so to communicate with it, you issue a
request to the master repository and push your local repository code to the master
repository. Getting the new change from a repository is called “pulling” and
merging your local repository’s ‘set of changes’ is called “pushing“.
It doesn’t follow the way of communicating or merging the code straight forward
to the master repository after making changes. Firstly you commit all the changes
in your own server or repository and then the ‘set of changes’ will merge to the
master repository.
Below is the diagram to understand the difference between these two in a better
way:

Centralize vs Distributed Version Control System

● Centralized version control is easier to learn than distributed. If you are a

beginner you’ll have to remember all the commands for all the operations in
DVCS and working on DVCS might be confusing initially. CVCS is easy to
learn and easy to set up.
● DVCS has the biggest advantage in that it allows you to work offline and gives
flexibility. You have the entire history of the code in your own hard drive, so all
the changes you will be making in your own server or to your own repository
which doesn’t require an internet connection, but this is not in the case of
CVCS.
● DVCS is faster than CVCS because you don’t need to communicate with the
remote server for each and every command. You do everything locally which
gives you the benefit to work faster than CVCS.
● Working on branches is easy in DVCS. Every developer has an entire history of
the code in DVCS, so developers can share their changes before merging all the
‘sets of changes to the remote server. In CVCS it’s difficult and time-consuming
to work on branches because it requires to communicate with the server
directly.
● If the project has a long history or the project contain large binary files, in that
case, downloading the entire project in DVCS can take more time and space
than usual, whereas in CVCS you just need to get few lines of code because you
don’t need to save the entire history or complete project in your own server so
there is no requirement for additional space.
● If the main server goes down or it crashes in DVCS, you can still get the backup
or entire history of the code from your local repository or server where the full
revision of the code is already saved. This is not in the case of CVCS, there is
just a single remote server that has entire code history.
● Merge conflicts with other developer’s code are less in DVCS. Because every
developer work on their own piece of code. Merge conflicts are more in CVCS
in comparison to DVCS.
● In DVCS, sometimes developers take the advantage of having the entire history
of the code and they may work for too long in isolation which is not a good
thing. This is not in the case of CVCS.

What is Git and where did it come from ?

Git is a version control system.
Git helps you keep track of code changes.
Git is used to collaborate on code.
Git is a distributed version control system (DVCS) designed to manage and
track changes in source code during software development.
It was created by Linus Torvalds in 2005 to support the development of the Linux
kernel and has since become the most widely used version control system in the
world.

A Short History of Git

As with many great things in life, Git began with a bit of creative destruction and
fiery controversy. The Linux kernel is an open source software project of fairly
large scope. During the early years of the Linux kernel maintenance (1991–2002),
changes to the software were passed around as patches and archived files. In 2002,
the Linux kernel project began using a proprietary DVCS called BitKeeper.
In 2005, the relationship between the community that developed the Linux kernel
and the commercial company that developed BitKeeper broke down, and the tool’s
free-of-charge status was revoked. This prompted the Linux development
community (and in particular Linus Torvalds, the creator of Linux) to develop their
own tool based on some of the lessons they learned while using BitKeeper. Some
of the goals of the new system were as follows:

● Speed

● Simple design

● Strong support for non-linear development (thousands of parallel

branches)

● Fully distributed

● Able to handle large projects like the Linux kernel efficiently (speed
and data size)
Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain
these initial qualities. It’s amazingly fast, it’s very efficient with large projects, and
it has an incredible branching system for non-linear development (see Git
Branching).

What does Git do?

● Manage projects with Repositories
● Clone a project to work on a local copy
● Control and track changes with Staging and Committing
● Branch and Merge to allow for work on different parts and versions of a
project
● Pull the latest version of the project to a local copy
● Push local updates to the main project

Working with Git :

● Initialize Git on a folder, making it a Repository

● Git now creates a hidden folder to keep track of changes in that folder
● When a file is changed, added or deleted, it is considered modified
● You select the modified files you want to Stage
● The Staged files are Committed, which prompts Git to store
a permanent snapshot of the files
● Git allows you to see the full history of every commit.
● You can revert back to any previous commit.
 ● Git does not store a separate copy of every file in every commit, but keeps
track of changes made in each commit!

Why Git?
● It is free and open source software.
● It is reliable.
● Over 70% of developers use Git!
● Developers can work together from anywhere in the world.
● Developers can see the full history of the project.
● Developers can revert to earlier versions of a project.

What is GitHub?
● Git is not the same as GitHub.
● GitHub makes tools that use Git.
● GitHub is the largest host of source code in the world, and has been owned
by Microsoft since 2018.
● In this tutorial, we will focus on using Git with GitHub.

Git Install :
You can download Git for free from the following
website: https://www.git-scm.com/

Using Git with Command Line

To start using Git, we are first going to open up our Command shell.

For Windows, you can use Git bash, which comes included in Git for Windows.
For Mac and Linux you can use the built-in terminal.
The first thing we need to do, is to check if Git is properly installed:

Example :

git --version

git version 2.30.2.windows.1

Configure Git :
Now let Git know who you are. This is important for version control systems, as
each Git commit uses this information:

Example :
git config --global user.name "ravindra123"

git config --global user.email [email protected]

Creating Git Folder :

Now, let's create a new folder for our project:

Example :

mkdir myproject

cd myproject

mkdir makes a new directory.

cd changes the current working directory.

Now that we are in the correct directory. We can start by initializing Git!

Initialize Git :
Once you have navigated to the correct folder, you can initialize Git on that folder:
Example :
git init

Initialized empty Git repository in /Users/user/myproject/.git/

Alternatives to GitHub
While Git is one of the most popular version control systems, there are several
alternatives, each with its own features and use cases. Here are some notable
alternatives to Git:

1. Subversion (SVN)

● Description: Apache Subversion (SVN) is a centralized version control

system. Unlike Git, which is distributed, SVN uses a central repository
where all versions of files are stored.
● Key Features:
o Centralized version control.
o Fine-grained access control.
o Supports binary files and large repositories.
● Use Cases: Suitable for projects where a centralized approach is preferred,
and in environments that require strict version control and access
management.
2. Mercurial (Hg)

● Description: Mercurial is a distributed version control system similar to Git

but with a different design philosophy. It focuses on simplicity and
performance.
● Key Features:
o Distributed version control.
o Simple command set.
o High performance for large repositories.
● Use Cases: Preferred for projects where a distributed model is needed but
users want a simpler command structure compared to Git.

3. Perforce Helix Core

● Description: Perforce Helix Core is a version control system designed for

large-scale projects and enterprises. It combines centralized and distributed
features.
● Key Features:
o Scalable for large projects.
o Strong support for binary files and large assets.
o Integrated with various tools and IDEs.
● Use Cases: Ideal for industries like game development, where large binary
assets and complex workflows are common.
4. Bazaar (bzr)

● Description: Bazaar is a distributed version control system that aims to be

user-friendly and flexible. It supports both centralized and decentralized
workflows.
● Key Features:
o Supports multiple workflows (centralized and distributed).
o Simple commands and user interface.
o Integration with other version control systems.
● Use Cases: Useful for projects requiring flexibility in version control
workflows and ease of use.

5. Fossil

● Description: Fossil is a distributed version control system that includes a

built-in bug tracking system, wiki, and interface. It is designed to be
self-contained.
● Key Features:
o Distributed version control.
o Integrated bug tracking and wiki.
o Built-in web interface for repository management.
● Use Cases: Suitable for projects looking for an all-in-one solution with
built-in project management features.
6. Team Foundation Version Control (TFVC)

● Description: TFVC is a centralized version control system part of

Microsoft’s Azure DevOps suite. It is used in conjunction with Azure
DevOps Services and Server.
● Key Features:
o Centralized version control.
o Deep integration with Azure DevOps and Microsoft development
tools.
o Fine-grained control and policy enforcement.
● Use Cases: Ideal for teams using Microsoft’s development ecosystem and
looking for integration with Azure DevOps.

7. CVS (Concurrent Versions System)

● Description: CVS is an older version control system that is centralized.

While it has largely been superseded by newer systems like SVN and Git, it
is still used in some legacy environments.
● Key Features:
o Centralized version control.
o Basic branching and merging capabilities.
● Use Cases: Mostly for legacy projects or environments where CVS was
previously established.

Each of these systems has its own strengths and is suited to different types of
projects and workflows. The choice of version control system often depends on the
specific needs of a project, team preferences, and integration requirements with
other tools.
 Cloud based Solution
1. GitLab
GitLab is a web-based DevSecOps (take that, Call of Duty) platform that allows
software development teams to plan, build, and ship secure code all in one
application. GitLab offers a range of features and tools to support the entire
software development lifecycle, from project planning and source code
management to continuous integration, delivery, and deployment.

Key benefits and singularities:

● Single application: GitLab brings all DevSecOps capabilities into one

application with a unified data store, so everything is all in one place.
● Enhanced productivity: GitLab’s single application delivers a superior user
experience, which improves cycle time and helps prevent context switching.
● Better automation: GitLab’s automation tools are more reliable and
feature-rich, helping remove the cognitive load and unnecessary grunt work.

Site type: Self-hosted

2. Bitbucket
Bitbucket is a Git-based code hosting and collaboration tool designed for teams. It
offers unbeatable integrations with Jira and Trello, designed to bring the entire
software team together to implement a project. Bitbucket provides a place where
your team can collaborate on code from concept to cloud, create quality code
through automated testing, and confidently deploy code.

Key benefits and singularities:

● Exceptional integration with Jira and Trello: Structure chaos and keep the
entire software company up to date, from engineering to design. Access
branches, build statuses, commits, and Jira issues or Trello card statuses.
This is excellent for medium-sized businesses.
● Code collaboration from concept to cloud: Transition Jira issues based on the
status of pull requests, create a merge process checklist with assigned
approvers, and check for approved builds. Automatically build and test with
integrated continuous delivery.
● Deploy with confidence: Keep track of your deployments, preview them,
and promote them with confidence. Protect your code. You can rest easy
knowing that your code is secure in the Cloud and implement checks to
prevent problems before they occur.

Bitbucket offers several hosting options, including Cloud, Server, and Data Centre.
Each option has its own unique features and benefits. For example, Bitbucket
Cloud is hosted on Atlassian’s servers and accessed via a URL. It has an exclusive
built-in CI/CD tool, Pipelines, that enables you to build, test, and deploy directly
from Bitbucket.

Site type: Self-hosted

3.GitHub:GitHub is a web-based platform that provides hosting for version
control using Git. It is widely used for collaborative software development and
offers a range of features that support various stages of the development lifecycle.
Here’s an overview of what GitHub offers:

Key Features of GitHub:

1. Version Control with Git:

o Git-Based: GitHub is built on Git, a distributed version control
system. It allows you to manage code repositories, track changes, and
collaborate with others.
2. Repositories:
o Public and Private Repositories: You can create public repositories
that are accessible to anyone or private repositories for restricted
access. GitHub also provides unlimited private repositories with
various pricing plans.
3. Collaborative Features:
o Pull Requests: Pull requests (PRs) are a core feature for code review
and collaboration. They allow developers to propose changes, review
code, and discuss modifications before merging them into the main
branch.
o Issues: GitHub Issues help track bugs, feature requests, and other
tasks related to your project. You can label, assign, and organize
issues using milestones and projects.
4. Project Management:
o Projects: GitHub Projects provides Kanban-style boards for managing
tasks, organizing work, and tracking project progress.
 o Actions: GitHub Actions allows you to automate workflows,
including building, testing, and deploying your code. You can define
CI/CD pipelines and other automation tasks using YAML files.
5. Code Review and Discussion:
o Code Review: Features like inline commenting and review requests
facilitate thorough code review processes.
o Discussions: GitHub Discussions allows teams to engage in
conversations around specific topics, questions, or ideas related to the
project.
6. Security:
o Code Scanning: GitHub provides tools for scanning code for security
vulnerabilities and code quality issues.
o Dependabot: Dependabot helps keep dependencies up-to-date by
automatically generating pull requests for outdated or insecure
dependencies.
7. Integration with Other Tools:
o Third-Party Integrations: GitHub integrates with a wide range of
third-party tools and services, including CI/CD systems, project
management tools, and chat platforms.
o GitHub Marketplace: Offers various tools and actions to extend
GitHub’s capabilities.
8. Documentation and Wiki:
o README Files: You can use README files to provide
documentation and instructions for your project.
o Wiki: GitHub provides a built-in wiki for more extensive
documentation and knowledge sharing.
9. GitHub Pages:
 o Static Site Hosting: GitHub Pages allows you to host static websites
directly from your GitHub repositories. It’s commonly used for
project documentation, personal blogs, and portfolio sites.
10.Community and Open Source:
o Open Source Projects: GitHub is a popular platform for open source
projects, providing visibility and collaboration opportunities for open
source developers.
o GitHub Sponsors: Allows users to financially support open source
developers and maintainers.

Git Vs GitHub

Git and GitHub are related but serve different purposes in the realm of version
control and software development. Here’s a clear breakdown of their differences:

Git :

● Type: Version Control System (VCS)

● Function: Git is a distributed version control system that allows you to track
changes in your source code during development. It enables multiple
developers to collaborate on the same codebase, manage different versions
of code, and merge changes.
● Installation: Git is a command-line tool that you install locally on your
computer.
● Features:
o Version Tracking: Keeps track of changes to files and directories.
 o Branching and Merging: Supports branching and merging, allowing
you to work on different features or fixes simultaneously.
o Local Repositories: Each developer has a complete copy of the
repository, including its history, allowing work to continue offline.
o Commit History: Tracks the history of changes, including who made
them and why.

GitHub :

● Type: Platform/Service
● Function: GitHub is a web-based hosting service that uses Git for version
control. It provides a collaborative platform for managing Git repositories
with additional features like code review, issue tracking, and CI/CD
integration.
● Access: GitHub is accessed via a web interface and requires an internet
connection to interact with its remote repositories.
● Features:
o Remote Repositories: Hosts Git repositories online, making them
accessible to multiple users.
o Collaboration Tools: Includes features like pull requests, code
reviews, and issue tracking to facilitate team collaboration.
o Project Management: Provides tools like Kanban boards and
milestones to manage and track project progress.
o CI/CD Integration: Offers GitHub Actions for automating workflows
such as building, testing, and deploying code.
o Documentation: Supports README files and wikis for project
documentation.
 o Community: Facilitates community engagement through open-source
projects, GitHub Sponsors, and GitHub Discussions.

Key Terminology

1. Clone : In Git, "cloning" refers to the process of creating a complete copy

of a repository from a remote location to your local machine. This includes
not just the latest version of the files, but the entire history of changes,
branches, and tags. Cloning is typically the first step when you want to start
working on an existing project that is hosted on a remote server

How to Clone a Git Repository :

To clone a Git repository, you use the git clone command followed by the URL of
the repository you want to clone. Here’s the basic syntax:

git clone [repository-url]

Example :

If you want to clone a repository from GitHub, for example, you would do
something like this:

git clone https://github.com/username/repository.git

Or, if you’re using SSH, it might look like this:

git clone [email protected]:username/repository.git

Why cloning is important ?

Cloning in Git is fundamental because it provides a complete and local copy of a

repository, facilitating collaboration, development, and experimentation. It ensures
that all contributors have access to the full project history and codebase, supports
backup and recovery, and integrates with modern development tools and platforms.
Whether you are starting work on a new project, contributing to an existing one, or
performing maintenance tasks, cloning is a crucial operation that sets up your local
development environment.

2. Repository in Git :
Definition : In Git, a repository (often abbreviated as repo) is a storage location
where your project's files and their version history are kept. There are two main
types of repositories in Git:
 1. Local Repository: This is the repository on your own machine. It contains
all your project files, as well as the entire history of commits and branches
related to your project. When you clone a repository from a remote server,
you create a local copy on your machine.
2. Remote Repository: This is a repository hosted on a server or a cloud
service (like GitHub, GitLab, Bitbucket, etc.). Remote repositories are used
for collaboration and sharing code with others. They allow multiple people
to contribute to the same project and keep track of changes made by
different contributors.

A Git repository contains several important components:

● Working Directory: The directory where you modify files. It contains the
current state of your project files.
● Index (Staging Area): A file, also called the index, that acts as a staging
area where you prepare changes before committing them.
● Commit History: A record of all changes made to the project. Each commit
is a snapshot of the project at a specific point in time.

To interact with a Git repository, you use commands such as git init to create a new
repository, git clone to copy an existing one, git add to stage changes, and git
commit to save changes to the repository's history.
3.Working Tree : In Git, the working tree (or working directory) refers to
the directory on your local filesystem where you make changes to your project
files. It's the area where you work on your code, add new files, edit existing ones,
or delete files. The working tree represents the current state of your project as it
exists on your local machine.

Here's how it fits into the broader context of a Git repository:

1. Working Tree: This is the actual directory on your filesystem where you
have your project files. Any changes you make here are initially untracked
by Git until you explicitly add them to the staging area.
2. Index (Staging Area): Once you make changes in your working tree, you
use commands like git add to move those changes to the staging area. This
area is where you prepare changes before committing them.
3. Repository (Git Directory): This contains the actual version control data,
including the commit history, branches, and tags. It is typically stored in a
hidden directory named .git in the root of your project. This directory keeps
track of all the changes and versions of your project files.

The workflow generally follows these steps:

1. Edit files in the working tree.

2. Stage changes using git add, which moves them from the working tree to
the staging area.
3. Commit changes using git commit, which saves the staged changes to the
repository's history.
In summary, the working tree is where you interact with and modify your files
before those changes are staged and committed into your Git repository.

4.What is the Staging Area?

The staging area is an intermediary space where you prepare and organize your
changes before committing them to the repository. It allows you to review and
select specific changes to include in your next commit, giving you control over
what gets saved in the project's history.

5.Git Stash :

The git stash command is a powerful feature in Git that helps you temporarily set
aside changes in your working directory and staging area. This can be useful when
you need to switch contexts or branches but don't want to commit your current
work just yet. Here’s a breakdown of how it works and how to use it:

What Does git stash Do?

● Temporarily Saves Changes: git stash saves your local modifications (both
staged and unstaged) to a stack-like structure, so you can revert to a clean
working directory.
● Restores Later: You can later reapply these changes to your working
directory with git stash apply or git stash pop.

6. Git Checkout :
The git checkout command in Git is a versatile command used for several
important tasks related to branch management and file restoration. Here's a detailed
explanation of its primary uses:

1. Switching Branches

● Command: git checkout <branch-name>

● Description: This command switches your working directory to the
specified branch. It updates the files in your working directory to match the
state of the branch you're switching to.
● Example:

git checkout feature-branch

2. Creating and Switching to a New Branch

● Command: git checkout -b <new-branch-name>

● Description: This command creates a new branch and immediately switches
to it. It’s a shorthand for creating a branch with git branch and then
switching to it with git checkout.
● Example:

git checkout -b new-feature

3. Restoring Files

● Command: git checkout -- <file-path>

● Description: This command discards changes in the working directory for
the specified file(s), reverting them to their last committed state. This is
useful for undoing local changes.
 ● Example:

git checkout -- file.txt

4. Checking Out a Specific Commit

● Command: git checkout <commit-hash>

● Description: This command allows you to switch your working directory to
the state of a specific commit, identified by its hash. This puts your
repository in a "detached HEAD" state, meaning that any new commits you
make will not be associated with a branch unless you create a new branch
from this commit.
● Example:

git checkout a1b2c3d4

7. git pull
git pull is used to update your local repository with changes from a remote
repository. It retrieves (or "pulls") new commits from a remote branch and
integrates them into your current branch.

● Command:

git pull [remote] [branch]

o remote: The name of the remote repository (often origin).

o branch: The name of the branch you want to pull changes from (if
omitted, it defaults to the current branch).
● Example:

git pull origin main

8. git push

git push is used to upload your local commits to a remote

repository. It pushes (or "pushes") your changes to a remote
branch, making them available to others.

● Command:

git push [remote] [branch]

o remote: The name of the remote repository (often

origin).
o branch: The name of the branch you want to push to
(if omitted, it defaults to the current branch).
● Operation:
o Push: git push sends your commits from your local
branch to the corresponding branch in the remote
repository. If there are new commits on the remote
branch that you do not have locally, git push will fail
until you first git pull those changes and resolve any
conflicts.
● Example: git push origin main
Core Concepts of Git
1. Repositories
A repository (or repo) is a storage space where your project files and their history
are kept. There are two types of repositories in Git:
● Local Repository: A copy of the project on your local machine.
● Remote Repository: A version of the project hosted on a server, often on
platforms like GitHub, GitLab, or Bitbucket.

2. Commits
A commit is a snapshot of your project at a specific point in time. Each commit
has a unique identifier (hash) and includes a message describing the changes made.
Commits allow you to track and review the history of your project.

3. Branches
A branch is a separate line of development. The default branch is
called main or master. You can create new branches to work on features or fixes
independently. Once the work is complete, the branch can be merged back into the
main branch.

4. Merging
Merging is the process of integrating changes from one branch into another. It
allows you to combine the work done in different branches and resolve any
conflicts that arise
5. Cloning
Cloning a repository means creating a local copy of a remote repository. This copy
includes all files, branches, and commit history.

6. Pull and Push

● Pull: Fetches updates from the remote repository and integrates them into your
local repository.
● Push: Sends your local changes to the remote repository, making them available
to others.

Basic Git Commands

1. Initialize a Repository – git init
To start using Git in a project, you need to initialize a repository:
git init
This command creates a new Git repository in your project’s directory.
2. Clone a Repository – git clone
Creates a copy of an existing repository.
git clone https://github.com/username/repo.git
3. Check Repository Status – git status
To check the status of your repository:
git status
This command shows changes, staged files, and the current branch.
4. Add Changes:
To stage changes for the next commit:
git add <file-name>
Or to add all changes:
git add .
5. Commit Changes – git commit
Records the staged changes with a message.
git commit -m "Initial commit"
Include a descriptive message to explain what changes were made.
6. Create a Branch – git branch <branch-name>
Uploads local repository content to a remote repository.
git branch <branch-name>
7. Switch Branches – git checkout
To switch to a different branch:
git checkout <branch-name>
8. Pull Changes – git pull
Fetches and integrates changes from a remote repository.
git pull origin main
9. Merge Branches – git merge
Merges changes from one branch into another.
git merge <branch-name>
10. Push Changes – git push
To push your changes to the remote repository:
git push origin <branch-name>

Git Bash
Git Bash is an application that provides a Git command line interface
(CLI) emulation for Microsoft Windows. It allows users to run Git commands and
interact with a repository, as well as offering Unix command line features.
Essentially, Git Bash brings the powerful functionalities of Unix-based systems to
Windows, making it easier for developers to manage and control their projects.
Why Use Git Bash?
1. Compatibility: Git Bash is designed to be fully compatible with Git, making it
a crucial tool for developers who use Git for version control.
2. Powerful Command Line Tools: It provides a range of Unix command line
tools, which are often preferred by developers for their flexibility and power.

Ease of Use: With Git Bash, you get a familiar Bash experience on Windows,
which is particularly useful for those who are accustomed to Unix/Linux
environments. In Git, the term checkout is used for the act of switching between
different versions of a target entity. The git checkout command is used to switch
between branches in a repository.