<commit_before>#A Git Crash Course {#chapter-git}

We strongly recommend that you spend some time familiarising yourself with a [version control](https://en.wikipedia.org/wiki/Version_control) system for your application's codebase. This chapter provides you with a crash course in how to use [Git](http://en.wikipedia.org/wiki/Git_(software)), one of the many version control systems available. Originally developed by [<NAME>](http://en.wikipedia.org/wiki/Linus_Torvalds), Git is today [one of the most popular version control systems in use](https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Popularity), and is used by open-source and closed-source projects alike.

This tutorial demonstrates at a high level how Git works, explains the basic commands that you can use, and provides an explanation of Git's workflow. By the end of this chapter, you'll be able to make contributions to a Git repository, enabling you to work solo, or in a team.

## Why Use Version Control?

As your software engineering skills develop, you will find that you are able to plan and implement solutions to ever more complex problems. As a rule of thumb, the larger the problem specification, the more code you have to write. The more code you write, the greater the emphasis you should put on software engineering practices. Such practices include the use of design patterns and the *DRY (Don't Repeat Yourself)* principle.

As a result of this complexity, software projects can contain many source code files. With it likely that more than one contributor exists within a given project, it can become difficult to avoid conflicts when working on files. Have you ever encountered one or more of the following situations:

* Made a change to code, realised it was a mistake and wanted to go back?
* Lost code (through a faulty drive), or had a backup that was too old?
* Had to maintain multiple versions of a product (perhaps for different organisations)?
* Wanted to see the difference between two (or more) versions of your codebase?
* Wanted to show that a particular change broke of fixed a piece of code?
* Wanted to submit a change (patch) to someone else's code?
* Wanted to see how much work is being done (where it was done, when it was done, or who did it)?
* Wanted to experiment with a new feature without interfering without working code?

Using a version control system makes your life easier in *all* of the above cases. While using version control systems at the beginning may seem like a hassle it will pay off later - so it's good to get into the habit now!

I> ### Using Git on Windows
I> Like Python, Git doesn't come as part of a standard Windows installation. However, Windows implementations of the version control system can be downloaded and installed. You can download the official Windows Git client from the Git [website](http://git-scm.com/download/win). The installer provides the `git` command line program, which we use in this crash course. You can also download a program called *TortoiseGit*, a graphical extension to the Windows Explorer shell. The program provides a really nice right-click Git context menu for files. This makes version control really easy to use. You can [download TortoiseGit](https://code.google.com/p/tortoisegit/) for free. Although we do not cover how to use TortoiseGit in this crash course, many tutorials exist online for it. Check [this tutorial](http://robertgreiner.com/2010/02/getting-started-with-git-and-tortoisegit-on-windows/) if you are interested in using it.
I>
I> We recommend however that you stick to the command line program. If you switch to a *NIX development environment at a later stage, you'll be glad you know the commands!

## How Git Works

Essentially, Git comprises of four separate storage locations: your **workspace**, the **local index**, the **local repository** and the **remote repository**. As the name may suggest, the remote repository is stored on some remote server, and is the only location stored on a computer other than your own. This means that there are two copies of the repository - your local copy, and the remote copy. Having two copies is one of the main selling points of Git over other version control systems. You can make changes to your local repository when you may not have Internet access, and then apply any changes to the remote repository at a later stage. Only once changes are made to the remote repository can other contributors see your changes.

D> ### What is a Repository?
D> We keep repeating the word *repository*, but what do we actually mean by that? In the context of version control systems, consider a repository as a data structure that contains a set of *commit objects*, and a set of references to commit objects, called *heads*. You can find out more about what these are on [this Git tutorial](http://www.sbf5.com/~cduan/technical/git/git-1.shtml) - and we will be explaining what the terminology for head means later on.

For now though, let's provide an overview of each of the different aspects of the Git system. We'll recap some of the things we've already mentioned just to make sure it makes sense for you.

* As already explained, the **remote repository** is the copy of your project's repository stored on some remote server. This is particularly important for Git projects that have more than one contributor - you require a central place to store all the work that your team members produce. You could set up a Git server on a computer with Internet access and a properly configured firewall (check out [this Git server tutorial](http://www.seifeet.com/2012/11/centos-63-configuring-git-server.html), for example), or simply use one of many services providing free Git repositories. One of the most widely used services available today is [GitHub](https://github.com/). In fact, this book has a Git [repository](https://github.com/leifos/tango_with_django_19) on GitHub!
* The **local repository** is a copy of the remote repository stored on your computer (locally). It is to this repository you make all your additions, changes and deletions. When you reach a particular milestone, you can then *push* all your local changes to the remote repository. From there, you can instruct your team members to retrieve your changes. This concept is known as *pulling* from the remote repository. We'll explain pushing and pulling in a bit more detail shortly.
* The **local index** is technically part of the local repository. The local index stores a list of files that you want to be managed with version control. This is explained in more detail [later in this chapter](#section-git-workflow). You can have a look [here](http://stackoverflow.com/questions/4084921/what-does-the-git-index-exactly-contains) to see a discussion on what exactly a Git index contains.
* The final aspect of Git is your **workspace**. Think of this folder or directory as the place on your computer where you make changes to your version controlled files. From within your workspace, you can add new files or modify or remove previously existing ones. From there, you then instruct Git to update the repositories to reflect the changes you make in your workspace. This is important - *don't modify code inside the local repository - you only ever edit files in your workspace.*

Next, we'll be looking at how to [get your Git workspace set up and ready to go](#section-git-setup). We'll also [discuss the basic workflow](#section-git-workflow) you should use when using Git.

## Setting up Git {#section-git-setup}

Setting up your Git workspace is a straightforward process. Once everything is set up, you will begin to make sense of the directory structure that Git uses. Assume that you have signed up for a new account on [GitHub](https://github.com/) and [created a new repository on the service](https://help.github.com/articles/create-a-repo) for your project. With your remote repository setup, follow these steps to get your local repository and workspace setup on your computer. We'll assume you will be working from your `<workspace>` directory.

1.  Open a terminal and navigate to your home directory (e.g. `$ cd ~`).
2.  *Clone* the remote repository - or in other words, make a copy of it. Check out how to do this below.
3.  Navigate into the newly created directory. That's your workspace in which you can add files to be version controlled!

### How to Clone a Remote Repository

Cloning your repository is a straightforward process with the `git clone` command. Supplement this command with the URL of your remote repository - and if required, authentication details, too. The URL of your repository varies depending on the provider you use. If you are unsure of the URL to enter, it may be worth querying it with your search engine or asking someone in the know.

For GitHub, try the following command, replacing the parts below as appropriate:

{lang="text",linenos=off}
    $ git clone https://<USER>:<PASS>@github.com/<OWNER>/<REPO_NAME>.git <workspace>

where you replace

* `<USER>` with your GitHub username;
* `<PASS>` with your GitHub password;
* `<OWNER>` with the username of the person who owns the repository;
* `<REPO_NAME>` with the name of your project's repository; and
* `<workspace>` with the name for your workspace directory. This is optional; leaving this option out will simply create a directory with the same name as the repository.

If all is successful, you'll see some messages that looks like the output shown below.

{lang="text",linenos=off}
    $ git clone https://github.com/leifos/tango_with_django_19
    Cloning into 'tango_with_django_19'...
    remote: Counting objects: 18964, done.
    remote: Total 18964 (delta 0), reused 0 (delta 0), pack-reused 18964
    Receiving objects: 100% (18964/18964), 99.69 MiB | 3.51 MiB/s, done.
    Resolving deltas: 100% (13400/13400), done.
    Checking connectivity... done.

If the output lines end with `done`, everything should have worked. Check your filesystem to see if the directory has been created.

### The Directory Structure

Once you have cloned your remote repository onto your local computer, navigate into the directory with your terminal, Command Prompt or GUI file browser. If you have cloned an empty repository the workspace directory should appear empty. This directory is therefore your blank workspace with which you can begin to add files for your project.

However, the directory isn't blank at all! On closer inspection, you will notice a hidden directory called `.git`. Stored within this directory are both the local repository and local index. **Do not alter the contents of the `.git` directory.** Doing so could damage your Git setup and break version control functionality. *Your newly created workspace therefore actually contains within it the local repository and index.*

### Final Tweaks

With your workspace setup, now would be a good time to make some final tweaks. Here, we discuss two cool features you can try which could make your life (and your team members') a little bit easier.

When using your Git repository as part of a team, any changes you make will be associated with the username you use to access your remote Git repository. However, you can also specify your full name and e-mail address to be included with changes that are made by you on the remote repository. Simply open a Command Prompt or terminal and navigate to your workspace. From there, issue two commands: one to tell Git your full name, and the other to tell Git your e-mail address.

{lang="text",linenos=off}
    $ git config user.name "<NAME>"
    $ git config user.email "<EMAIL>"

Obviously, replace the example name and e-mail address with your own - unless your name actually is <NAME>.

Git also provides you with the capability to stop - or ignore - particular files from being added to version control. For example, you may not wish a file containing unique keys to access web services from being added to version control. If the file were to be added to the remote repository, anyone could theoretically access the file by cloning the repository. With Git, files can be ignored by including them in the `.gitignore` file, which resides in the root of `<workspace>`. When adding files to version control, Git parses this file. If a file that is being added to version control is listed within `.gitignore`, the file is ignored. Each line of `.gitignore` should be a separate file entry.

Check out the following example of a `.gitignore` file:

{lang="text",linenos=on}
    `config/api_keys.py`
    `*.pyc`

In this example file, there are two entries - one on each line. The first entry prompts Git to ignore the file `api_keys.py` residing within the `config` directory of your repository. The second entry then prompts Git to ignore *all* instance of files with a `.pyc` extension, or compiled Python files. This is a really nice feature: you can use *wildcards* to make generic entries if you need to!

I> ### `.gitignore` - What else should I ignore?
I> There are many kinds of files you could safely ignore from being committed and pushed to your Git repositories.
I> Examples include temporary files, databases (that can easily be recreated) and operating system-specific files. Operating system-specific files include configurations for the appearance of the directory when viewed in a given file browser. Windows computers create `thumbs.db` files, while OS X creates `.DS_Store` files.
I>
I> When you create a new repository on GitHub, the service can offer to create a `.gitignore` file based upon the languages you will use in your project, which can save you some time setting everything up.

## Basic Commands and Workflow {#section-git-workflow}

With your repository cloned and ready to go on your local computer, you're ready to get to grips with the Git workflow. This section shows you the basic Git workflow - and the associated Git commands you can issue.

{id="fig-git-sequence"}
![](images/git-sequence.png)

We have provided a pictorial representation of the basic Git workflow as shown above. Match each of the numbers in the black circles to the numbered descriptions below to read more about each stage. **Refer to this diagram whenever you're unsure about the next step you should take - it's very useful!**

### 1. Starting Off

Before you can start work on your project, you must prepare Git for your
forthcoming geek session. If you haven't yet sorted out your project's
Git workspace, you'll need to `clone` the repository to obtain a copy of
all of its files. Check out Section requirements-git-clone-label for
more information on how to achieve this.

If you have previously made a clone of the remote repository, it's good
practice to get into the habit of updating you local copy by using the
`git pull` command. This 'pulls' changes from the remote repository. By
doing this, you'll be working from the same page as your team members,
which will help keep the issue of conflicting file contents from making
your life a nightmare.

### 2. Doing Some Work!

Once your workspace has been updated with the latest changes, the onus
is on you to do some work! Within your workspace, you can take existing
files and modify them. You can delete them too, or add new files to be
version controlled.

It's not all plain sailing, however. You must be aware that as you work
away, you need to keep Git up-to-date on the list of files you have
added, removed or updated by modifying the *local index*. The list of
files stored within the local index are then used to perform your next
*commit*, which we'll be discussing in the next step. To keep Git
informed, there are several Git commands which let you update the local
index. Three of the commands are near-identical to those that were
discussed in Chapter requirements-label, with the addition of a `git`
prefix.

-   The first command `git add` allows you to request Git to add a
    particular file to the next commit for you. A common newbie mistake
    is to assume that `git add` is used for adding new files to your
    repository only - *this is not the case! You must tell Git what
    modified files you wish to commit, too!* The command can be used in<commit_msg>Updating Git chapter<commit_after>#A Git Crash Course {#chapter-git}

We strongly recommend that you spend some time familiarising yourself with a [version control](https://en.wikipedia.org/wiki/Version_control) system for your application's codebase. This chapter provides you with a crash course in how to use [Git](http://en.wikipedia.org/wiki/Git_(software)), one of the many version control systems available. Originally developed by [<NAME>](http://en.wikipedia.org/wiki/Linus_Torvalds), Git is today [one of the most popular version control systems in use](https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Popularity), and is used by open-source and closed-source projects alike.

This tutorial demonstrates at a high level how Git works, explains the basic commands that you can use, and provides an explanation of Git's workflow. By the end of this chapter, you'll be able to make contributions to a Git repository, enabling you to work solo, or in a team.

## Why Use Version Control?

As your software engineering skills develop, you will find that you are able to plan and implement solutions to ever more complex problems. As a rule of thumb, the larger the problem specification, the more code you have to write. The more code you write, the greater the emphasis you should put on software engineering practices. Such practices include the use of design patterns and the *DRY (Don't Repeat Yourself)* principle.

As a result of this complexity, software projects can contain many source code files. With it likely that more than one contributor exists within a given project, it can become difficult to avoid conflicts when working on files. Have you ever encountered one or more of the following situations:

* Made a change to code, realised it was a mistake and wanted to go back?
* Lost code (through a faulty drive), or had a backup that was too old?
* Had to maintain multiple versions of a product (perhaps for different organisations)?
* Wanted to see the difference between two (or more) versions of your codebase?
* Wanted to show that a particular change broke of fixed a piece of code?
* Wanted to submit a change (patch) to someone else's code?
* Wanted to see how much work is being done (where it was done, when it was done, or who did it)?
* Wanted to experiment with a new feature without interfering without working code?

Using a version control system makes your life easier in *all* of the above cases. While using version control systems at the beginning may seem like a hassle it will pay off later - so it's good to get into the habit now!

I> ### Using Git on Windows
I> Like Python, Git doesn't come as part of a standard Windows installation. However, Windows implementations of the version control system can be downloaded and installed. You can download the official Windows Git client from the Git [website](http://git-scm.com/download/win). The installer provides the `git` command line program, which we use in this crash course. You can also download a program called *TortoiseGit*, a graphical extension to the Windows Explorer shell. The program provides a really nice right-click Git context menu for files. This makes version control really easy to use. You can [download TortoiseGit](https://code.google.com/p/tortoisegit/) for free. Although we do not cover how to use TortoiseGit in this crash course, many tutorials exist online for it. Check [this tutorial](http://robertgreiner.com/2010/02/getting-started-with-git-and-tortoisegit-on-windows/) if you are interested in using it.
I>
I> We recommend however that you stick to the command line program. If you switch to a *NIX development environment at a later stage, you'll be glad you know the commands!

## How Git Works

Essentially, Git comprises of four separate storage locations: your **workspace**, the **local index**, the **local repository** and the **remote repository**. As the name may suggest, the remote repository is stored on some remote server, and is the only location stored on a computer other than your own. This means that there are two copies of the repository - your local copy, and the remote copy. Having two copies is one of the main selling points of Git over other version control systems. You can make changes to your local repository when you may not have Internet access, and then apply any changes to the remote repository at a later stage. Only once changes are made to the remote repository can other contributors see your changes.

D> ### What is a Repository?
D> We keep repeating the word *repository*, but what do we actually mean by that? In the context of version control systems, consider a repository as a data structure that contains a set of *commit objects*, and a set of references to commit objects, called *heads*. You can find out more about what these are on [this Git tutorial](http://www.sbf5.com/~cduan/technical/git/git-1.shtml) - and we will be explaining what the terminology for head means later on.

For now though, let's provide an overview of each of the different aspects of the Git system. We'll recap some of the things we've already mentioned just to make sure it makes sense for you.

* As already explained, the **remote repository** is the copy of your project's repository stored on some remote server. This is particularly important for Git projects that have more than one contributor - you require a central place to store all the work that your team members produce. You could set up a Git server on a computer with Internet access and a properly configured firewall (check out [this Git server tutorial](http://www.seifeet.com/2012/11/centos-63-configuring-git-server.html), for example), or simply use one of many services providing free Git repositories. One of the most widely used services available today is [GitHub](https://github.com/). In fact, this book has a Git [repository](https://github.com/leifos/tango_with_django_19) on GitHub!
* The **local repository** is a copy of the remote repository stored on your computer (locally). It is to this repository you make all your additions, changes and deletions. When you reach a particular milestone, you can then *push* all your local changes to the remote repository. From there, you can instruct your team members to retrieve your changes. This concept is known as *pulling* from the remote repository. We'll explain pushing and pulling in a bit more detail shortly.
* The **local index** is technically part of the local repository. The local index stores a list of files that you want to be managed with version control. This is explained in more detail [later in this chapter](#section-git-workflow). You can have a look [here](http://stackoverflow.com/questions/4084921/what-does-the-git-index-exactly-contains) to see a discussion on what exactly a Git index contains.
* The final aspect of Git is your **workspace**. Think of this folder or directory as the place on your computer where you make changes to your version controlled files. From within your workspace, you can add new files or modify or remove previously existing ones. From there, you then instruct Git to update the repositories to reflect the changes you make in your workspace. This is important - *don't modify code inside the local repository - you only ever edit files in your workspace.*

Next, we'll be looking at how to [get your Git workspace set up and ready to go](#section-git-setup). We'll also [discuss the basic workflow](#section-git-workflow) you should use when using Git.

## Setting up Git {#section-git-setup}

Setting up your Git workspace is a straightforward process. Once everything is set up, you will begin to make sense of the directory structure that Git uses. Assume that you have signed up for a new account on [GitHub](https://github.com/) and [created a new repository on the service](https://help.github.com/articles/create-a-repo) for your project. With your remote repository setup, follow these steps to get your local repository and workspace setup on your computer. We'll assume you will be working from your `<workspace>` directory.

1.  Open a terminal and navigate to your home directory (e.g. `$ cd ~`).
2.  *Clone* the remote repository - or in other words, make a copy of it. Check out how to do this below.
3.  Navigate into the newly created directory. That's your workspace in which you can add files to be version controlled!

### How to Clone a Remote Repository {#section-git-setup-clone}

Cloning your repository is a straightforward process with the `git clone` command. Supplement this command with the URL of your remote repository - and if required, authentication details, too. The URL of your repository varies depending on the provider you use. If you are unsure of the URL to enter, it may be worth querying it with your search engine or asking someone in the know.

For GitHub, try the following command, replacing the parts below as appropriate:

{lang="text",linenos=off}
    $ git clone https://<USER>:<PASS>@github.com/<OWNER>/<REPO_NAME>.git <workspace>

where you replace

* `<USER>` with your GitHub username;
* `<PASS>` with your GitHub password;
* `<OWNER>` with the username of the person who owns the repository;
* `<REPO_NAME>` with the name of your project's repository; and
* `<workspace>` with the name for your workspace directory. This is optional; leaving this option out will simply create a directory with the same name as the repository.

If all is successful, you'll see some messages that looks like the output shown below.

{lang="text",linenos=off}
    $ git clone https://github.com/leifos/tango_with_django_19
    Cloning into 'tango_with_django_19'...
    remote: Counting objects: 18964, done.
    remote: Total 18964 (delta 0), reused 0 (delta 0), pack-reused 18964
    Receiving objects: 100% (18964/18964), 99.69 MiB | 3.51 MiB/s, done.
    Resolving deltas: 100% (13400/13400), done.
    Checking connectivity... done.

If the output lines end with `done`, everything should have worked. Check your filesystem to see if the directory has been created.

### The Directory Structure

Once you have cloned your remote repository onto your local computer, navigate into the directory with your terminal, Command Prompt or GUI file browser. If you have cloned an empty repository the workspace directory should appear empty. This directory is therefore your blank workspace with which you can begin to add files for your project.

However, the directory isn't blank at all! On closer inspection, you will notice a hidden directory called `.git`. Stored within this directory are both the local repository and local index. **Do not alter the contents of the `.git` directory.** Doing so could damage your Git setup and break version control functionality. *Your newly created workspace therefore actually contains within it the local repository and index.*

### Final Tweaks

With your workspace setup, now would be a good time to make some final tweaks. Here, we discuss two cool features you can try which could make your life (and your team members') a little bit easier.

When using your Git repository as part of a team, any changes you make will be associated with the username you use to access your remote Git repository. However, you can also specify your full name and e-mail address to be included with changes that are made by you on the remote repository. Simply open a Command Prompt or terminal and navigate to your workspace. From there, issue two commands: one to tell Git your full name, and the other to tell Git your e-mail address.

{lang="text",linenos=off}
    $ git config user.name "<NAME>"
    $ git config user.email "<EMAIL>"

Obviously, replace the example name and e-mail address with your own - unless your name actually is <NAME>.

Git also provides you with the capability to stop - or ignore - particular files from being added to version control. For example, you may not wish a file containing unique keys to access web services from being added to version control. If the file were to be added to the remote repository, anyone could theoretically access the file by cloning the repository. With Git, files can be ignored by including them in the `.gitignore` file, which resides in the root of `<workspace>`. When adding files to version control, Git parses this file. If a file that is being added to version control is listed within `.gitignore`, the file is ignored. Each line of `.gitignore` should be a separate file entry.

Check out the following example of a `.gitignore` file:

{lang="text",linenos=on}
    `config/api_keys.py`
    `*.pyc`

In this example file, there are two entries - one on each line. The first entry prompts Git to ignore the file `api_keys.py` residing within the `config` directory of your repository. The second entry then prompts Git to ignore *all* instance of files with a `.pyc` extension, or compiled Python files. This is a really nice feature: you can use *wildcards* to make generic entries if you need to!

I> ### `.gitignore` - What else should I ignore?
I> There are many kinds of files you could safely ignore from being committed and pushed to your Git repositories.
I> Examples include temporary files, databases (that can easily be recreated) and operating system-specific files. Operating system-specific files include configurations for the appearance of the directory when viewed in a given file browser. Windows computers create `thumbs.db` files, while OS X creates `.DS_Store` files.
I>
I> When you create a new repository on GitHub, the service can offer to create a `.gitignore` file based upon the languages you will use in your project, which can save you some time setting everything up.

## Basic Commands and Workflow {#section-git-workflow}

With your repository cloned and ready to go on your local computer, you're ready to get to grips with the Git workflow. This section shows you the basic Git workflow - and the associated Git commands you can issue.

{id="fig-git-sequence"}
![](images/git-sequence.png)

We have provided a pictorial representation of the basic Git workflow as shown above. Match each of the numbers in the black circles to the numbered descriptions below to read more about each stage. **Refer to this diagram whenever you're unsure about the next step you should take - it's very useful!**

### 1. Starting Off

Before you can start work on your project, you must prepare Git. If you haven't yet sorted out your project's Git workspace, you'll need to [`clone` your repository to set it up](#section-git-setup-clone).

If you've already cloned your repository, it's good practice to get into the habit of updating your local copy by using the `git pull` command. This *pulls* the latest changes from the remote repository onto your computer. By doing this, you'll be working from the same page as your team members. This will reduce the possibility of conflicting versions of files, which really does make your life a bit of a nightmare.

To perform a `git pull`, first navigate to your `<workspace>` directory within your Command Prompt or terminal, then issue `git pull`. Check out the snippet below from a Bash terminal to see exactly what you need to do, and what output you should expect to see.

{lang="text",linenos=off}
    $ cd <workspace>
    $ git pull
    remote: Counting objects: 3, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (3/3), done.
    From https://github.com/someuser/somerepository
       86a0b3b..a7cec3d  master     -> origin/master
    Updating 86a0b3b..a7cec3d
    Fast-forward
     README.md | 1 +
     1 file changed, 1 insertion(+)
     create mode 100644 README.md

This example shows that a `README.md` file has been updated or created from the latest pull. 

E> ### Getting an Error?
E> If you receive `fatal: Not a git repository (or any of the parent directories): .git`, you're not in the correct directory. You need `cd` to your workspace directory - the one in which you cloned your repository to. A majority of Git commands only work when you're in a Git repository.

T> ### Pull before you Push!
T> Always `git pull` on your local copy of your repository before you begin work. **Always!**

### 2. Doing Some Work!

Once your workspace has been updated with the latest changes, the onus
is on you to do some work! Within your workspace, you can take existing
files and modify them. You can delete them too, or add new files to be
version controlled.

It's not all plain sailing, however. You must be aware that as you work
away, you need to keep Git up-to-date on the list of files you have
added, removed or updated by modifying the *local index*. The list of
files stored within the local index are then used to perform your next
*commit*, which we'll be discussing in the next step. To keep Git
informed, there are several Git commands which let you update the local
index. Three of the commands are near-identical to those that were
discussed in Chapter requirements-label, with the addition of a `git`
prefix.

-   The first command `git add` allows you to request Git to add a
    particular file to the next commit for you. A common newbie mistake
    is to assume that `git add` is used for adding new files to your
    repository only - *this is not the case! You must tell Git what
    modified files you wish to commit, too!* The command can be used in
{'fraction_non_alphanumeric': 0.05811260244684642, 'fraction_numerical': 0.006146810785128875, 'mean_word_length': 4.332013932868905, 'pattern_counts': {'":': 0, '<': 37, '<?xml version=': 0, '>': 64, 'https://': 19, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 10, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5868395', 'n_tokens_mistral': 8408, 'n_tokens_neox': 7973, 'n_words': 5212}