Git - Recording the Changes

Quiz

Recording changes to the repository means:

A complete copy of every file from the remote Git repository is downloaded to your local computer during a clone.
You have unrestricted access to edit and alter the files in this local copy.
You may control which modifications you wish to keep with Git.
Changes can be kept untracked (not included in commits) or tracked (included in subsequent snapshots or commits).
Any new or existing files that haven't been uploaded for tracking yet are referred to as untracked files. After cloning, all files are initially regarded as tracked and unaltered.

The Three States in Git

There are three main states, which a file can be in during its life cycle in Git:

Git keeps track of file modifications since the last commit (snapshot).

Modified: By staging the modified files, you can select which of them to include in the next snapshot.
Staged: By committing, every staged change is captured in a single picture.
Committed: As you work on your project, you will repeat this cycle of editing, staging, and committing.

Checking the Status of Your Files

The most convenient way to verify the condition of files in your Git repository is to use the git status command.

$ git status

After cloning, running git status gives you an accurate picture of the files and their present condition.

The output message is as follows:

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

This indicates a clean working directory, with no modified tracked files or untracked files.

It also identifies the current branch and confirms it hasn't diverged from the server's branch, typically master.

$ echo 'myGymProj' > README
$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 3 commits.
   (use "git push" to publish your local commits)

Untracked files:
   (use "git add ..." to include in what will be committed)
         README

nothing added to commit but untracked files present (use "git add" to track)

The git status command lists untracked files under the Untracked files section.

Git won't automatically track new files. You need to tell Git to start tracking them using the git add command. This ensures accidental files aren't included in commits.

Tracking New Files

To begin tracking a new file, use git add. It will then be recognized by Git for upcoming commits.

After adding a file, you can validate it's tracked and ready to commit by running git status.

$ git add README

Changes to be committed is displayed when executing git status, indicating files that are staged for the next commit.

Just as git add started tracking these staged files, committing records their current version.

$ git add about_us.html
$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 3 commits.
   (use "git push" to publish your local commits)

Changes to be committed:
   (use "git restore --staged ..." to unstage)
      new file:   about_us.html

You can add entire directories or specific files to staging using git add, including those added earlier with git init.

Staging Modified Files

A tracked file such as homePage.html will not immediately be staged when edited. They are listed with git status under Changes not staged for commit.

This means that the changes must be staged using git add before committing because they aren't captured for the next commit.

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 3 commits.
   (use "git push" to publish your local commits)

Changes to be committed:
   (use "git restore --staged ..." to unstage)
         new file:   about_us.html

Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git restore <pre>..." to discard changes in working directory)
         modified:   homePage.html

The Changes not staged for commit column lists the homePage.html file, suggesting that a tracked file has been edited but is not yet ready for commit.
The git add command is used to stage changes. The git add is a flexible tool that may be used to track new files, resolve merge conflicts, and stage files.
It is recommended to stage the Test.htm file using git add and then use git status to verify the status.

$ git add homePage.html

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 3 commits.
   (use "git push" to publish your local commits)

Changes to be committed:
   (use "git restore --staged ..." to unstage)
         new file:   about_us.html
         modified:   homePage.html

After staging, both files will be included in your upcoming commit.
Assume, at this point, that you have one last modification in mind to make to homePage.html before committing it.
Once you make that adjustment and open it once more, you're prepared to commit.

But first, let's execute git status again:

$ vim homePage.html

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 3 commits.
   (use "git push" to publish your local commits)

Changes to be committed:
   (use "git restore --staged ..." to unstage)
         new file:   about_us.html
         modified:   homePage.html

There is currently a staged and unstaged version of homePage.html. When you use git add, a file is staged by Git exactly as it is.
The version of homePage.html in your working directory at the time of your most recent git add command will be included in the commit if you commit now.
To stage the most recent version of the file, you must run git add again after making changes to homePage.html.

$ git add homePage.html

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 3 commits.
   (use "git push" to publish your local commits)

Changes to be committed:
   (use "git restore --staged ..." to unstage)
         new file:   about_us.html
         modified:   homePage.html

Short Status

The file status of your Git repository can be thoroughly viewed with git status.

Use the -s or --short flag to obtain a shorter version of the output from git status for a more readable perspective. This simplifies searching for specific changes.

$ git status -s

The output message is as follows:

A  about_us.html
M  homePage.html
?? .homePage.html.swp

The git status -s command provides a condensed view of your repository's status using codes:

?? - New untracked files
A - Newly added files
M - Modified files (and others)

The output is displayed in two columns:

