update md file

.gitignore

@@ -0,0 +1,3 @@
+this file wont visibile in git
+secret.txt
+.env

ASSIGNMENT-04-09-2025.md

@@ -0,0 +1,16 @@
+## Q1: Did Git perform a fast-forward merge or a 3-way merge?
+
+Git performed a **3-way merge**.
+
+### Explanation:
+- A **fast-forward merge** happens when the branch pointer can just be moved forward because no new commits exist on the target branch since the branching point.
+- A **3-way merge** happens when both branches have new commits, and Git needs to create a merge commit by combining changes from both sides.
+
+In my case, both `feature/bugReport` and `feature/mergeFile` had new commits, so Git created a merge commit.  
+Thus, it was a **3-way merge**.
+
+---
+
+## Q2: What does `git log --graph --oneline --all` show after the merge?
+
+![git log --graph --oneline --all](git_log_--graph_--oneline_--all.png)

GIT_ASSIGNMENT.md

@@ -1,7 +1,208 @@
-## Create Repository in Organization
+# 🚀 Git Assignment – My Version Control Journey
 
-- Visited the Git-Training-Hub organization on Git Comorin.
+---
-- Created a new repository named git-practice-Ajin with no README, .gitignore, or license.
-- The repository is empty as required.
 
-![Repository Screenshot](GIT_ASSIGNMENT.png)
+## 🛠 Step 1: Verifying Git Installation
+
+📌 _First step was making sure Git was installed and working fine._
+
+![Git version check](git_version.png)
+
+✅ The output displayed the installed Git version.
+
+---
+
+## 📂 Step 2: Checking Repository Status
+
+👀 _Next, I checked the repo to see if there were pending changes._
+
+![Git status](git_status.png)
+
+🔎 Git shows tracked, untracked, and staged files.
+
+---
+
+## ➕ Step 3: Moving Files to Staging
+
+✨ _I noticed some modifications and added them with_ `git add`.
+
+![Git add](git_add.png)
+
+🗂 Files are now ready to be saved in the next commit.
+
+---
+
+## 📝 Step 4: Reviewing Commit History
+
+📖 _Every commit is part of the project’s story, so I reviewed mine._
+
+![Git log](git_log.png)
+
+🕒 Shows commit messages, author names, and dates.
+
+---
+
+## 🔹 Step 5: Simplified Commit Log
+
+👾 _To avoid too much detail, I used_ `git log --oneline`.
+
+![Git log oneline](git_log_--oneline.png)
+
+⚡ A compact and easy-to-read commit history.
+
+---
+
+## 🌳 Step 6: Visualizing History with Graph
+
+🎨 _History is better when visualized, so I used graph mode._
+
+![Git log graph](git_log_--oneline_--graph.png)
+
+🌿 Displays branches and merges clearly.
+
+---
+
+## 🔍 Step 7: Checking File Changes
+
+🖋 _Before committing, I inspected changes with_ `git diff`.
+
+![Git diff](git_diff.png)
+
+🔑 Shows exact line changes inside files.
+
+---
+
+## 🆚 Step 8: Comparing Two Versions
+
+⚔️ _To see what changed between two commits, I compared them._
+
+![Git diff between two commits](git_diff_commit_commit.png)
+
+📌 Helps track project progress over time.
+
+---
+
+## 🌿 Step 9: Working with Branches
+
+🔀 _I explored branches to work independently without touching main code._
+
+![Git branch](git_branch.png)
+
+🌱 Branches allow experimentation safely.
+
+---
+
+## 📥 Step 10: Cloning a Repository
+
+🛰 _I downloaded a project from remote using_ `git clone`.
+
+![Git clone](git_clone.png)
+
+📂 A full copy is now available locally.
+
+---
+
+## 📥 Step 11: Pulling Remote Updates
+
+🛰 _To stay up to date, I fetched and merged with_ `git pull origin`.
+
+![Git pull](git_pull.png)
+
+---
+
+## 🌐 Step 12: Checking Remote Connections
+
+🔗 _I verified linked remote repositories with_ `git remote -v`.
+
+![Git remote](git_remote.png)
+
+---
+
+## 🚫 Step 13: Using .gitignore
+
+📄 _Added a `.gitignore` file to skip tracking unnecessary stuff._
+
+![Git ignore](gitignore_file.png)
+
+---
+## 🔀 Step 14: Performing a Merge
+
+⚡ _I merged changes from another branch into my current branch._
+
+![git log --merge](git_log_--_merge.txt.png)
+
+📌 Since both branches had commits, Git created a **3-way merge commit** (not a fast-forward merge).
+
+---
+## 📜 Step 15: Inspecting Merge Commit Details
+
+👀 _I used `git log -p -- merge.txt` to review the merge commit changes._
+
+![git log -p -- merge.txt](git_log_-p_--_merge.txt.png)
+
+📝 Shows added and modified lines from both branches.
+
+---
+## 🗂 Step 16: Checking Simplified Log After Merge
+
+⚡ _To quickly see the commit history after the merge, I ran:_
+
+![git log --oneline -- merge.txt](git_log_--oneline_--_merge.txt.png)
+
+---
+## 🌳 Step 17: Visualizing All Branches and Merge
+
+🎨 Using the graph mode to visualize history clearly:
+
+![git log --graph --oneline --all](git_log_--graph_--oneline_--all.png)
+
+🌿 Shows both branches and the merge commit.
+
+---
+## Step 18: Blame – Tracking Line History
+
+🖊 With git blame, I checked who wrote each line in merge.txt.
+
+![git blame merge.txt](git_blame_merge.txt.png)
+
+🔑 Each line is attributed to its commit.
+
+---
+## 🎯 Step 19: Blame with Line Range
+
+🎯 To narrow focus, I ran blame only for lines 1–5.
+
+![git blame -L 1,5 merge.txt](git_blame_-L_1,5_merge.txt.png)
+
+---
+
+## 📧 Step 20: Blame with Email
+
+📧 Finally, I checked the author emails using git blame -e.
+
+![git blame -e merge.txt](git_blame_-e_merge.txt.png)
+
+---
+## 🔀 Step 21: Merging Branch `feature/mergeFile` into Main
+
+⚡ _I merged the branch `feature/bugReport` into `feature/mergeFile` using the command:_
+
+![git merge feature/mergeFile](git_merge.png)
+
+---
+# ✨ Summary
+
+1. ✅ **Git Version Check** – Verified installation.  
+2. ✅ **Git Status** – Checked repository state.  
+3. ✅ **Git Add** – Staged changes.  
+4. ✅ **Git Log** – Viewed history.  
+5. ✅ **Git Log (oneline/graph)** – Short + visual log.  
+6. ✅ **Git Diff** – Compared file changes.  
+7. ✅ **Git Branch** – Created/checked branches.  
+8. ✅ **Git Clone** – Cloned repo locally.  
+9. ✅ **Git Pull** – Pulled updates.  
+10. ✅ **Git Remote** – Checked remotes.  
+11. ✅ **Git Ignore** – Excluded files.  
+12. ✅ **Git Merge** – Performed and confirmed a 3-way merge.
+13. ✅ **Git Blame** – Tracked who wrote each line (with -L and -e options).
+---

