Git Intro

Git Intro

Version control records incremental changes to code over time. Git operates on a distributed architecture where every developer holds a full copy of the repository history locally.

Distributed Version Control Architecture

flowchart LR
    subgraph Centralized ["Centralized VCS"]
        C1["Central Server"] <--> U1["Developer A"]
        C1 <--> U2["Developer B"]
    end

    subgraph Distributed ["Distributed VCS (Git)"]
        R1["Remote Repo"] <--> L1["Dev A Local Repo"]
        R1 <--> L2["Dev B Local Repo"]
    end

Core Concepts & Explanation

---

Git is a popular version control system.

It was created by Linus Torvalds in 2005, and has been maintained by Junio Hamano since then.

It is used for:

• Tracking code changes
• Tracking who made changes
• Coding collaboration

---

• Repository: A folder where Git tracks your project and its history.
• Clone: Make a copy of a remote repository on your computer.
• Stage: Tell Git which changes you want to save next.
• Commit: Save a snapshot of your staged changes.
• Branch: Work on different versions or features at the same time.
• Merge: Combine changes from different branches.
• Pull: Get the latest changes from a remote repository.
• Push: Send your changes to a remote repository.

---

• Initialize Git on a folder, making it a Repository
• Git now creates a hidden folder to keep track of changes in that folder
• When a file is changed, added or deleted, it is considered modified
• You select the modified files you want to Stage
• The Staged files are Committed , which prompts Git to store a permanent snapshot of the files
• Git allows you to see the full history of every commit.
• You can revert back to any previous commit.
• Git does not store a separate copy of every file in every commit, but keeps track of changes made in each commit!

---

---

• Over 70% of developers use Git!
• Developers can work together from anywhere in the world.
• Developers can see the full history of the project.
• Developers can revert to earlier versions of a project.

Note: Most Git actions (like staging, committing, and viewing history) happen on your own computer.

Only Push and Pull interact with remote servers like GitHub, GitLab, or Bitbucket to upload or download changes.

---

Practical Terminal Workflow

Execute the following terminal commands to work with this concept in your workspace:

# Check local Git version
git --version

# Display system configuration settings
git config --list --show-origin

Best Practices & Pro-Tips

• Atomic Commits: Keep each commit small, focused, and dedicated to a single logical feature or bug fix.
• Imperative Commit Messages: Write commit titles in imperative mood (e.g., Fix CORS bug rather than Fixed CORS bug).
• Review Diff Before Staging: Run git diff to review unstaged modifications before adding files to the index.

Common Gotchas & Troubleshooting

• Detached HEAD State: Triggered when checking out a specific commit hash directly rather than a branch. Create a new branch with git switch -c <branch-name> to preserve edits.
• Accidentally Staged Binary Files: Run git restore --staged <filename> to remove the file from the index without altering your local workspace copy.

Self-Check Challenge

Open your terminal in a test project directory, execute git status, and verify your current working tree state. Practice running git log --oneline to review commit history.