Git Prodigy Mastering Version Control with Git and GitHub Ebenezer Don

Git Prodigy Mastering Version Control with Git
and GitHub Ebenezer Don install download
https://ebookmeta.com/product/git-prodigy-mastering-version-
control-with-git-and-github-ebenezer-don/
Download more ebook from https://ebookmeta.com

Git Prodigy
Mastering Version Control with
Git and GitHub
Ebenezer Don
This book is for sale at http://leanpub.com/git-prodigy
This version was published on 2023-08-31
This is a Leanpub book. Leanpub empowers authors and
publishers with the Lean Publishing process. Lean
Publishing is the act of publishing an in-progress ebook
using lightweight tools and many iterations to get reader
feedback, pivot until you have the right book and build
traction once you do.
© 2023 Ebenezer Don

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1. Introduction to Version Control . . . . . . . . . . 4
What is Version Control? . . . . . . . . . . . . . . . 5
Why is Version Control Important? . . . . . . . . 8
Introduction to Git . . . . . . . . . . . . . . . . . . . 11
Other Version Control Systems . . . . . . . . . . . 19
Installing Git . . . . . . . . . . . . . . . . . . . . . . . 23
2. Getting Started with Git - Command Line and
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Basic Git Commands . . . . . . . . . . . . . . . . . . 29
CLI vs GUI: Understanding the Differences . . . 34
Performing Basic Commands in VSCode . . . . . 38
Creating Your First Repository and Making Your
First Commit . . . . . . . . . . . . . . . . . . . . 42
Viewing the Commit History and Reverting To
A Previous Commit . . . . . . . . . . . . . . . . 46

CONTENTS
3. Branching and Merging in Git . . . . . . . . . . . 51
Understanding Branches . . . . . . . . . . . . . . . 52
Creating and Switching Between Branches . . . . 55
Merging Branches . . . . . . . . . . . . . . . . . . . . 58
Resolving Merge Conflicts . . . . . . . . . . . . . . 62
Branching and Merging Using VSCode . . . . . . 67
4. Introduction to GitHub . . . . . . . . . . . . . . . . 71
What is GitHub? . . . . . . . . . . . . . . . . . . . . . 72
Creating a GitHub Account . . . . . . . . . . . . . 76
Exploring the GitHub Interface . . . . . . . . . . . 79
Creating Your First GitHub Repository . . . . . . 83
5. Remote repositories with GitHub . . . . . . . . . 87
Understanding Remote Repositories . . . . . . . . 88
Connecting Git with GitHub . . . . . . . . . . . . . 91
Cloning a GitHub Repository . . . . . . . . . . . . 96
Pushing to and Pulling from GitHub . . . . . . . . 100
6. Collaborating on GitHub . . . . . . . . . . . . . . 104
Understanding Collaborators and Permissions . 105
Inviting Collaborators to a Repository . . . . . . . 108
Forking a Repository . . . . . . . . . . . . . . . . . . 110
Pull Requests . . . . . . . . . . . . . . . . . . . . . . . 115
Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Code Review and Merging on GitHub . . . . . . . 125
7. Best Practices for Git and GitHub . . . . . . . . 129

CONTENTS
Writing Good Commit Messages . . . . . . . . . . 131
Managing Branches Effectively . . . . . . . . . . . 137
Repository Organization and READMEs . . . . . 141
Things to Keep in Mind when Working with Git
and GitHub . . . . . . . . . . . . . . . . . . . . . 145
8. Licensing and Open Source . . . . . . . . . . . . . 147
What is Open Source? . . . . . . . . . . . . . . . . . 148
Open Source Licensing . . . . . . . . . . . . . . . . . 154
Best Practices for Contributing to Open Source
Projects . . . . . . . . . . . . . . . . . . . . . . . 157
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 162
9. Advanced Git Features . . . . . . . . . . . . . . . . 163
Stashing Changes . . . . . . . . . . . . . . . . . . . . 164
Rebasing and Rewriting History . . . . . . . . . . . 171
Using Git Hooks . . . . . . . . . . . . . . . . . . . . . 175
Git Blame and Bisect: Tracing Changes and
Debugging . . . . . . . . . . . . . . . . . . . . . 178
10. Troubleshooting Common Git and GitHub
Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Detached HEAD State . . . . . . . . . . . . . . . . . 184
Authentication Issues . . . . . . . . . . . . . . . . . 186
Recovering Lost Commits . . . . . . . . . . . . . . . 190
11. Conclusion and Next Steps . . . . . . . . . . . . 195
Reflecting on Git and GitHub Concepts . . . . . . 196

Further Resources and Learning Paths . . . . . . . 199
Appendix A: Git Command Cheat Sheet . . . . . . 204
Appendix B: Glossary of Git and GitHub Terms . 210

Preface
This book exists for one reason: to help you master Git,
GitHub, and the open-source landscape, regardless of
your prior knowledge or experience.
When I first encountered Git, I was, frankly, scared of
it. The concept of Version Control and the commands
associated with Git seemed intimidating. The term “Open
Source” was a mystery, and I couldn’t understand how a
group of strangers around the globe could use GitHub to
efficiently collaborate on a project. However, my perspec-
tive changed dramatically when I finally delved in and
learned how to use Git. I came to the startling realization
of how many thousands of hours and years of lost work I
could have saved if I had embraced it earlier. Git became a
tool that empowered me to work confidently, giving me
the freedom to collaborate, experiment, and even break
things, all while knowing I had a reliable safety net.
“Git Prodigy” was crafted as a clear, accessible, and
practical guide designed to unravel these powerful tools
and the vibrant world of open-source software.
In the pages of this book, we will take a journey. It’s
a journey that begins in the roots of version control,