Left - Staging area status (what's ready for commit)
Right - Working directory status (current state of your files)

Ignoring Files

In the root directory of your project, create a.gitignore file to exclude unwanted files from Git tracking.

List patterns in the .gitignore file to match and exclude them. This stops these unnecessary files from being accidentally committed.

$ cat .gitignore

Examples of such files include:

Logs
Temporary files (tmp directories)
Process ID (pid) directories
Automatically generated documentation

$ cat .gitignore

The output message is as follows:

# no .a files
*.a

# but do track lib.a, even though you're ignoring .a files above
!lib.a

# only ignore the root TODO file, not subdir/TODO
/TODO

# ignore all files in the build/ directory
build/

# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

# ignore all .txt files in the doc/ directory
doc/**/*.txt

Create a .gitignore file to prevent committing unnecessary files.

Ignore comments (lines with #) and blank lines.
Use glob patterns for matching files:

* matches any number of characters (e.g., *.log)
[] matches characters within brackets (e.g., [abc])
? matches a single character
[0-9] matches a range of characters (e.g., numbers 0-9)
** matches nested directories (e.g., a/**/z)

Start patterns with / to ignore only the specific file (not subdirectories).
End patterns with / to target directories (e.g., tmp/).
Prefix patterns with ! to negate the rule (e.g., include README.md).

Viewing the Staged and Unstaged Changes

The git status offers a concise overview of changes in your working directory.

It lists files that are modified, staged, or untracked.
Use git status to get a general idea of what's changed.
In contrast, git diff provides a detailed view of the actual edits.
It shows line-by-line additions and removals, like a patch of the modifications.
Use git diff when you need to see the exact edits made to your files.

$ git status

Type git diff without any parameters to inspect changes you've made but haven't staged yet.

$ git diff

The output message is as follows:

diff --git a/homePage.html b/homePage.html
index 994cc5a..9e40d3c 100644
--- a/homePage.html
+++ b/homePage.html
@@ -47,7 +47,7 @@
         }
         .navbar li{
               display: inline-block;
-            font-size: 20px;
+            font-size: 22px;

         }
         .navbar li a{
@@ -94,7 +94,7 @@
         </div>
         <!-- right for logo -->
         <div class="right">
-            <button class="btn">Call Us</button>
+            <button class="btn">Contact Us</button>
<button class="btn">Email Us</button>
</div>
</header>

By comparing the changes in your working directory with the staging area, the git diff command highlights alterations that haven't been staged yet.

Use git diff --staged to see changes that have been staged for the next commit by comparing them to the previous commit.

$ git diff --staged

The output message is as follows:

diff --git a/about_us.html b/about_us.html
new file mode 100644
index 0000000..e69de29
diff --git a/homePage.html b/homePage.html
index 3abf58d..994cc5a 100644
--- a/homePage.html
+++ b/homePage.html
@@ -99,7 +99,7 @@
   </div>
   <header>
   <div class="Container">
   -        <h2>Join the best gym of Delhi now</h2>
   +        <h2>Join the best gym of Pune now</h2>
   </div>
   <body>

The git diff only reveals unstaged modifications; it does not show all of the changes that have been made since your last commit.

If all of your changes have been staged, git diff will return nothing.

Once the homePage.html file has been staged and edited, you can use git diff to see both the staged and unstaged changes in the file.

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 3 commits.
   (use "git push" to publish your local commits)

Changes to be committed:
   (use "git restore --staged ..." to unstage)
         new file:   about_us.html
         modified:   homePage.html

Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
         modified:   homePage.html

Currently, you may view what is still unstaged by using git diff:

$ git diff

The output message is as follows:

diff --git a/homePage.html b/homePage.html
index 9e40d3c..dbf6cf4 100644
--- a/homePage.html
+++ b/homePage.html
@@ -80,7 +80,7 @@
         <div class="left">
         <img src="img/dumbbell.jpg" alt="">
-                <div>ABC Fitness</div>
+                <div>XYZ Fitness</div>
         </div>

You can use git diff --cached to view the changes you've staged so far.

It's worth noting that --staged and --cached are synonyms in this context.

$ git diff --cached

The output message is as follows:

diff --git a/about_us.html b/about_us.html
index e69de29..9a1eb8d 100644
--- a/about_us.html
+++ b/about_us.html
@@ -0,0 +1 @@
+<h1>Hello World</h1>
\ No newline at end of file
diff --git a/homePage.html b/homePage.html
index 9e40d3c..dbf6cf4 100644
--- a/homePage.html
+++ b/homePage.html
@@ -80,7 +80,7 @@
      <div class="left">
      <img src="img/dumbbell.jpg" alt="">
      -                <div>ABC Fitness</div>
      +                <div>XYZ Fitness</div>
      </div>

Committing the Changes

You can fine-tune precisely which modifications are part of a commit using the staging area.

Unstaged modifications won't be included, such as newly added or modified files that weren't added via git add.
Use git commit to commit all staged changes.
This is predicated on a prior git status verifying that everything is staged according to plan.

$ git commit

When you run git commit, the editor opens with the most recent git status output commented out.

You can either:

Delete these comments and write your own commit message.
Keep the comments as a reference for what's being committed.
When you save and exit the editor, Git creates the commit using your message (without the comments or diff).

You can skip the editor! You can write your commit message directly after the git commit command using the -m flag.

For example: git commit -m "Fixed Test.htm". This avoids opening the editor and lets you include your message inline.

$ git commit -m "changed the name"

The output message is as follows:

[gym-project 5c4824d] changed the name
2 files changed, 2 insertions(+), 1 deletion(-)

Skipping staging area

The staging area can increase complexity even though it is helpful for precise commits.

Git provides a shortcut, git commit -a, to avoid staging.
The git add is not necessary because this command automatically stages all tracked files before committing.
When you wish to commit all changes at once, it makes workflows simpler.

$ git commit -a -m "added h2 tag"

The output message is as follows:

[gym-project c2a4e75] added h2 tag
1 file changed, 2 insertions(+), 1 deletion(-)

By using git commit -a (or all), you can bypass the individual git add step and automatically stage all tracked files before committing.

But be careful it contains all recorded changes, which can include unintended ones. Consider using the staging area with git add for more exact control.

Removing the files

When you remove a file from your Git repository, it needs to be removed from two places:

Working directory: This is the file's local copy for you.
Staging area: Files that you have ready for the next commit are stored here.
You use the git rm command to accomplish this. By doing this, the file is deleted from both locations and made sure not to reappear as an untracked file in the future.

When you remove a file from your working directory directly without using git rm, it gets listed in the Changes not staged for commit portion of the git status output.

$ rm about_us.html

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 6 commits.
   (use "git push" to publish your local commits)

Changes not staged for commit:
   (use "git add/rm <file>..." to update what will be committed)
   (use "git restore <file>..." to discard changes in working directory)
         deleted:    about_us.html

no changes added to commit (use "git add" and/or "git commit -a")

Subsequently, executing git rm stages the removal of the file.

$ git rm about_us.html

The output message is as follows:

rm 'about_us.html'

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 6 commits.
   (use "git push" to publish your local commits)

Changes not staged for commit:
   (use "git add/rm <file>..." to update what will be committed)
   (use "git restore <file>..." to discard changes in working directory)
         deleted:    about_us.html

no changes added to commit (use "git add" and/or "git commit -a")

Removing a tracked file: After you commit, the file will be deleted from Git's tracking and your working directory.
Forcing removal: Use the -f option if the file is modified or already staged to forcefully remove it. This prevents accidental deletion of uncommitted changes.
Keeping the file untracked: Use the --cached option to remove the file from staging only.

This is useful if you mistakenly added a file or want to keep it in your working directory but exclude it from version control.

$ git rm --cached Test.htm

Files, directories, and file-glob patterns are all accepted arguments for the git rm command. With this flexibility, you can carry out tasks like:

$ git rm docs/\*.txt

In order to stop Git from expanding filenames, this command deletes any files in the docs/ directory that have the.txt extension.

Moving the files

Git's Methodology for Renaming Files: In contrast to several other version management systems, Git does not explicitly record the moves that occur while renaming files.

This implies that renaming a file creates a new file after it is first deleted.
However, Git uses advanced algorithms to recognize these renames later on, in an intelligent manner.

Git has the ability to rename files within its repository using the mv command, while without explicitly tracking file transfers.

$ git mv file_from file_to\

Git does, in fact, identify this as a renamed file when you run a command like this and check the status:

$ git mv homePage.html home_page.html

$ git status

The output message is as follows:

On branch gym-project
Your branch is ahead of 'origin/gym-project' by 6 commits.
   (use "git push" to publish your local commits)

Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
         deleted:    about_us.html
         renamed:    homePage.html -> home_page.html

Renames are intelligently detected by Git, regardless of the technique (manual or git mv). Although git mv provides a handy one-step fix, Git maintains its flexibility.

Before committing, you can handle the add/remove stages and rename using any tool.

Print Page