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 confidently, 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 development. 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 different 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

1. Introduction to Version Control 6 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 everyone 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

1. Introduction to Version Control 7 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.

1. Introduction to Version Control 8 Why is Version Control Important? Version control is essential to modern software development 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.

1. Introduction to Version Control 9 Experimentation Without Fear Being innovative and experimenting with new ideas is at the heart of software development. However, experimenting 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,

1. Introduction to Version Control 10 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.

1. Introduction to Version Control 11 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.

1. Introduction to Version Control 12 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

1. Introduction to Version Control 13 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 repository and history on your local machine, most operations 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 function called “SHA-1” to generate unique identifiers for each commit. This helps ensure data integrity and tracks changes, contributing to the protection of your

1. Introduction to Version Control 14 files, directory structure, and history from unnoticed modifications or corruption. • Flexibility: Whether you’re a solo developer working 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 development 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 obtain hands-on knowledge and understand how to harness Git’s potential to manage your code effectively.

1. Introduction to Version Control 15 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.

1. Introduction to Version Control 16 • 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 discuss 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.

1. Introduction to Version Control 17 • GitHub provides several security features such as security 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.

1. Introduction to Version Control 18 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 compare to Git.

1. Introduction to Version Control 19 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 straightforward and suitable when transitioning from a no-VCS setup, but it lacks some of the robust features offered by distributed systems like Git.

1. Introduction to Version Control 20 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 control 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

1. Introduction to Version Control 21 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

1. Introduction to Version Control 22 you use, the important thing is that you use version control. It’s an essential tool for modern software development. 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.

1. Introduction to Version Control 23 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

1. Introduction to Version Control 24 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

1. Introduction to Version Control 25 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 different 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).

1. Introduction to Version Control 26 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

2. Getting Started with Git - Command Line and GUI 29 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 commands 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.

2. Getting Started with Git - Command Line and GUI 30 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:

2. Getting Started with Git - Command Line and GUI 31 $ 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

2. Getting Started with Git - Command Line and GUI 32 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

2. Getting Started with Git - Command Line and GUI 33 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.

2. Getting Started with Git - Command Line and GUI 34 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 automate repetitive tasks. • Might be faster for experienced users.

2. Getting Started with Git - Command Line and GUI 35 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 command line. • No need to remember commands; options are usually available through menus.

2. Getting Started with Git - Command Line and GUI 36 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.

2. Getting Started with Git - Command Line and GUI 37 In the next section, we will explore how to perform some basic Git commands using a popular GUI tool: VSCode.

2. Getting Started with Git - Command Line and GUI 38 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

Recently uploaded

Git Prodigy Mastering Version Control with Git and GitHub Ebenezer Don