Preface 2
unfurling the basic concepts of Git. You’ll learn how
to initiate a new repository, stage and commit changes,
manage branches, and merge code—always with an eye on
real-world application, with plenty of examples to make
the concepts come alive.
We’ll then explore GitHub, a platform that has emerged
as a cornerstone of collaborative software development.
You’ll learn how to work with remote repositories, use pull
requests, manage code reviews, and fork projects. But we
won’t stop at the mechanics: you’ll also learn how to work
effectively as part of a team, leveraging GitHub’s features
to facilitate productive collaboration.
Beyond Git and GitHub, “Git Prodigy” shines a spotlight
on the thriving open-source community. This ecosystem
is as diverse and colourful as it is influential, shaping
much of today’s software landscape. Through this book,
you’ll gain a deep understanding of the customs, rules,
and culture of open-source software, with insights into
licensing and best practices for making contributions.
This knowledge will empower you to participate con-
fidently, responsibly, and meaningfully.
As we reach the final chapters, you’ll learn advanced
Git features and real-world troubleshooting techniques.
From rebasing to cherry-picking, from handling merge
conflicts to recovering lost commits, you’ll acquire skills
that turn problems into opportunities for learning and

Preface 3
growth.
In this journey, you’ll learn more than just commands
and features. You’ll understand the philosophy behind
Git, GitHub, and open source—the why, not just the
how. Whether you’re a beginner hoping to grasp the
basics, an experienced developer aiming to hone your
skills, or an open-source enthusiast seeking to contribute
more effectively, you’ll find “Git Prodigy,” a valuable
companion.
Let’s get started.

1. Introduction to
Version Control
This chapter sets the foundation for understanding the
importance and role of version control in software devel-
opment. We’ll delve into Git, one of the most widely used
version control systems, and explain the key differences
between Git and GitHub. We’ll end the chapter with a
guide on how to install Git.
• 1.1 What is Version Control?
• 1.2 Why is Version Control Important?
• 1.3 Introduction to Git
• 1.4 Git vs GitHub: What’s the Difference?
• 1.5 Other Version Control Systems
• 1.6 Installing Git

1. Introduction to Version Control 5
What is Version Control?
Imagine you’re working on an important document, like
an essay or a report, and it’s been weeks since you
started. You keep restructuring your document as you
write, adding and removing paragraphs, and saving your
changes.
Then you realize that you’ve made a mistake. You’ve
deleted a paragraph that you wanted to keep. You try
to undo your changes, but you’ve saved over the same
file multiple times, and you can’t go back to the previous
version. You’re stuck!
Now, if you have ever worked on a project and saved dif-
ferent versions at different points with names like “first-
draft”, “second-draft”, “final-draft” or “final-final-draft-
for-real”, to avoid this problem, instead of overwriting
only one saved file, you’ve actually done some kind of
version control. You did this so that you can always go
back to a previous version in case you don’t like your new
changes.
Version Control, in programming, is just a more sophis-
ticated and streamlined version of this concept. It’s like
a time machine for your project. It keeps snapshots of
your work at different points in time, and you can travel
back and forth through these snapshots whenever you

want. And the best part? It’s all in one place; you don’t
need multiple versions of the same file cluttering your
workspace.
There are two types of version control systems: Central-
ized and Distributed.
Centralized Version Control (CVC)
Centralized Version Control is like having one master
document on a central server. Users check out parts of the
document to their local workspace, make modifications,
and then push those changes back to the master document.
There’s a single place where you can find the history of
the document and see all the changes. But, if something
happens to that central place, all the history might be lost.
Distributed Version Control (DVC)
Distributed Version Control is different. It’s like every-
one having a complete history of the document. They
can make changes independently and later merge their
changes with others. Even if the central place is lost, the
document’s history is safe because everyone has a copy.
This is the type of version control we’ll be learning in this

book, and it’s the most popular type of version control
used today.
Git is a Distributed Version Control System that allows
you to keep a history of your project, collaborate with
others easily, and make changes without affecting the
main project until you are ready.
In the following sections, we’ll dive into the fascinating
world of Git and learn how to harness its power for
managing your projects efficiently and collaboratively.

Why is Version Control
Important?
Version control is essential to modern software develop-
ment for a multitude of reasons. It’s like an insurance
policy for your project, offering a safety net for potential
mistakes and facilitating smooth team collaboration. Let’s
dive into some specifics of why version control is so
indispensable.
Reverting and Rectifying Mistakes
Everyone makes mistakes, and programmers are no ex-
ception. Sometimes you’ll make changes that either create
new bugs or just don’t pan out the way you hoped. With
version control, there’s no need to panic.
Imagine you roll out a new feature for your web app
and immediately receive messages about a critical bug.
Version control allows you to swiftly revert to a stable
version of the code, effectively undoing the changes, so
you can address the issue.

