GIT ADD COMMAND EXPLAINED WITH EXAMPLES

INTRODUCTION

In our last article, we explained how to add content to a local git repository. There we used the git add command to add the README.md file to the repository we initialized with git. In this article, we will talk about the git add command in greater detail and will also demonstrate some common options used with the git add command with examples.

What does the ‘git add’ command really do?
This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit.  A “working tree” consist of files in the repository that you are currently working on. An “index” is the staging area where new commits are prepared. It acts as the interface between a repository and a working tree.
The index holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit.  Thus after making any changes to the working directory, and before running the commit command, you must use the add command to add any new or modified files to the index. The git add command can be performed multiple times before a commit.  It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run git add again to add the new content to the index.

Example 1: Add new/modified files to the staging area of a git repository
I’ve modified the README.md file that we created in our last article by adding a line to it.

[sahil@linuxnix my_first_repo]$ cat README.md
This is a readme file for my first git repository
This is a second line

Now if we run the git status command, git will tell us that a file has been modified and git also tells us to stage the file and commit the changes if we wish to save them.

[sahil@linuxnix my_first_repo]$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: README.md
#
no changes added to commit (use "git add" and/or "git commit -a")

Git is helpful in the sense that it displays hints about what the user should do next. So let us move the updated file to the staging area with git add and commit the changes using git commit.

[sahil@linuxnix my_first_repo]$ git add README.md
[sahil@linuxnix my_first_repo]$
[sahil@linuxnix my_first_repo]$ git commit -m "Added a line to README.md"
[master f9849b2] Added a line to README.md
1 file changed, 1 insertion(+)
[sahil@linuxnix my_first_repo]$

Notice that this time I used the git commit command with the -m option followed by a description of the commit i.e the comment. If you do not wish to open the editor to add descriptive comments to your commits then consider using the -m option with the git commit command. This is also extremely useful when you would like to use the git commit command inside a script or some other automated process. The git commit output tells us that we modified one file and the modification was the insertion of one line to the file. The plus (+) symbol indicates that a line or content was added to a file.

We’ll now explore some of the commonly used options with the ‘git add’ command with examples.

Example 2: Verbose mode
Using the verbose mode with the ‘git add’ command displays the names of the files being added to the staging area.
Given below is an example.

[sahil@linuxnix my_first_repo]$ git add -v README.md
add 'README.md'
[sahil@linuxnix my_first_repo]$

Example 3: Glob mode
Similar to the bash shell the git command allows the use of file glob expressions indicated by *.
I created a new file named README1.md in our repository and in doing so we now have two files with the extension .md in our repository.

[sahil@linuxnix my_first_repo]$ ls
README1.md README.md

If we want to add both .md files to the staging area, we would use the following command.

[sahil@linuxnix my_first_repo]$ git add -v *md
add 'README.md'
add 'README1.md'

This adds both files to the staging area.

Example 4: Add all files to the staging area
If we wish to add all files in the repository to the staging area we should use the git add command with the -A option followed by the wildcard character *. Given below is an example.

[sahil@linuxnix my_first_repo]$ ls
README1.md README.md test.txt

[sahil@linuxnix my_first_repo]$ git add -A *

This is like telling git to add all the changes made to all the files in the repository to the staging area. Here we added all three files in the repository to the staging area to be committed. We can run the git status command to verify.

[sahil@linuxnix my_first_repo]$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: README.md
# modified: README1.md
# new file: test.txt
#

Example 5: Add ignored files
Git allows us to ignore certain files from being committed to the repository. The ignoring of files is managed by using a .gitignore file in the repository. We will talk about ignoring files in a separate article dedicated to it. But if needed we could actually add ignored files to the staging area. For this, we use the git add command with the -f option to allow the forceful addition of otherwise ignored files to the staging area. A syntax example is shown below:

git add -f <file name>

CONCLUSION

In this article we explored the git add command in greater detail along with examples. We will be continuing our series of articles on git exploring more aspects of this extremely powerful and feature-rich distributed version control system.

GIT: Dry Run Before Adding to Git Repository

When something goes wrong it is important to test things before you do them so you can avoid things going wrong!

One way to do that in Git is to use the --dry-run flag with git-add.