index.html

@@ -1,17 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-
-<head>
-    <meta charset="UTF-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1.0">
-    <title>Document</title>
-</head>
-
-<body>
-    <h1>Hello World</h1>
-    <p>This is a sample HTML document.</p>
-    <p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Libero magni porro totam consequatur architecto ipsum
-        id, voluptate ullam ex facilis fugit quae consequuntur animi, quis deserunt laboriosam! Harum, vero ut.</p>
-</body> 
-
-</html>

merge.txt

@@ -0,0 +1,7 @@
+# created new merge file
+# added a second line for this file
+# added a third line for this file
+# added a fourth line for this file
+# added a fifth line for this file
+# added a sixth line for this file
+# changed to new mergeFile branch

new_branch.txt

@@ -0,0 +1,2 @@
+create new branch and checkout to the new branch 
+edit text 

readme.md

@@ -0,0 +1,35 @@
+1️⃣ Reproduce the situation
+
+- Initially, my repo had a file called readme.md.
+- I renamed it to README.md (only case change).
+- After running:
+
+    `git status`
+
+    Git showed no changes, meaning it did not detect the rename.
+
+📸 ![Git readme](git_readme.png) – Git did not show any changes after renaming readme.md → README.md
+
+2️⃣ Investigate why Git is not tracking the rename
+
+- Git depends on the filesystem to detect changes.
+- On Windows (NTFS, FAT), the filesystem is case-insensitive.
+- That means readme.md and README.md are treated as the same file.
+- Because Windows reports no difference, Git assumes nothing happened.
+
+3️⃣ Correct steps to make Git recognize and commit the rename
+
+To force Git to recognize the case-only rename:
+
+`git mv -f readme.md README.md`
+`git commit -m "Rename readme.md to README.md"`
+
+4️⃣ Underlying reason
+
+- Git itself is case-sensitive → it can distinguish between readme.md and README.md.
+- Windows filesystems are case-insensitive → both names point to the same file.
+- On Linux/macOS (case-sensitive), Git would automatically detect the rename.
+- On Windows, we must explicitly force it with git mv -f.
+
+✅ Conclusion:
+It’s due to the way Git (case-sensitive) interacts with Windows (case-insensitive) filesystems.