Experimentation Without Fear
Being innovative and experimenting with new ideas is at
the heart of software development. However, experiment-
ing in your main codebase can be risky. Version control
systems allow you to mitigate this risk.
For example, consider a scenario where you are develop-
ing an app and want to add a new feature that you’re
not sure will be enjoyable. Version control allows you to
create a separate copy of your code, known as a branch,
for experimentation. If your new feature proves to be
successful, you can merge it back into the main code. If it’s
unsatisfactory, you can simply discard the branch without
affecting the main codebase.
Simplifying Collaboration
When working on a software project with a team, things
can get messy if you don’t have a good system in place.
Imagine multiple people making changes to the same files
- it’s a recipe for disaster without version control.
Let’s say you and your colleague are both working on
different features of a mobile app. Version control enables
you both to work on the same codebase without inter-
fering with each other’s work. When you’re both done,

you can combine your changes into the main project, and
if there are any conflicts, the version control system will
help you resolve them.
In essence, version control is not just a good-to-have, it’s a
must-have for any software development process. It’s
like a safety net, a time machine, and a team coordinator
all rolled into one. In the next section, we’ll start our
journey into one of the most popular version control
systems - Git.

Introduction to Git
Now that we’ve established how critical version control
is for software development let’s delve into Git. Git is
a Distributed Version Control System (DVCS) that has
become an industry standard for both small and large-
scale projects. In this section, we will lay the groundwork
for understanding what Git is, how it differs from other
version control systems, and why it has become so popular
among developers.
What is Git?
Git is a distributed version control system designed to
manage the source code history of software development
projects. It was created by Linus Torvalds in 2005 to
manage the development of the Linux kernel. Since then,
it has become the most widely used version control system
in the world.
The term “distributed” in its architecture means that each
user’s working copy of the codebase includes the full
history of changes and commits. Unlike Centralized Ver-
sion Control Systems (CVCSs) where there’s one central
repository, in Git, every developer’s working copy is a
repository.

A repository, often shortened to “repo,” is a storage
location where all the files of a project and their history
of changes are stored. A repository can be local, which
means it’s stored on your computer, or remote, which
means it’s stored on a server.
Git’s distributed architecture makes it possible to work
offline on your local repository, and then push your
changes to a remote repository when you’re ready. This
remote repository is typically a version of your project
that is hosted on the Internet or network somewhere. This
makes collaboration and version control efficient, even
with large codebases and teams.
How Does Git Work?
To track changes in your project, Git uses a feature known
as a commit. Commits in a Git repository are like
snapshots of your project at a particular point in time.
With commits, you can revert to previous versions of your
project, compare changes over time, and identify when
and where changes were made.
These snapshots are stored within a directory at the root
of your project called .git, which is created when a new
Git repository is initialized. This directory is hidden by
default on most systems and contains all the information

necessary for Git to manage your project’s history. To
see the contents of the .git directory, you might need
to enable the option to show hidden files in your file
explorer.
Whenever you make a commit, Git saves a snapshot of
what all your files look like at that moment. This is
different from some other VCSs, which store data as a list
of file-based changes.
Why Use Git?
Here are a few reasons you might want to use Git for your
projects:
• Speed: Git is fast. Since you have the entire reposi-
tory and history on your local machine, most opera-
tions are almost instantaneous.
• Collaboration: Git’s distributed nature makes it easy
for teams to work together. Different members can
work on different features in parallel.
• Data Integrity: Git uses a cryptographic hash func-
tion called “SHA-1” to generate unique identifiers for
each commit. This helps ensure data integrity and
tracks changes, contributing to the protection of your

files, directory structure, and history from unnoticed
modifications or corruption.
• Flexibility: Whether you’re a solo developer work-
ing on a small project or part of a multinational team
on an enterprise application, Git can scale to your
needs.
• Open Source: Git is free and open source. It has
a large, active community of contributors, which
means it’s continually being improved and updated.
• Integration: Git integrates well with various devel-
opment tools and platforms, making it versatile in
different workflows.
In Summary:
Git is not just an ordinary tool—it’s an entire ecosystem
that stands on its own. The combination of its decen-
tralized structure, exceptional efficiency, and flexibility
makes it the favored version control system among many
developers. As we progress through this book, you’ll ob-
tain hands-on knowledge and understand how to harness
Git’s potential to manage your code effectively.

Git vs GitHub: What’s the Difference?
One of the common questions everyone new to version
control has is the distinction between Git and GitHub.
Although they sound similar and are closely related, they
serve different purposes. Let’s demystify these two and
understand how they complement each other.
Understanding Git
As we discussed in the previous section, Git is a version
control system. It is a tool that manages the source code
history and allows multiple developers to work on a single
project without stepping on each other’s toes. Git is
software that you install locally on your computer, and
it works primarily from the command line (though there
are also graphical user interfaces for Git).
Key Points about Git:
• It is a Distributed Version Control System (DVCS).
• It allows you to track changes, create branches, and
collaborate in your local code repository.
• Git does not require an internet connection for most
operations.

• It is free and open source.
Understanding GitHub
GitHub, on the other hand, is a web-based platform that
uses Git for version control. Think of it as a social
networking site for coders and their code. It allows you
to upload your Git repositories online, making it easier
to collaborate with others. GitHub provides additional
features such as Pull Requests, Issues, and Wikis for your
repositories.
Key Points about GitHub:
• It is a hosting service for Git repositories.
• It facilitates collaboration by making it easy to share
repositories and work with others.
• GitHub offers additional features such as Pull Re-
quests, code reviews, and Issue tracking. We’ll dis-
cuss these in detail in later chapters.
• GitHub can be integrated with third-party tools and
services, such as continuous integration systems,
code quality measurement tools, and project
management applications.

