README.md



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 lists all the available commands with links to extensive documentation.

Displaying information about a local repository
The git status command 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

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:

The git log command 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:


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:

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. 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.


Important notes

Using git add on an empty directory has no effects : Git does not manage empty directories.
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 will have a double effect:

It will remove a file (or a set of files) from the local copy of the repository
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 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. 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. 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:


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] 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:

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:

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.


Keeping a local repository synchronized with a remote repository
A same remote repository can be cloned several times: by different people on each of their machines, by a single user on different machines, by a single user in different directories on the same machine.
When someone pushes modifications from a clone (local repository) to the original remote repository, these modifications do not get pushed to every existing clone. It is the duty of the owner of each local repository to ensure that the local copy does not get too far behind the remote repository.

Fetching information about the remote repository
The git fetch command] retrieves information about all modifications made to the current branch of the remote repository, since the local repository was last synchronized. It does not modify the local repository.".