Git & GitHub Fundamentals

📘 Module 1: What is Git?

What We Learn:

Why Version Control? Imagine writing an essay and wanting to save different versions (e.g., "essay_final_v1.docx", "essay_final_v2_really_final.docx"). Git automates this, tracking every change you make to your code. It's like a time machine for your project! This is essential for:
- Tracking all changes over time.
- Collaborating with others without overwriting work.
- Reverting to older versions if something breaks.
- Experimenting with new ideas safely.
Git vs GitHub: The Engine vs. The Platform
- Git: This is the powerful *software* that runs on your computer. It's the "engine" that does the actual version control work – tracking changes, managing history, etc. You use Git commands in your terminal.
- GitHub: This is a popular *website* (a platform) that hosts Git projects online. Think of it like Google Drive or Dropbox for your code. It adds collaboration features like sharing your code with others, reviewing changes, and managing projects. You can use Git without GitHub, but GitHub makes teamwork much easier!
Installation: Git is a command-line tool. You'll install it on your computer and interact with it via your terminal (e.g., Command Prompt on Windows, Terminal on Mac/Linux).
```
git --version # Check if Git is installed and see its version
```

Best Practices:

Always use .gitignore from the start. This file tells Git to ignore certain files or folders (like temporary files, system files, or sensitive information) that you don't want to track in your project. This keeps your repository clean and focused only on the important code.
Configure your global Git settings with your name and email. This is super important because every change you save (commit) will be linked to this identity. It helps your teammates know who made which changes.
```
git config --global user.name "John Doe"       # Your full name
git config --global user.email "john.doe@example.com" # Your email address
```

📘 Module 2: Repository Basics

What We Learn: Git's Three States (Simplified)

Working Directory: This is where you actually write and edit your code files. These are your "current changes."
Staging Area (Index): Think of this as a "holding area" or a "pre-commit zone." You pick and choose which changes from your working directory you want to include in your *next* snapshot (commit).
Local Repository: This is where all your "snapshots" (commits) are permanently stored on your computer. It's the complete history of your project.

Key Commands:

`git init`: How to *start* tracking a new project with Git. It creates the hidden .git folder that stores all the version control magic.

mkdir my_new_project      # Create a new folder
cd my_new_project         # Go into the folder
git init                  # Initialize Git in this folder

`git clone`: If someone else started a project (or you have one on GitHub), this command lets you *download a complete copy* of it to your computer.
```
git clone https://github.com/user/project-name.git
```
`git status`: Your "Git Assistant." This command tells you what's going on in your project: which files you've changed, which are new, and which are ready to be saved.
```
git status # Always run this to see your current Git situation!
```
`git add`: Moves changes from your "Working Directory" to the "Staging Area." You're telling Git: "Hey, I want to include *these specific changes* in my next snapshot."
```
git add my_amazing_feature.js # Stage a specific file
git add .                     # Stage ALL changes in the current folder (be careful!)
```
`git commit`: Takes everything in your "Staging Area" and permanently saves it as a "snapshot" (a commit) in your "Local Repository." Each commit is a point in time you can always go back to.
```
git commit -m "Add header section to homepage"
# The -m stands for 'message'. Write a clear, short message!
```

`git log`: Shows you the history of your project. You can see all the commits, who made them, and their messages. It's like looking through your project's diary.

git log            # Full, detailed history
git log --oneline  # Compact, one-line summary for each commit
git log --graph    # Shows branches and merges visually (super helpful!)

Best Practices:

Commit frequently with clear, concise messages. Small, regular commits are easier to understand and revert if needed. Imagine trying to debug one massive change vs. several small, logical ones!
Do not commit generated or sensitive files. Use your .gitignore file to tell Git to ignore things like compiled code, secret API keys, or temporary files.

📘 Module 3: Branching & Merging

What We Learn: Branches as Parallel Universes

Branches: Think of a branch as a separate "line of development" or a "parallel universe" for your project. The main branch is usually called main (or master). When you create a new branch, you're making a copy of your project at that moment, so you can make changes without affecting the main version. This is great for:
- Working on new features without breaking existing code.
- Experimenting with ideas that might not work out.
- Allowing multiple people to work on different things at once.

`git branch`: Use this command to manage your branches.

git branch new-feature       # Create a brand new branch named 'new-feature'
git branch                   # List all branches you have (the one with '*' is your current branch)
git branch -d old-branch     # Delete a branch you've already merged (clean up!)
git branch -D old-branch     # Force delete a branch (use with caution, even if not merged)

`git checkout`: This is how you *switch* between these parallel universes (branches). When you checkout a branch, your files in the working directory change to match that branch's version.
```
git checkout new-feature    # Switch to the 'new-feature' branch
git checkout -b another-feature # Create a new branch AND switch to it in one go!
```
`git merge`: Once you've finished work on a feature branch, you'll want to bring those changes back into your main branch. This is what `git merge` does – it combines the histories of two branches.
```
git checkout main           # First, go to the branch you want to merge *into*
git merge new-feature       # Now, merge changes from 'new-feature' into 'main'
```
If Git can't figure out how to combine changes automatically (e.g., you and a teammate changed the *exact same line* differently), you'll encounter a Merge Conflict. Don't panic! Git will tell you which files have conflicts, and you'll manually decide which changes to keep. We'll cover resolving these on the next slide!
`git rebase` (Advanced - For Later!): This is another way to combine changes, but it rewrites your project's history to make it look cleaner and more linear. While powerful, it can be tricky for beginners and can cause issues if used on branches that others are actively working on. It's often best to stick with `git merge` until you're more comfortable.
```
# Not recommended for beginners on shared branches!
git checkout my-feature && git rebase main
```