• GitHub provides several security features such as se-
curity vulnerability alerts, automated security fixes,
and token scanning to protect repositories and user
data.
How They Complement Each Other
Git is mainly a local tool; you use it to track changes
on your computer. It is powerful on its own, but its
capabilities are magnified when you bring GitHub into
the mix. With GitHub, you can share your code with
the world, collaborate with other developers, and even
integrate third-party apps and services.
When to Use Git and When to Use
GitHub
• Use Git when you are working on a project (either
alone or with a team) and need to keep track of the
changes in your code.
• Use GitHub when you want to share your project
with others, collaborate more efficiently, or when
you need a remote backup of your repository.

In Summary:
Git is the tool, and GitHub is the service that hosts your
repositories and enhances collaboration. They are distinct
but complementary. While you can use Git without using
GitHub, utilizing them together creates a more powerful
and efficient workflow, especially for collaboration on
larger projects or open-source contributions. Next, we’ll
look at other version control systems and how they com-
pare to Git.

Other Version Control Systems
While Git is undoubtedly one of the most popular version
control systems, it is by no means the only one. There are
several other VCSs, each with their unique features and
strengths. It’s beneficial to know that alternatives exist,
as different projects may have different needs. Let’s take
a brief look at some other prominent VCSs.
Subversion (SVN)
Subversion, also known as SVN, is a centralized version
control system initially developed by CollabNet Inc in
2000, and now maintained by the Apache Software Foun-
dation. Unlike Git, which is a distributed system, SVN
follows a more linear approach to version control.
While SVN does support branching and merging, the
mechanism is quite different and can be more cumber-
some compared to Git. SVN requires a connection to the
central repository for commits, but it can track changes
offline to some extent. Some teams find SVN straight-
forward and suitable when transitioning from a no-VCS
setup, but it lacks some of the robust features offered by
distributed systems like Git.

Mercurial
Mercurial is a distributed version control system like Git,
but it was designed with simplicity in mind. Its commands
and workflow are more straightforward, making it easier
to learn, especially for those new to version control.
While Mercurial supports most of the basic features of Git,
such as local commits and easy branching, its simplicity
does come at the cost of fewer features by default. How-
ever, it does have a robust plugin system that allows you
to extend its functionality.
Perforce
Perforce, or Helix Core, is a version control system that
is widely used in the gaming industry. It excels in
handling large binary files, making it an excellent choice
for projects like game development, where you’re dealing
with 3D models, textures, and other large assets.
However, Perforce operates as a centralized version con-
trol system and is proprietary software. So depending
on your project’s needs or team size, you might need to
purchase a license.
Unlike Git, Perforce lacks a distributed architecture and
does not support local repositories in the same way that

Git does.
Concurrent Versions System (CVS)
Concurrent Versions System, first released in 1986, is
an older centralized version control system, once widely
used in the open-source community. CVS allows multiple
developers to work simultaneously on a project, a notable
advancement when it was introduced.
However, CVS is less efficient with large projects or binary
files and has a more error-prone branching and merging
system compared to newer VCS like Git or SVN. Develop-
ment on CVS has slowed significantly, and it lacks many
features found in contemporary systems. Today, CVS is
mostly used in projects that adopted it before modern
systems were available and have not yet migrated to a
newer VCS.
In Summary:
Different version control systems have different strengths
and are suited to different types of projects. While Git’s
robustness, flexibility, and widespread adoption make it
the tool of choice for most software development projects,
other systems may be more suited to specific use cases.
The key is to understand your project’s needs and the
capabilities of each VCS. Regardless of the specific system

you use, the important thing is that you use version
control. It’s an essential tool for modern software de-
velopment. In the following chapters, we will focus on
mastering Git, but many of the principles and practices
you’ll learn will apply to other version control systems as
well.

Installing Git
Now that we’ve learned what version control is and have
a basic understanding of Git, it’s time to start using
Git practically. The first step is to install Git on your
computer. This section will guide you through the process
of installing Git on Windows, macOS, and Linux.
Installing Git on Windows
1. Go to the official Git website at git-scm.com1.
2. Click on the “Download” button for Windows.
3. Once the installer is downloaded, run the .exe file.
4. During the installation, you can leave the default
options selected or customize them according to your
preferences.
5. Click “Install” to begin the installation process.
6. Once the installation is complete, you may need
to restart your computer or your command promp-
1https://git-scm.com

t/PowerShell terminal to ensure Git is accessible from
any command prompt.
7. You can open the Git Bash application, which is a
command-line interface for using Git on Windows.
Installing Git on macOS
1. Git might be preinstalled on macOS. You can check
this by typing git --version in the terminal. If it’s
already installed, you’ll see the Git version displayed.
2. If you don’t have Git or want to install a newer
version, the easiest way to install Git is using Home-
brew. If you don’t have Homebrew, you can install it
by visiting brew.sh2 and following the instructions.
3. After installing Homebrew, you can install Git by
typing brew install git in the terminal, and
pressing Enter.
4. To check if Git was installed successfully, type git
--version in the terminal. It should display the
installed Git version.
2https://brew.sh

Installing Git on Linux
1. On a Linux system, you can use the package manager
that comes with your distribution to install Git.
2. For Debian/Ubuntu-based systems, open a terminal
and type sudo apt-get update followed by sudo
apt-get install git.
3. For Red Hat/Fedora-based systems, use sudo dnf
install git.
4. Please note, other distributions might require differ-
ent commands or procedures.
5. To confirm that Git is installed, type git --version
in the terminal. This will show you the version of Git
that’s installed.
Configuring Git
After installing Git, it’s a good idea to configure it with
your information.
1. Open your terminal or Git Bash (on Windows).

