Types of files status in GIT and viewing status of files and difference in them.

Files in a local GIT repository can be in 4 status :
a. Untracked : These files are newly added into the repository.
b. Unmodified : These files exist in repository and local and both have same content.
c. Modified : These files exist in repository and local but some changes are made to the local copy of the file.
d. Staged : These files exist in repository and local but some changes are made to the local copy of the files and the files has been added to the staging area using git add <file_name> command. These file will go with the next commit made to the repository

Status of GIT files can be viewed using below commands

git status
git status -s
#to see the time taken to check status
time git status

So there are different stages files in GIT for example below

Command : git status -s
  1. File f1.txt is modified but not yet staged hence M in the right column with read color
  2. File f2.txt is modified and added to the staging area hence M in the left column with green color
  3. File f3.txt was modified and added to the staging area but after that again there was modification done to f3.txt this time it was not added into staging are. If we commit f3.txt now GIT will only commit that version of file which was added to the staging area, the modified version of f3.txt will not be committed
  4. File f5.txt was a completely new file, it was created and added to the staging are hence A in the left column with GREEN color signifying it a newly added file
  5. File f4.txt displays ?? in the left and the right column which signifies it is an untracked file which is not present in the repository nor added into git staging area.

Now the same set of status can be viewed as a complete version with command git status, below is the screenshot of how it looks.

Command : git status

Configuration files in GIT

GIT configuration can be stored at three locations local, global and system. GIT config tool handles all these configuration by setting and getting its values.

git config

It is tool used by GIT to set and get configuration variables, these configuration controls all aspects of how GIT looks and operates

GIT Local
These configurations are stored in the .git folder in the same location where the repository is created

.git\config                  //on Windows

.git/config                  //on Linux

GIT Global
These configuration resides in the home directory(C:\Users\<UserName>\) i.e %USERPROFILE% and the configuration is stored in the file .gitconfig

%USERPROFILE%\.gitconfig                       //on Windows
~/.gitconfig or ~/.config/git/config           //on linux

GIT System
These configuration resides at location C:\ProgramData\Git\config

C:\ProgramData\Git\config        //on Windows
/etc/gitconfig                   //on Linux

You can view all your settings and see where they are coming from using the below command

git config --list --show-origin

Precedence of configuration file from lowest of highest
1. System configuration (Lowest priority)
2. Global configuration
3. Local configuration (Highest priority)

If you want to see value of one of the settings then you can run the below command

git config user.name

Creating a repository and committing files.

Repository can be created in two ways :
1. Take a local directory which is not under version control and convert it into GIT directory which is under version control
2. Take a online repository which already has files in it and clone it to your system.

  1. Making you own new repository (command : git init) and adding files to it (command : git add <fileName>)
git init
git add file1
git add -A //all file shorthand
git add --all
git commit -m "Fist Commit"

2. Cloning files from an online repository

git clone https://github.com/libgit2/libgit2

We recommend you to use -o attribute with the git clone command so that we can rename the default short name that is orgin with some other value so that we can identify it more clearly.

git clone <url> -o <new short name>

Committing files directly in GIT (Skipping the staging area)

As we saw in the above example we can commit files into git using command git -m “Commit”, but only if the files are added to the staging area. If you want to directly commit a file without adding it into the staging area you can also do that but this type of commit commits all the files that are modified directly, it is a bit risky to add all the files hence you need to be sure before doing such type of commits.

git commit -a -m "Committing files directly into GIT, skipping the staging area"

Download and setting up git profile

  1. Download Git from following website (https://git-scm.com/)
  2. Install the GIt software with default Settings except, select “Use Git from Git Bash only”
  3. Then install GIT all by default options.

Setting up GIT
GIT requires setting up profile name and email
Open up GIT bash and fire below commands to setup git

git config --global user.name "Tyson Gill"
git config --global user.email "gill.tyson332@gmail.com"
git config --global core.editor nano
Note : Instead of user name "Tyson Gill" enter you own name and instead of email id enter your own email id.

To increase the performance of your GIT bash you can execute below commands

git config --global core.preloadindex true
git config --global core.fscache true
git config --global gc.auto 256
set GIT_TRACE=true
#below command should be handled with caution
export PS1='$'

To verify the all the sets run the below command

git config --list

If you need any help with any git command you can fireup the “help” attribute of any command in git using -h or –help attribute, sample below

$ git add -h
usage: git add [<options>] [--] <pathspec>...

    -n, --dry-run         dry run
    -v, --verbose         be verbose

    -i, --interactive     interactive picking
    -p, --patch           select hunks interactively
    -e, --edit            edit current diff and apply
    -f, --force           allow adding otherwise ignored files
    -u, --update          update tracked files
    --renormalize         renormalize EOL of tracked files (implies -u)
    -N, --intent-to-add   record only the fact that the path will be added later
    -A, --all             add changes from all tracked and untracked files
    --ignore-removal      ignore paths removed in the working tree (same as --no-all)
    --refresh             don't add, only refresh the index
    --ignore-errors       just skip files which cannot be added because of errors
    --ignore-missing      check if - even missing - files are ignored in dry run
    --chmod (+|-)x        override the executable bit of the listed files

What is GIT?

GIT is a version control tool just like CVS, Preforce etc but it works totally in a different way, if you need to undestand GIT you have to understand it like a totally new concept, trying to map concept of this tool with any another similar tool will not help you any faster.

GIT stores the changes like a stream of snapshots. Note these snap shots will only contain the changes that you have made with the previous version and not the complete file it self. If there is no change then it does not create a file or store the snapshot of it, GIT just links the file to it previous version.

Advantages of GIT :
1. All the GIT operation is possible in local : In traditional version control you have to compare the file history then you have to hit the repository and compare it but in case of GIT it all happens locally, this prevents the GIT from network dependency latency and give it a overhead of fast comparison.
2. GIT has integrity : Everything in GIT is stored in form of checksum, so you cannot escape from GIT after making any changes, even after you pull the data from repository GIT does compare the checksum(SHA-1 algorithm) to see if there were no damage done while transferring the file over the internet.
3. GIT Generally only Adds data : All the changes you make in GIT are store in GIT in the form of additional data, and you can go back to any point of time you committed the data since GIT maintains all of it, and hence you can code without the fear if loosing the previous code.

Three stages of GIT :
1. Committed : The file changes are successfully committed to the repository.
2. Modified : The file has been changes but not committed to the repository.
3. Staged : The file has been changes and it is marked as stages i.e the changes will go in the next commit made to the repository

Note : Staging is a new middle layer where you mark the files that there are the files that has been modified and need to committed.