Working with the repository

We have to take a few minutes to look at the life cycle of a file inside Git.

A file will go through the following states, and the Git command line will take the file from one state to another. We will explain each state and its command line.

The important part of this schema is the triangle between the three states UNMODIFIED, MODIFIED, and STAGED. This triangle is an infinite loop. Indeed, every time you change a file, its state is set to modified, and then staged; when you commit the file, it returns to the unmodified state, and so on.

UNTRACKED is the first state where the file is created, but this isn't tracked by Git.

To change the state of a file, you have to add it.

Adding a file

When you start an empty repository and add a file, it will be in the untracked state, which means that it isn't in the Git repository.

To track a file, you have to execute this command line:

Erik@local:~/myProject$ touch MyFileName.txt
Erik@local:~/myProject$ echo "test" > MyFileName.txt
Erik@local:~/myProject$ git add MyFileName.txt

So, your file is now tracked by Git.

If you want to add all files because you already have something inside the directory while you create the repository, add a period (.) just after git add to specify to take all files inside the current directory:

Erik@local:~/myProject$ echo "hello" > MyFile2.txt
Erik@local:~/myProject$ echo "hello" > MyFile3.txt
Erik@local:~/myProject$ git add .

The file is currently staged and ready to be committed inside the repository.

Committing a file

As soon as your file is tracked, all changes will be notified by Git, and you have to commit the change on the repository.

Tip

Remember to commit your change as soon as possible (not for every line, but it's a marker to validate what you have done).

The commit command is local to your own repository, nobody except you can see it.

The commit command line offers various options. For example, you can commit a file, as shown in the following example:

Erik@local:~/myProject$ git commit -m 'This message explains the changes' MyFileName.txt

To commit everything, use the following command:

Erik@local:~/myProject$ git commit -m 'My commit message'

You will create a new commit object in the Git repository. This commit is referenced by an SHA-1 checksum and includes various data (content files, content directories, the commit history, the committer, and so on). You can show this information by executing the following command line:

Erik@local:~/myProject$ git log

It will display something similar to the following:

Commit f658e5f22afe12ce75cde1h671b58d6703ab83f5
Author: Eric Pidoux <[e-mail]>
Date: Mon Jun 2 22:54:04 2014 +0100
My commit message

The file is in the unmodified state because you just committed the change; you can push the files in the remote repository.

Pushing a file

Once committed, you can push the files in the remote repository. It can be on a bare repository, using init with the git init --bare command, so just type the following command:

Erik@local:~/myProject$ git push /home/erik/remote-repository.git

If you create a remote repository on another server, you have to configure your local Git repository.

If you use Git 2.0 or later, the previous command will print out something like this on the screen:

Warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
gitconfig --global push.default matching
To squelch this message and adopt the new behavior now, use:
gitconfig --global push.default simple

The 'matching' value from the push.default configuration variable denotes that git push will push all your local branches to the branches with the same name on the remote. This makes it easy to accidentally push a branch you didn't intend to.

The 'simple' value from the push.default configuration variable denotes that git push will push only the current branch to the branch that git pull will pull from; it also checks that their names match. This is a more intuitive behavior, which is why the default should be changed to this configuration value.

Firstly, check if a remote repository is defined:

Erik@local:~/myProject$ git remote

If it's not, define the remote repository named origin:

Erik@local:~/myProject$ git remote add origin http://github.com/myRepoAddress.git

Now, push the changes using the following command:

Erik@local:~/myProject$ git push -u origin master

After this, you will have a resume of what was pushed.

In fact, the remote repository will check the current Head (the reference to the commit) and compare it with its own. If there are differences between them, it will fail.

Removing a file

If you don't want a file anymore, there are two ways to remove it:

• Delete the file manually and commit the changes. This will delete the file locally and on the repository. Use the following command line

  Erik@local:~/myProject$ git commit -m 'delete this file'
  

• Delete the file only through Git:

  Erik@local:~/myProject$ git rm --cached MyFileName.txt
  

Checking the status

There is a way to display the working tree status, that is, the files that have changed and those that need to be pushed, and of course, there is a way to display the conflicts:

Erik@local:~/myProject$ git status

If everything is correct and up to date, you will get this result:

Erik@local:~/myProject$ git status
# On branch master
nothing to commit, working directory clean

If you add a file, Git will warn you to track it by using the git add command:

Erik@local:~/myProject$ touch text5.txt
Erik@local:~/myProject$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   text5.txt
nothing added to commit but untracked files present (use "git add" to track)

If you edit MyFile2.txt and type git status again, then you will have new lines:

Erik@local:~/myProject$ echo "I am changing this file" > MyFile2.txt
Erik@local:~/myProject$ git status
# On branch master
# Changes to be committed:
#   (use "gitreset HEAD<file>..." to unstage)
#
#   new file: text5.txt
# 
# Changes not staged for commit:
#   (use "git add <file>…" to update what will be committed)
#
# modified: MyFile2.txt
#

On these lines, separate paragraphs display all files in each state. The MyFile2.txt file is not tracked by Git and text5.txt is ready to be committed.

If you add text5.txt using the git add command, you will notice the following changes:

Erik@local:~/myProject$ git add MyFile2.txt
Erik@local:~/myProject$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   text5.txt
#   modified:   MyFile2.txt
#

Ignoring files

Git can easily ignore some files or folders from your working tree. For example, consider a website on which you are working, and there is an upload folder that you might not push on the repository to avoid having test images in your repository.

To do so, create a .gitignore file inside the root of your working tree:

Erik@local:~/myProject$ touch .gitignore

Then, add this line in the file; it will untrack the upload folder and its contents:

upload

Files or folders you define in this file will not be tracked by Git anymore.

You can add some easy regex, such as the following:

• If you want to ignore all PHP files, use the following regex:

  *.php
  

• If you want to ignore all files having p or l at the end of its name, use the following regex:

  *.[pl]
  

• If you want to ignore all temporary files (finishing by ~), use the following regex:

  *~
  

If the file is already pushed on the repository, the file is tracked by Git. To remove it, you will have to use the gitrmcommand line by typing this:

Erik@local:~/myProject$ git rm --cached MyFileName.txt