2. Type git config --global user.name "Your
Name" and press Enter.
3. Type git config --global user.email "youre-
mail@example.com" and press Enter.
This sets up your name and email as the author of your
commits. It’s important because every commit you make
will include this information.
Wrapping Up
Congrats! You have successfully installed and configured
Git on your system. You’re now ready to start creating
repositories, making commits, and delving deeper into
version control. In the next chapter, we’ll take a closer
look at creating your first repository and making your first
commit. Let’s dive right in!

2. Getting Started
with Git - Command
Line and GUI
In this chapter, we’ll discuss how to interact with Git, both
through the command line Interface (CLI) and Graphical
User Interface (GUI) tools, with a focus on understanding
when to use each. We’ll walk through some basic Git
commands and use Visual Studio Code to perform them
in a GUI. This chapter concludes by guiding you through
creating your first Git repository and making your first
commit.
• 2.1 Basic Git Commands
• 2.2 CLI vs GUI: Understanding the Differences
and When to Use Each
• 2.3 Performing Basic Commands in VSCode
• 2.4 Creating Your First Repository and Making
Your First Commit

2. Getting Started with Git - Command Line and GUI 28
• 2.5 Viewing the Commit History and Reverting
To A Previous Commit

Basic Git Commands
Before we dive into creating repositories and making
commits, it’s essential to familiarize yourself with some
basic Git commands. These commands form the bedrock
of your interactions with Git and will be used frequently
throughout your Git journey.
Let’s start by looking at some of the most common Git
commands you’ll use. Remember, practice makes perfect.
So, as you read, try to follow along by typing the com-
mands on your own computer.
git init
The git init command is used to create a new Git
repository. When you run this command in a directory,
Git initializes a new repository in it. This means that
Git starts keeping track of your files and changes in that
directory. You can run this command in any directory to
create a new repository there:
$ git init
The dollar sign ($) is used to indicate the command
prompt, so you don’t need to type it too.

git clone
The git clone command allows you to create a copy of
an existing Git repository in your local machine. This is
especially useful when you want to work on a project that
is hosted on a remote repository, like GitHub.
$ git clone <repository-url>
git add
The git add command is used to stage changes for a
commit. It tells Git that you want to include the updates
to a particular file(s) in the next commit. This includes
new files, modifications to existing files, and the deletion
of files. Here, the term “staging” refers to the process of
preparing files for a commit. The “staging area” is where
Git keeps track of the changes that are to be included in
the next commit.
$ git add <file-name>
To add all new and modified files in the current directory
and its subdirectories to the staging area, use the . (dot)
as the file name:

$ git add .
The git add command also has a -A flag that allows
you to stage all changes, including all new, modified, and
deleted files in the entire repository, not just the current
directory and its subdirectories:
$ git add -A
git commit
The git commit command is used to save your changes
to the local repository. This step takes the files as they are
in the staging area and stores a snapshot of these files as
a commit. A commit in Git is like a checkpoint in your
project history that you can return to at any time. Each
commit has a unique ID, often referred to as a “hash”,
which you can use to access it whenever you need to.
$ git commit -m "Commit message"
The -m flag is used to add a commit message. A commit
message is a short description of the changes you made
in the commit. It’s a good practice to write a descriptive
commit message that explains your changes accurately. In

the terminal, a flag is a way to specify the behavior of a
command. Flags are usually preceded by a hyphen (-) or
two hyphens (--).
The git commit command also has an -a flag that allows
you to automatically stage files that have been modified
and deleted, but new files that have not been tracked are
not affected:
$ git commit -a -m "Commit message"
If there are new files that you’ve never added to the
repository before, you will need to add them using git
add <file> or git add . before they can be included
in a commit.
If you need to write a longer commit message, you can
omit the -m flag and just run git commit. This will open
a text editor where you can write your commit message.
When you’re done, save the file and close the editor to
complete the commit. We’ll discuss best practices for
writing commit messages in a later chapter.
git status
The git status command displays the state of the
working directory and the staging area. It lets you see

which changes have been staged, which haven’t, and
which files aren’t being tracked by Git. This command
gives you a summary of all the changes that have been
made since the last commit, and which of these changes
are ready to be committed.
$ git status
git log
The git log command shows a list of all the commits
made to a repository. The commits are displayed in
reverse chronological order, so the most recent commit
is at the top. This command provides a history of your
project, showing the changes made in each commit, as
well as the author of the commit and the date it was made.
$ git log
These commands are just the tip of the iceberg when it
comes to interacting with Git, but they will get you started
on your journey. As we move along through the chapters,
we’ll introduce more commands and dive deeper into how
Git works.

CLI vs GUI: Understanding the
Differences
When interacting with Git, you have two main options:
the command line or a Graphical User Interface (GUI).
Both methods have their advantages and disadvantages.
Let’s explore what each offers and when it might be
appropriate to use one over the other.
Command Line Interface (CLI)
The Command Line Interface (CLI) is a text-based way to
interact with Git. As you’ve seen in the previous section,
you issue commands by typing them into a terminal or
console. This is the original way of interacting with Git,
and it’s powerful because it gives you direct access to all
Git commands.
Advantages:
• Full access to all Git features.
• Automation: CLI allows you to write scripts to auto-
mate repetitive tasks.
• Might be faster for experienced users.

