Practice: Inspecting and Modifying History

This section provides practice for common scenarios involving project history inspection, correcting mistakes in staging or commits, and managing files within a Git repository.

Make sure you have a terminal or command prompt open and navigate to a Git repository you've been working on, perhaps the one from the previous chapter's practice session. If you don't have one handy, create a new directory, navigate into it, and run git init. Then, create a couple of files (e.g., README.md, script.py) add some initial content, and make one or two commits using git add . and git commit -m "Initial commit".

Inspecting Changes with git diff

First, let's see how git diff helps us understand changes.

1. Modify a File: Open one of the files in your repository (e.g., README.md) and add a new line of text or modify an existing one. Save the file.

2. Check Status: Run git status. Git will report that README.md has been modified but is not staged for commit.

   $ git status
   On branch main # Or master, depending on your default
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git restore <file>..." to discard changes in working directory)
           modified:   README.md
   
   no changes added to commit (use "git add" and/or "git commit -a")
   

3. View Unstaged Changes: Run git diff. This command, by default, shows the differences between your working directory and the staging area (index). You'll see the lines you added (prefixed with +) or removed/changed (prefixed with -).

   $ git diff
   diff --git a/README.md b/README.md
   index e69de29..b9ca75a 100644
   --- a/README.md
   +++ b/README.md
   @@ -0,0 +1 @@
   +This is the initial README content.
   +# Plus a new line I added. # This line will have a '+' prefix
   

   (The exact output will depend on your file content and changes)

4. Stage the Change: Add the modified file to the staging area:

   git add README.md
   

5. View Staged Changes: Now, run git diff again. Notice that it shows no output. This is because the changes in your working directory now match the staging area. To see what is staged (the difference between the staging area and the last commit), use the --staged (or --cached) flag:

   git diff --staged
   

   The output will look similar to step 3, showing the changes you just staged.

6. Commit the Change: Let's commit this staged change:

   git commit -m "Update README with additional info"
   

7. Compare Commits: You can also use git diff to compare two commits. Let's compare the latest commit (HEAD) with the one before it (HEAD~1):

   git diff HEAD~1 HEAD
   

   This will show the changes introduced specifically in the last commit you just made.

Fixing Mistakes: Unstaging and Amending

Mistakes happen. Maybe you staged the wrong file, or made a typo in your last commit message.

1. Accidental Stage: Modify another file (e.g., script.py) and also create a new temporary file you don't want to commit yet (e.g., temp.log). Now, accidentally stage both:

   # Modify script.py
   echo "print('Hello Git!')" > script.py
   # Create temp file
   echo "Temporary log data" > temp.log
   # Stage everything in the directory
   git add .
   

2. Check Staged Files: Run git status. You'll see both script.py and temp.log are staged.

3. Unstage the Temporary File: You only wanted to stage script.py. Use git reset HEAD <file> to remove temp.log from the staging area:

   git reset HEAD temp.log
   

4. Verify: Run git status again. script.py should still be staged, but temp.log should now appear as an "Untracked file".

   $ git status
   On branch main
   Changes to be committed:
     (use "git restore --staged <file>..." to unstage)
           modified:   script.py
   
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
           temp.log
   

5. Commit with a Typo: Commit the staged change, but make a typo in the message:

   git commit -m "Add greating to script" # Oops, typo: "greating"
   

6. Amend the Commit Message: You just made that commit. To fix the message without creating a new commit, use git commit --amend:

   git commit --amend -m "Add greeting to script"
   

   This opens your default text editor (unless you use -m again like here) to let you edit the message of the most recent commit. If you check git log -1, you'll see the corrected message, and the commit hash will likely have changed. Important: Avoid amending commits that you have already shared (pushed) to a remote repository, as it rewrites history.

7. Amend to Add Changes: Modify script.py again slightly. Stage the change (git add script.py). Now, realize this small change logically belongs with the previous commit ("Add greeting to script"). Instead of making a new commit, you can add this staged change to the last commit using --amend again, keeping the existing message:

   git commit --amend --no-edit
   

   The --no-edit flag prevents the editor from opening, keeping the previous message while incorporating the newly staged changes into that last commit. Check git log -p -1 to see the combined changes in the amended commit.

Undoing Commits Safely with git revert

Sometimes, you realize a commit made earlier introduced a bug or unwanted change. Instead of deleting it (which rewrites history and is problematic for shared repositories), you can revert it. Reverting creates a new commit that exactly undoes the changes introduced by a previous commit.

1. Identify Target Commit: Use git log --oneline to find the hash of the commit you want to undo. For example, let's revert the "Update README with additional info" commit made earlier. Copy its short commit hash.

2. Revert the Commit: Run git revert <commit-hash>:

   # Replace <commit-hash> with the actual hash from your log
   git revert <commit-hash>
   

3. Confirm Revert Commit: Your editor will open with a pre-filled commit message like "Revert 'Update README with additional info'". You can edit this message if desired, then save and close the editor.

4. Verify: Run git log --oneline again. You'll see a new commit at the top with the "Revert..." message. Check the content of README.md; the changes introduced in the reverted commit should now be gone. The original commit still exists in the history, but its effects have been counteracted by the new revert commit.

Managing Files with git rm and git mv

Git needs to track not just content changes, but also file removals and renames.

1. Track and Commit a File: Let's use that temp.log file. Stage it and commit it:

   git add temp.log
   git commit -m "Add temporary log file"
   

2. Remove the File: Decide you don't need temp.log anymore. To remove it from the project and tell Git to stop tracking it, use git rm:

   git rm temp.log
   

   Running ls (or dir on Windows) will show the file is gone from your working directory. git status will show that the deletion is staged.

3. Commit the Removal:

   git commit -m "Remove temporary log file"
   

4. Rename a File: Let's rename script.py to app.py. The Git way is git mv:

   git mv script.py app.py
   

   This command actually does two things: it renames the file on your filesystem (mv script.py app.py or ren script.py app.py) and stages this change (git add app.py and git rm script.py).

5. Verify and Commit Rename: Check git status. It should show renamed: script.py -> app.py. Commit the change:

   git commit -m "Rename script.py to app.py"
   

   Git is smart enough to track the history across the rename.

This practice session covered inspecting changes (git diff), unstaging (git reset HEAD), modifying the last commit (git commit --amend), safely undoing past commits (git revert), and properly removing (git rm) and renaming (git mv) tracked files. These are fundamental tools for keeping your project history clean and understandable.