Best Practices:

Follow consistent branch naming conventions (e.g., feature/login-page, bugfix/nav-bug, hotfix/critical-error). This makes it easy for everyone to understand the purpose of each branch.
Keep feature branches short-lived. The longer a branch lives separate from main, the more changes accumulate, and the harder (and more painful!) merges can become. Merge often!

⚠️ Module 4: Conflict Resolution

What are Conflicts?

A Git conflict happens when two different branches have changes to the same part of the same file, and Git cannot automatically decide which change to keep. This most commonly occurs during a `git merge` or `git pull`.
Common Causes:
- Two people editing the same lines in a file.
- One person deletes a file while another modifies it.
When a conflict occurs, Git will pause the merge and tell you which files are conflicted. You'll see "CONFLICT (content): Merge conflict in [filename]" in your terminal.

How to Resolve Conflicts:

1. Identify Conflicts: Run `git status` to see files marked as "unmerged".
```
git status
```
2. Open the Conflicted File: You'll see special "conflict markers" in your code:
```
<<<<<<< HEAD
This is the content from my current branch (HEAD).
=======
This is the content from the branch I'm merging.
>>>>>>> feature/my-feature
                        
```
* `<<<<<<< HEAD`: Marks the beginning of the changes from your current branch. * `=======`: Separates your changes from the incoming changes. * `>>>>>>> feature/my-feature`: Marks the end of the incoming changes from the other branch.
3. Manually Edit: Delete the conflict markers and edit the code to the desired final version. You decide which parts to keep, combine, or discard.
4. Stage the Resolved File: After editing, tell Git that you've resolved the conflicts for that file.
```
git add conflicted_file.txt
```
5. Commit the Merge: Once all conflicts are resolved and staged, commit to complete the merge. Git often provides a default commit message.
```
git commit -m "Merge branch 'feature/my-feature' into main (resolved conflicts)"
```

Best Practice:

Don't be afraid of conflicts! They are a normal part of collaborative development. Practice resolving them to get comfortable.

📘 Module 5: Intro to GitHub

What We Learn: Sharing Your Code Online!

Creating Repositories on GitHub: This is where you create a new online home for your Git project. Once it's on GitHub, others can see it, contribute to it, and you have a remote backup of your code!

`git remote`: This command tells your local Git repository where its online counterpart is. The most common remote name is origin, which usually points to the GitHub repository you cloned or linked.

git remote add origin https://github.com/your-username/your-repo.git # Link your local repo to GitHub
git remote -v                                                        # See which remotes you have linked

`git push`: This is how you "upload" your local saved commits (snapshots) from your computer to your GitHub repository. You're sharing your progress with the world (or your team)!
```
git push origin main         # Push your local 'main' branch to the 'origin' remote
```
`git fetch`: This command downloads the latest changes from the GitHub repository to your local computer, *but it doesn't automatically apply them to your working files*. It's like "checking for new mail" without opening it yet. It lets you see what's new without changing your current work.
```
git fetch origin             # Fetch all new commits from GitHub's 'origin'
```
`git pull`: This is a combination of `git fetch` AND `git merge`. It downloads the latest changes from GitHub and then automatically tries to integrate them into your current local branch. It's like "checking for new mail AND opening it immediately."
```
git pull origin main         # Pull changes from 'origin/main' into your current branch
```
It's good practice to git pull before starting work each day to ensure you have the latest code.

Best Practices:

Always write a comprehensive README.md file. This is the first thing people see when they visit your GitHub repository. It should explain what your project is, how to set it up, how to run it, and how others can contribute.
Include a LICENSE file. This file tells others how they are allowed to use, modify, and distribute your code. It's important for protecting your work and for open-source collaboration.
In team environments, set up branch protection rules on critical branches (like main or develop). These rules can require things like code reviews or automated tests to pass before new code can be added, ensuring high quality.

📘 Module 6: Pull Requests & Code Review

What We Learn: Teamwork with Pull Requests

Pull Requests (PRs): A Pull Request (often called a PR, or Merge Request on other platforms) is your way of formally proposing changes from a feature branch back into the main branch on GitHub. It's not just about merging code; it's about starting a conversation! Think of it as "asking for feedback on your work before it becomes official."
Reviewers: When you open a PR, you'll ask teammates to be "reviewers." Their job is to carefully look at your code, suggest improvements, catch potential bugs, and ensure it follows project standards. This improves code quality and helps everyone learn.
Discussion: The PR page on GitHub is a central place for discussion. Reviewers can leave comments on specific lines of code, ask questions, or suggest alternative solutions. This back-and-forth helps refine the changes before they are integrated.
Approvals: Once the code has been reviewed, all feedback has been addressed, and the reviewers are satisfied, they can "approve" the Pull Request. Often, a certain number of approvals are required before the code can be merged into the main branch, acting as a quality checkpoint.

Best Practices:

Keep PRs focused and small. Each PR should ideally address a single feature, bug fix, or a small, logical set of changes. Smaller PRs are much easier and faster for reviewers to understand and approve, leading to quicker integration.
Use draft PRs (sometimes called "Work In Progress" or "WIP" PRs). This is a great way to open a PR even if your work isn't finished. It signals to your team that you're working on something and allows for early feedback, without implying it's ready for final review and merge.