Disadvantages:
• Steeper learning curve for those not familiar with a
command line.
• Requires memorizing commands and their options.
• Might be more error-prone for beginners.
Graphical User Interface (GUI)
GUI tools for Git are applications that provide a visual
interface for interacting with repositories. These tools
are often easier for beginners because they don’t require
memorizing commands.
Advantages:
• User-friendly: Visual representation makes it more
intuitive.
• Easier to learn for those not familiar with the com-
mand line.
• No need to remember commands; options are usually
available through menus.

Disadvantages:
• Might not have support for all Git features.
• Automation is limited compared to the command
line.
• Some GUI tools might not be updated as frequently
as Git itself.
• Might be more difficult to troubleshoot issues.
When to Use CLI or GUI?
• Use the CLI if you’re comfortable with text-based
commands, need to use advanced Git features, or
want to automate tasks using scripts.
• Use a GUI if you’re new to Git, prefer a visual
representation, or don’t have a need for advanced
features and automation.
Ultimately, many Git users find that a combination of both
the command line and a GUI tool is the most effective way
to work. You might use a GUI for day-to-day tasks and the
command line for more complex operations.

In the next section, we will explore how to perform some
basic Git commands using a popular GUI tool: VSCode.

Performing Basic Commands in
VSCode
Visual Studio Code, commonly referred to as VSCode, is
a popular code editor that comes with built-in support
for Git. This makes it an excellent tool for developers
who prefer a graphical interface over the command line.
In this section, we will explore how to perform some of
the basic Git commands we learned earlier, but this time,
using VSCode’s Git integration.
Setting Up VSCode with Git
Before we begin, make sure you have both Git and VSCode
installed on your computer. VSCode should automatically
detect Git, but if not, you can set the path to Git in the
VSCode settings.
Initializing a Git Repository
In the command line, we used git init to initialize a Git
repository. In VSCode, you can do this with the following
steps:

Random documents with unrelated
content Scribd suggests to you:

"Sympathetic vibrations," said Gerrod happily. "If you could hang up
one of those microscopic shells and ring it it would ring that note.
So, when the vibrations from the piano strike them, they vibrate in
sympathy, only the piano vibrations are so strong and the shells so
fragile that they rack themselves to bits, and the animals are killed.
Whee! Hurray! Hurray!"
He shook hands all around, hardly, able to contain his excitement.
"But I say," said Davis anxiously, "will those vibrations travel through
water, and can we put a piano overboard?"
Gerrod laughed.
"We'll put a submarine siren overboard," he said excitedly, "and tune
it to that note. You can hear a submarine siren for fifteen miles with
an under-water telephone. Man, you've done the trick!"
The maid appeared in the doorway.
"Some one on the telephone for Miss Morrison."
Nita reluctantly left the room where the others were chattering
excitedly. She went to the telephone and put the receiver to her ear,
still unconsciously trying to catch the words of the party in the music
room. Almost the first words she heard drove them from her mind,
however. Her father was speaking.
"Nita," he was saying coolly, "this is your father. I'm marooned in the
house on the island, and the Silver Menace is climbing up the walls.
The windows are blocked. I'm expecting them to break in any
minute. When they do I'm done."
"Daddy!" Nita choked, aghast.
"Simmons, the chauffeur, tried to get across the bridge this
morning," said her father still more coolly, "and the sticky stuff got
him. The room I'm in is dark. The Silver Menace has climbed up to
the roof. We've stopped up the chimney so it can't come down to get
us, but when the house is completely covered we'll be in an air-tight
case that will suffocate us sooner or later. I'm rather hoping the

windows will break in before that time. I'd rather die like Simmons
this morning."
"But, daddy, daddy, hold on! We'll come to you——"
"It can't be done," her father interrupted crisply. "I called you to say
good-by and to tell you to look after the families of the servants that
are fastened up here with me." He paused a moment, and said
quietly: "I'm in the library downstairs. I can hear the windows
creaking. They may give way at any moment and let the horror into
the house. It tried to creep in under the doorsills, but we calked
them with the table linen."
"Daddy!" cried Nita agonizedly. "Oh, daddy, try to fight it off just a
little while! We've found a way to stop it! We can kill them all!"
"I have about ten minutes more, Nita," said her father gently. "You
couldn't get to me. Be a good girl, Nita——" There was a crash.
"There go the windows! Good-by, Nita, good-by——"
The others heard her cry out, and rushed from the music room to
hear her calling, calling desperately for her father to answer her,
calling into a silent phone.
CHAPTER IX.
Davis pounded mightily upon the great gate of the half-deserted
shipyard. Behind him, Nita was sobbing in spite of her efforts to hold
back her tears. Evelyn tried her best to calm Nita, but without real
effect. Gerrod had shot the party out at the gate of the shipyard and
darted off in the little motor car on some mysterious errand. Davis
pounded again wrathfully, using a huge stone to make his blows
reverberate through the yard. A workman came slowly toward them.
"Hurry! Hurry!" Nita called tearfully. "Please hurry!"