Let’s say I have a bunch of changes and I just want to check what will happen when I run git-add to stage them for commit. Unstaging a staged change isn’t a big deal but I like to avoid problems (and fixing them!) if I can.

git add . --dry-run

Using this command I’m adding all changed files (the . means everything) but I’m only doing a simulation. When this happens I’ll get a list of files that will be included in the add and staged for the next commit.

A handy tip for the next time you want to see what happens before you do it.

GIT: How can I ignore files that have already been committed to the repo?

Git can only ignore files that are untracked - files that haven't been committed to the repository, yet. That's why, when you create a new repository, you should also create a .gitignore file with all the file patterns you want to ignore.

However, of course, not everything goes perfect... and files slip through that you later would like to see ignored.

Preparing the Cleanup

Before cleaning up your repository, you should conduct two important preparations:

1. Make sure your .gitignore file is up-to-date and contains all the correct patternsyou want to ignore.
2. Commit or stash any outstanding local changes you might have. Your working copy should be clean before you continue.

TIP

How to Ignore Files

Our free online book explains the general process of how to ignore files in great detail.

Cleaning Ignored Files

In three steps, you can clean up your repository and make sure your ignored items are indeed ignored:

$ git rm -r --cached .
$ git add .
$ git commit -m "Clean up ignored files"

GIT: Starting with an Unversioned Project

Let's start with an existing project that is not yet under version control. Change into the project's root folder on the command line and use the "git init" command to start versioning this project:

$ cd path/to/project/folder
$ git init

Now take a moment to look at the files in that directory (including any hidden files):

$ ls -la

You'll see that a new, hidden folder was added, named ".git". All that happened is that Git created an empty local repository for us. Please mind the word "empty": Git did notadd the current content of your working copy as something like an "initial version". The repository contains not a single version of your project, yet.

GLOSSARY

Working Copy

The root folder of your project is often called the "working copy" (or "working directory"). It's the directory on your local computer that contains your project's files.

You can always ask the version control system to populate your working copy with any version of your project. But you always only have one working copy with one specific version on your disk - not multiple in parallel.

Ignoring Files

Typically, in every project and on every platform, there are a couple of files that you don't want to be version controlled: on Mac OS, e.g., those pesky ".DS_Store" files aren't worth versioning. In other projects, you might have build or cache files that make no sense in a version control system. You'll have to decide yourself which files you don't want to include.

NOTE

Which Files Should I Ignore?

As a simple rule of thumb you'll most likely want to ignore files that were created automatically (as a "by-product"): temporary files, logs, cache files...

Other examples for excluded files range from compiled sources to files that contain passwords or personal configurations.

A helpful compilation of ignore rules for different projects and platforms can be found here: github.com/github/gitignore

The list of files to ignore is kept in a simple file called ".gitignore" in the root folder of your project. It's highly recommended to define this list at the very beginning of your project - before making your first commit. Because once files are committed, you'll have to jump through some hoops to get them out of version control, again.

Now, let's get going: Create an empty file in your favorite editor and save it as ".gitignore" in your project's root folder. If you're on a Mac, e.g., you'll want to make sure it contains at least the following line:

.DS_Store

If there are other files you want to ignore, simply add a line for each one. Defining these rules can get quite complex. Therefore, to keep things simple, I'll list the most useful patterns which you can easily adapt to your own needs:

• Ignore one specific file: Provide the full path to the file, seen from the root folder of your project.
  path/to/file.ext
• Ignore all files with a certain name (anywhere in the project): Just write down the file's name, without giving a path.
  filename.ext
• Ignore all files of a certain type (anywhere in the project):
  *.ext
• Ignore all files in a certain folder:
  path/to/folder/*

Making Your First Commit

With some ignore rules in place, it's time to make our initial commit for this project. We'll go into great detail about the whole process of committing a little later in this book. For now, simply execute the following commands:

$ git add -A
$ git commit -m "Initial commit"

GIT: Why do i have missing dlls issue when downloading the latest checked in project from github?

The .gitignore is set to ignore *.dll.

You need to use the following commands to forcefully track it:

git add -f *.dll

GIT: How to create a local git repository with existing code base?

$ cd /path/to/my/codebase

$ git init <1>

$ git add . <2>