Create a Folder named “gitprojects”. Use the command mkdir.

Enter into that newly created folder “gitprojects”. Use the command cd <folder name>.

Check if is there anything (File / Folder) in that newly created folder “gitprojects” or not. Use the command ls. There won’t be anything.

In the project “gitprojects” we want to work on the first project. So, create a folder named “project1”.

Enter into that newly created folder in the “gitprojects” i.e “project1”.

Check / Confirm the location of the folder. Use the command pwd. So, on the Desktop we created one folder named “gitprojects” and in that folder, we created one more folder named “project1”. And currently, we are in the folder “project1”.

Now, the folder “project1” will be our workspace. So, we prepared our workspace.

Version Control will not be available for our workspace “project1” now.

Note: By default, Version Control is not available for the Workspace / Working Directory.

We can check it by using the command ls, nothing will be there, then we can use ls -a and there also we will not get anything.

There will be one dot (.) and two dots (..) in that folder representing every directory containing two hidden directories, one is the current working directory (.) and the other is the parent directory (..).

Now, GIT is not aware of our Workspace. So, we have to tell it that the folder “project1” is our Workspace. And let the GIT know that we want Version Control for the “project1”.

Q. For the Workspace “project1” is the Version Control applicable?

Ans: No, also if the Version Control is not applicable then we can’t use any GIT command. To get the Version Control for the Workspace there should be a Local Repository in the Workspace, and the GIT is responsible to provide the Local Repository. For that, we can use the command git init.

So, for that, we have to initialize the Repository. This means we want the Repository to maintain different Versions. Then Git will provide an empty Repository.

To initialize the Workspace (Create an empty Repository) so that the Version Control is available to our Working Directory, or re-initializing an existing one (Local Repository) we’ll use the command git init.

We have to execute the command git init in the Working Directory.

Note: The name of the local Repository will be .git. As the name starts with a dot (.) therefore it’s a hidden directory, internally this directory is used for the Version Control purpose.

Now, we’ll check the status of the GIT in the workspace “project1” using the command git status.

git status shows the current status of all the files in each area, Ex:

• Untracked files

• modified files

• staged files etc.

So, it's “fatal” (Dangerous) i.e it’s a severe error. It’s not a git repository then why are we using this command?

If we don’t know about any command in GIT then we can use the command git only, and a list of all the commands in GIT will be printed on the screen.

Now, we want the Version Control for the workspace “project1”. So, we’ll use the command git init.

Now, it says it initialized an empty GIT repository inside the workspace .git directory.

Now, to confirm it we’ll use the command ls -a as .git is a hidden folder.

Now, use the command git status to check the status of the GIT in the workspace.

Till now, nothing is available in the GIT.

Create one more workspace in the directory “gitprojects” named “project2”.

Create two files inside the folder “project2”. We can use the command touch or cat. And write something in that file.

Now, the workspace “project2” is not empty, it has two files in it.

Now, we’ll use the command git init to initialize the GIT in the Workspace and create an empty Local Repository in our Workspace (project2).

Now, we have to manually/explicitly add the files in the Local Repository. As there is nothing in the Local Repository (It is empty) So, nothing is being tracked by the GIT. We can check it by using the command git ls-files.

Scenario 1:

As we have already created a Workspace (project2), and the Local Repository is already there.

Now, the Local Repository already contains 2 files i.e. one Commit is there and that commit itself contains 2 files “a.txt” & “b.txt”.

Now, if we’ll use the command git init then it’ll reinitialize the empty Local Repository (directory) means, it’ll become Empty again.

So, we’ll Check / Confirm that.

If we’ll check the status of the GIT in the working space “project2” using the command git status then two untracked files will be present in the Workspace (project2).

Now, we’ll add the files to the Staging Area. So, for that, we can use the command git add . (We use dot (.) so that the whole files in the workspace will be added). Or we can use git add *txt then all the txt files will be added to the Staging area. Or we can just write the file names also.

Now, again change the status of the GIT in that Workspace (project2). It says we are on the Master Branch, but no Commit is made yet, we have to Commit the 2 Files.

Also, it starts tracking the files. So, GIT starts tracking the files when we add them to the Staging Area.

So, now, we’ll Commit both files to our Local Repository. For that, we’ll use the command git commit -m “<message>”.

Now, if we are doing these operations for the first time then we have to configure GIT. Otherwise while Committing, it’ll ask for the details of the user as it’ll not be able to detect the email id of the user.

So, to configure we’ll use the following commands:

git config --global user.email "you@example.com"

git config --global user.name "Your Name"

In our case it’ll be

git config --global user.email "aviaadiikishorr@gmail.com"

git config --global user.name "abhishekkishor"

Now, once we Configure it, we are good to go.

git config: It is the command used for the GIT Configurations.

git config --list: To check which are all the configurations configured in GIT.

git config user.name: Display the username.

git config user.email: Display the user’s email id.

Without Global vs With Global

For all the Repositories which are managed by the GIT currently; if we want to use the same username and mail id then we require to use Global. It means, for all the repositories (Git & Github) these configurations are applicable.

Without Global means, the Configurations apply only to the Current Repository. So, if we are using the GIT configurations Without Global for a project, then if we start working on another project, then the GIT will ask for the user’s details again for that project.

So, if we are working on multiple Remote Repositories then it’s recommended to configure GIT Without Global.

Considering we are working on three projects, 2 Projects are personal repositories and another one is in the office's repository.

Now, if we Commit again then the files will be Committed to the Local Repository.

Now if we check the status of the GIT again using the command git status then, it’ll tell us nothing is there to Commit.

After that if we check the log of the GIT in the workspace using the command git log then we’ll get the following things:

• Commit Id - It is a 40-digit alphanumeric Hash value representing the Committed file content.

• Author name along with the email id,

• Timestamp i.e At what Date and time the files had been Committed?

• Commit the Message that we had written/given while committing.

git log: It shows the history of all the Commits.

• HEAD -> master: HEAD is a reference which is pointing to the master.

• HEAD: It is the most recent Commit. We can change HEAD to the other Commit also.

• master: It is the name of the Branch. As well as at the same time it is a reference to the Recent Commit / Version.

And then the Master is pointed by another Reference called HEAD. So, HEAD is a reference to the other reference. And this reference is known as the Symbolic Reference(Reference to another reference).

We’ll check the files in our Workspace also. For that, we can use the command ls. We’ll see there are two files present in our Workspace “a.txt” and “b.txt”.

Now, if we’ll check the list of the tracked files then we can use the command git ls-files. So, we’ll see GIT will be tracking both the files “a.txt” and “b.txt”.

And there is already one commit in our Local Repository. We can use the command git log

Now, if we use the command git init to re-initialize the workspace again. It’ll tell that it reinitialized the Git Local Repository again.

Now, again if we’ll check our Workspace then again two files will be present in it.

GIT will be Tracking the same two files as before.

Only one Commit Id will be there, the same as before.

Q. Then what is the meaning of Reinitialized?

Ans: It means everything is available, maybe internally the space gets refreshed. Means Reinitializing GIT again makes no difference. So, by mistake, if we use the command git init after Initialization and Commit by mistake then also nothing will happen.