The workman recognized her through the palings. All of Morrison's
employees knew his daughter. The workman broke into a run. The
gate swung open.
"Where's Mr. Keeling, the manager?" demanded Nita urgently. "We
must see him at once."
The workman pointed, and the three of them hurried as fast as they
could walk toward the man he had indicated.
"Mr. Keeling," said Nita desperately. "Father is marooned in our
house up the Hudson. He may be dead by now. We've got to get to
him!"
"I don't know how——" began the manager helplessly.
"I want a submarine siren," said Davis crisply. "One that can be
tuned to different notes. Also the fastest motor boat you have. Give
the necessary orders at once."
"But the Silver Menace——" began the manager again.
"Don't stand there talking," barked Davis in a tone that secured
instant obedience. "Get the siren and the boat. And hurry! This is life
and death!"
Galvanized into action, but still confused, the manager gave the
orders. A fast motor boat that had been hauled ashore and pot into
a shed when the Silver Menace blocked the river was hauled out. A
heavy submarine siren was hastily unearthed from one of the
workshops, and Davis drove the workmen to the task of fitting a
sling on the boat by which the siren could be lowered over the bow.
A heavy crane was run up and the motor boat made fast, in
readiness to be lifted overboard. Every one worked with the utmost
speed of which they were capable. Davis was not his usual good-
natured self now. He drove his workmen mercilessly. Hardly had the
last of their preparations been completed when a heavy truck
rumbled into the yard. Gerrod had commandeered the truck and
worked wonders. A grand piano had been lifted bodily into the big
automobile. As the truck stopped he was lifting the lid that protected

the keys. An electrician stood by the siren, with the tuning apparatus
exposed. Hardly had the engine of the truck been shut off when
they were busy tuning the blast of the siren to match the tinkling
sound of the piano. It took a heart-breakingly long time to get the
pitches precisely alike, but then the launch swung high in the air and
alighted on the surface of the jelly below. The electrician in the
launch pressed the button that would set the siren at work sending
out its blast of sound waves through the water.
Those on the bank watched in agonized apprehension. The siren
sank into the jelly like mass. No audible sound issued from it, once it
was submerged, but when the curious sound waves issued into the
water from the giant metal plate that in normal times carried
warnings to ships at sea a change was visible in the jelly. Where
ever the curious water sound traveled the silvery jelly clouded and
abruptly turned to liquid! Almost instantly the space between the
two wharves, in which the launch lay, was free of the horrible stuff.
Gerrod shouted excitedly. Davis swore happily. Nita pushed anxiously
forward.
"We've got to get to daddy!" she cried desperately. "We mustn't
waste a second! Not an instant!"
The four of them piled into the launch. An engineer leaped down
and twisted the motor. The fast launch shot forward, the submarine
siren at the bow sending out its strange water sound that was
inaudible to those on board, but which had such an amazing effect
on the microscopic animals that composed the silver sea. As the
launch gathered speed and headed up the Hudson a high bow wave
spread out on either side. The water on which they rode was
yellowed and malodorous, but it was water, and not the silvery, slime
that had threatened the world. The Silver Menace vanished before
the launch as if by magic. When the motor boat approached, with its
siren still sounding fiercely, though inaudibly, the jellied surface of
the river shivered into yellowed liquid, and the creeping horror on
the banks trembled and became a torrent of water that flowed
eagerly back into the bed of the stream.

The island on which Morrison had been marooned loomed up ahead,
looking like a small mountain of silver. The house at its top was as a
monument of shining metal. But as the boat sped toward it the
silvery appearance of the coating clouded and melted away. Instead
a torrent of evil-smelling water poured down the sloping sides of the
island and into the river again!
They found the servants weeping for joy. Morrison, when the
windows of the library had broken in under the weight of the mass
of the horror outside, had leaped through the door of the library and
slammed the door behind him. They had calked the cracks with
cloth, and for a moment isolated the Silver Menace in that one room.
As window after window broke in, however, they had been forced to
withdraw from room to room, until at last they were huddled
together in a tiny linen closet, windowless and without ventilation.
They were waiting there for death when they heard the rushing of
water all about them and found the Silver Menace, silver and a
menace no longer, flowing down to rejoin the waters from which it
had come.
As is the way of women, Nita, having sobbed heartbrokenly for
sorrow when she believed her father dead, now sobbed even more
heartbrokenly for joy at finding him alive, but she did not neglect,
after a reasonable interval, to bring Davis forward.
"You know him, daddy," she said, smiling. "Well, he is the person
who found the way to destroy the Silver Menace, and so he's the
person you are going to pay that big reward to."
Morrison shook hands with Davis. He knew what was coming next.
"And though it hasn't anything to do with the other things," Nita said
proudly, "he's the person I'm going to marry."
"It would be ungracious," observed Morrison, "to disagree with you.
Mr. Davis, you are a lucky man."
"I know it," said Davis, laughing in some embarrassment. He looked
at Nita, who dimpled at him, and was promptly and frankly kissed

