Hope you have gone through my previous article Getting Started With GIT - Part 1; If not then you can go through it (Mastering Git : Getting Started with Git (Part 1) (hashnode.dev) This is the Second Part (Continuation) of part 1.

Scenario 2

If we change/add something in both the files in the Working Directory.

Go to the Workspace (project2) and modify both files by adding another line.

Now, check the status of GIT in the Workspace (project2) using the command git status. Now, both files will be modified.

Now, if we have to commit that changes, then we have to again add those changes to the Staging Area using the command git add. Then we have to commit those changes i.e sending the files from the Staging Area to the Local Repository.

So, it’s a two-line process. But we can do it by using a single-line command git commit -am "commit message".

-a: Will add changes to the staging area. Then Commit to the message.

Note: This command is used when the file is being tracked by the GIT. This command does not apply to the newly created files.

If we will check the log of the GIT, then there will be two commits along with the two Commit IDs and other details, for example, time.

Scenario 3

Go to the directory “gitprojects” and create a Workspace named “project3”.

Now, we’ll check the status of the GIT in the workspace “project1” using the command git status. We’ll get the response from the GIT that the Version Control is not applicable in the Workspace. Therefore we can’t use any GIT command. We have to initialize GIT once we create a Workspace and if we want Version Control then we require a repository.

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

Now, if we’ll check the status of the GIT then it’ll tell us no commits have been made yet and there is nothing to commit. So, to check the status of GIT we can use the command git status.

Now, create two files “a.txt” and “b.txt”. And write something in those files. For that, we can use the command cat.

Now, we created two files in our Workspace. Those two files aren’t tracked by GIT now. GIT will start tracking the files once it’ll get into or will be added to the Staging Area. But, we didn’t put the files into the Staging Area till now, so GIT won’t track them.

To check it, we can use the command git status. It’ll tell you those files are not being tracked.

If we want to see the concise version of the status, not the verbose/detailed output then, we can use the command git status -s. It’ll show the verbose/detailed output of the status.

??: Question Marks refer to the untracked files.

Now, add the file “a.txt” to the Staging Area. And the other file “b.txt” is still in the current Workspace.

Once we added the file to the Staging Area, then the GIT will start tracking the file and ready for the Commit.

Note: Staging Area is also known as Index Area or Cache Area.

It is a Logical / Virtual Area but not a physical Area.

Now, we’ll check the Status of the GIT again. It’ll tell that one file has been added but still, one other file is untracked.

Now, check the concise output of the status, we’ll use the command git status -s

A: Letter A refers that the file has been added to the staging area.

Add the other file “b.txt” also to the Staging Area. For that, we’ll use the command git add .

Now, we’ll check which files are there in the Staging Area that is which files are being tracked by GIT, so for that we can use the command git ls-files.

Now, if we check the status of the GIT, then we’ll see both the files are being tracked, that is they are in the Staging Area and ready to be committed. So, we’ll use the command git status

We can also check the Concise output of the status. So, we’ll use the command git status -s

We’ll see the Letter “A” before both files, so that means both files have been added to the Staging Area.

Now, we have to perform the Commit operation. So, if we want to Commit Staged Changes (Whatever files are added in the Staging Area); We’ll use the command git commit. And to commit, messages should be compulsory. So, for that, we’ll use -m along with the command git commit and after that message should be there. So, we’ll use the command git commit -m "message".

• “New files added”: Commit message.

• 644: Permissions

  • 6: rw- (Read and Write) (Owner’s Permission)

  • 4: r-- (Read) (Group Permissions)

  • 4: r-- (Read) (Other Permissions)

• To cross-check the permissions we can use the command ls -l.

• 8d0909c: First 7 characters of the Git Id. (Check with the command git log).

Now, check the log of the GIT. For that, we’ll use the command git log.

The advantage of the Commit Id that is in the Hash form are:

1. Security: If the Repository got hacked, then there will be no problem as the data will in the Hash Format. Only GIT can understand that data (Commit Id).

2. Less Space: Even if we are having huge data, then also it’ll store using the 40 Hexadecimal characters only. So, it’ll take very less space as compared to other Version Control System Tools.

There will be 40 characters of Hexadecimal Commit Id, Author, Timestamp and Commit Message.

Now, modify the files that are present in the Workspace. So, again if we want to add/modify anything in the files we’ll use the command cat.

Now, check the status of the GIT. It’ll be objecting the file “a.txt” not the file “b.txt” as we have modified the file “a.txt” not the file “b.txt” and, as the content of the files in both the Workspace and the Local Repository should be the same but here it’s not (we have modified the file a.txt).

Now, add the Modified file to the staging area, we’ll use the command git add <filename>.

But as the file “a.txt” has already been added to the Staging Area then we can directly Commit the file into the Local Repository. We don’t need to do it separately as it’s a two-line process. But we can do it by using a single line command git commit -a -m “commit message”.

It’ll tell, one file has been changed and the change is one line insertion.

Now, check the log of the GIT. For that, we’ll use the command git log.

This time there will be two commits present in the Local Repository.

In this log, the master represents the most recent Commit which is the 2nd one.

Commit Id: 6b43326ee85e4d249eaf375b836f28ae2b6ade1e

Scenario 4

Change the user’s details:

Change the Username of the User (Without Global). For that, we can use the command git config user.name "<Changed username>"

Change the email Id of the User (Without Global). For that we can use the command git config user.email "<Changed email>".

Confirm the username and user email Id. For that, we can use the command:

git config user.name

git config user.email

Create a file “c.txt” in the Workspace and add something to that file.

Now, add that file to the Staging Area. We can use the command git add <filename>

After that commit that file along with a Commit Message. We can use the command git commit -m "Commit message"

Now, check the log of the GIT. You’ll see for the 3rd Commit the username and the user’s email is different (It is the same as what we had changed previously).

But it got changed for this particular Local Repository (Local Repo of the workspace “project3”) only, as we haven’t configured it Globally.

To confirm that we can use the command git config --list. We’ll see the Username and the Email Id that we have configured just now and the Username and the Email Id that we had configured initially both will be present.

This happens because we are still in the Workspace where we were working and reconfigured all the details of the user.

Now, just go back to the previous folder (Using the command cd ..) or any folder and then in the terminal re-type the same command git config --list again. We’ll see the details (Username & Email Id) that we had configured initially as we had configured that Globally.