# Git Command Line Basics

All Git commands start with the `git` "main" command followed by a keyword matching the Git operation to be performed. Running Git commands only works inside folders that belong to a (local) Git repository.
Trying to run Git commands outside a Git repository folder will generate an error message.

[This index](https://git-scm.com/docs) lists all the available commands with links to extensive documentation.

## Displaying information about a local repository

The `git status` [command](https://git-scm.com/docs/git-status) displays information about the current status of the local repository:
  - What is the current branch ?
  - If it is related to a remote branch, have any modifications been made on either side ?
  - What has happend to the files and folders of the local repository ?

#### Important note
  1. By default Git ignores files with a predefined list of suffixes, considering they are generated by some complation process, and should not be included in a Git repository. These files will not show up in the output of `git status`.

On a freshly cloned repository, the output of `git status` looks like:

  ![status_initial.png](./media/status_initial.png)

The `git log` [command](https://git-scm.com/docs/git-log) details all the operations that have been performed on the current branch since it was created, crouped by commits. `git log` provides many many options to customize the output.

On the freshly cloned example repository, the output of `git log` looks like:

  ![log_initial.png](./media/log_initial.png)


## Making changes to a local repository

You can make any changes to a local repository (adding, removing, renaming files and folders, editing files). Git will take note of what has changed and you can always use `git status` to view the changes.

For example, after editing the contents of the `README.md` file, `git status` will display:

  ![status_after_changes.png](./media/status_after_changes.png)

Notice that Git mentions that the `README.md` and the `imaginary.md` files have been modified *but has not been staged for commit*. The same is true for the newly added `images/bigfoot.jpeg` file. This means that even if you try `git commit` right now, nothing will be commited.

### Notifying Git which changes have to be included in the next commit.

Git has to be explicitely made aware of what changes you want to include in the next commit. 

#### Notifying Git that files have been added or modified.

For files that have been modified or new files, this is done with the `git add` [command](https://git-scm.com/docs/git-add). When `git add` is followed by a file name, this file will be included in the next commit. When `git add` is followed by a folder or directory name, each file it contains will be included in the next commit.

After using Git add on the modified and new files of the repository, this is what the output of `git status` looks like.

  ![status_after_add.png](./media/status_after_add.png)

##### Important notes
  1. Using `git add` on an empty directory has no effects : Git does not manage empty directories.
  1. If you edit a file for which you already did `git add`, you will need to do the `git add` again.


### Deleting files tracked by Git

The `git rm` [command](https://git-scm.com/docs/git-rm) will have a double effect:
  1. It will remove a file (or a set of files) from the local copy of the repository
  2. It will notify Git that it should not track this (these) file(s) anymore.

When using `git rm` to remove a directory, only files known to Git will be removed.

#### Important note
If you remove one or more files with the Linux `rm` command. Git will require that you also use `git rm` to notify that you no longer want to keep track of the file(s). Better to use `git rm` in the first place.

### Renaming / Moving files tracked by Git

The `git mv` [command](https://git-scm.com/docs/git-mv) allows you to rename or move a file or a folder.

#### Important note.
If you rename one or more files with the Linux `mv` command. Git will be tricked and believe that first you deleted the old file and then that a new appeared instead. As above, better to use `git mv` in the first place.


### Undoing changes to files since the latest commit.

Sometimes, you will want to undo the changes you made to one or several files since your last commit. This can easily be achieved with the `git restore` [command](https://git-scm.com/docs/git-restore). You can also use `git restore` to recover files you accidentally deleted with the Linux `rm` command (or using your system's trash can).

## Committing changes to a local repository.

Once you checked with `git status` that all your modifications are accounted for, you can use the `git commit` [command](https://git-scm.com/docs/git-commit). This will store all the changes in the history track of the current branch of your local repository. An identifier will be associated to your commit, as well as an entry in the log file.

Running `git commit` without any additionnal option will run a text editor and require you to enter a message explaining your commit. This can be avoided by using the `-m` option followed by a message (between double quotes)

The following screenshot shows the result of a commit on our pet project after the addition of some new information:

![git_commit.png](./media/git_commit.png)

### Notes on the output of `git commit`
  - The first line of the commit show the branch the changes were commited to (`main`) in this case, the commit identifier (`8de79b0`) and the message you entered.
  - As this is the first commit, on a machine where we never used Git before, Git tries to guess how to set the author information (name and email address) for the commit. It also shows how to fix these if they are incorrect.
  - The last lines of the commit show a summary of what has been actually committed.


## Propagating local changes to the remote repository

To update a remote repository with all the commits that have been made locally, the `git push` [[command](https://git-scm.com/docs/git-restore)] is used. It needs no arguments or options, because it "knows" which part of the history is local and needs to be propagated to the remote repository.

To know what will be propagated, you can use `git status` as in the following example:

![status_before_push.png](./media/status_before_push.png)

It shows that the local repository is one commit *ahead* of the remote repository. Meaning, that one local commit (the latest) will be propagated to the remote repository.

The actual output of `git push` looks like:

![git_push.png](./media/git_push.png)

Notice the last line, with two commit ids (the one of the latest commit when cloning the repository, and the latest local commit id), and the names of the branches involved in the commit.

On GitLab, the project welcome page displays information about the latest commit that has been pushed to the repository.

![gitlab_after_push.png](./media/gitlab_after_push.png)