for her daring. She did not seem to mind, however. In fact, she
dimpled again.
The last vestige of the Silver Menace was turned to yellowed water
within a month. Submarine sirens, carefully tuned to precisely the
pitch that would cause the tiny shells to shatter themselves, were
hastily set aboard huge numbers of fast steamers, that swept the
ocean in patrols, clearing the sea as they went. Whenever the clear
note was poured out by one of the under-water sirens the silvery
animalcules died in their myriads. Slowly, as the evil smell of their
bodies dissipated, the inhabitants of the Atlantic Ocean came back to
their normal haunts. By shoals and schools, by swarms and in tribes,
the fishes came down again from the North. A week after the
destroying steamers began their patrol rain fell on the Atlantic coast.
The abnormally dry air above the ocean took up water avidly and
poured it down on the parched earth with a free hand. The ocean,
too, took up again its former function of furnishing cool breezes
during the day and warm breezes at night. The seashore became
once more a place of charm and delight. At least Davis and Nita
found it so. Davis was being waited upon with decorations and
honorary degrees, with the freedom of cities and medals of honor
from learned societies. At each presentation solemn speeches were
made in which he was told how superlatively clever he was.
Remembering the purely accidental nature of his discovery, he found
it difficult to keep from laughing. These things were tiresome, but
were not active nuisances until after his marriage. When he found
that he and Nita would not be left alone, that no matter how
scrupulously they concealed their identity it was sooner or later
discovered and they were interviewed and written up in special
articles for the newspapers he grew annoyed.
The climax came on a beautifully moonlit night at a seashore resort
where they were quite confident they would not be discovered. The
beach was like silver, and the waves were dark and mysterious,

except where the reflection of the moon glittered on their shining
sides. Davis and Nita, forgetting the world and devoutly hoping that
they were by the world forgot, sat and looked at the moon and
played idly in the sand and told each other the eternal foolishnesses
that are probably the truest wisdom. They were utterly happy just
being alone with each other.
A dark figure looked up over and coughed. They started.
"You are Flight Commander and Mrs. Davis?" said a voice
deprecatingly.
Davis groaned and admitted it.
"Our little villagers learned that you are visiting here, and a banquet
has been prepared in the pavilion in your honor. Won't you do us the
honor to attend?"
Davis muttered several words under his breath, for which Nita later
reprimanded him, and rose heavily.
The banquet was a great success. The freedom of the village was
given them both. Speeches were made, in which Davis was told how
superlatively clever he was. The band played "See the Conquering
Hero Comes." Davis sat miserably through it all, with Nita, scarcely
less miserable, by his side.
The next morning he sent a wire to Teddy Gerrod:
Can we come and spend our honeymoon with you? People
won't let us alone.
Davis.
Within an hour the answer came:
Come along. We'll let you alone. We're having a second
honeymoon ourselves.
Gerrod.

Davis showed the wire to Nita.
"Splendid!" she said with a sigh of relief. Then she dimpled and
looked up at Davis. "But, Dicky, dear, we'll never have a second
honeymoon like they are having."
"We won't?" demanded Davis. "Why not?"
"Because," said Nita, putting her face very close to his. "Because our
first one is never going to stop."
THE END.

*** END OF THE PROJECT GUTENBERG EBOOK THE SILVER
MENACE ***
Updated editions will replace the previous one—the old editions will
be renamed.
Creating the works from print editions not protected by U.S.
copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying
copyright royalties. Special rules, set forth in the General Terms of
Use part of this license, apply to copying and distributing Project
Gutenberg™ electronic works to protect the PROJECT GUTENBERG™
concept and trademark. Project Gutenberg is a registered trademark,
and may not be used if you charge for an eBook, except by following
the terms of the trademark license, including paying royalties for use
of the Project Gutenberg trademark. If you do not charge anything
for copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.
START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE

PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK
To protect the Project Gutenberg™ mission of promoting the free
distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.
Section 1. General Terms of Use and
Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.
1.B. “Project Gutenberg” is a registered trademark. It may only be
used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.

1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.
1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.
1.E. Unless you have removed all references to Project Gutenberg:
1.E.1. The following sentence, with active links to, or other
immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.
1.E.2. If an individual Project Gutenberg™ electronic work is derived
from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.
1.E.3. If an individual Project Gutenberg™ electronic work is posted
with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.
1.E.4. Do not unlink or detach or remove the full Project
Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.
1.E.5. Do not copy, display, perform, distribute or redistribute this
electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1

with active links or immediate access to the full terms of the Project
Gutenberg™ License.
1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.
1.E.7. Do not charge a fee for access to, viewing, displaying,
performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.
1.E.8. You may charge a reasonable fee for copies of or providing
access to or distributing Project Gutenberg™ electronic works
provided that:
• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information

about donations to the Project Gutenberg Literary Archive
Foundation.”
• You provide a full refund of any money paid by a user who
notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.
• You provide, in accordance with paragraph 1.F.3, a full refund of
any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.
• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.
1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™
electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.
1.F.
1.F.1. Project Gutenberg volunteers and employees expend
considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or

damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.
1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for
the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.
1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you
discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.
1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.
1.F.5. Some states do not allow disclaimers of certain implied
warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.
1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,
the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.
Section 2. Information about the Mission
of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.
Volunteers and financial support to provide volunteers with the
assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will

remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.
Section 3. Information about the Project
Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.
The Foundation’s business office is located at 809 North 1500 West,
Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact
Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many

small donations ($1 to $5,000) are particularly important to
maintaining tax exempt status with the IRS.
The Foundation is committed to complying with the laws regulating
charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.
While we cannot and do not solicit contributions from states where
we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.
International donations are gratefully accepted, but we cannot make
any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.
Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.
Section 5. General Information About
Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.

Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.
Most people start at our website which has the main PG search
facility: www.gutenberg.org.
This website includes information about Project Gutenberg™,
including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.

Git Prodigy Mastering Version Control with Git and GitHub Ebenezer Don

More Related Content

Similar to Git Prodigy Mastering Version Control with Git and GitHub Ebenezer Don (20)

Recently uploaded (20)

Git Prodigy Mastering Version Control with Git and GitHub Ebenezer Don