Git & GitHub

As soon as you start working on real projects — especially with other people — you need a way to track changes to your code over time, undo mistakes, and collaborate without overwriting each other's work. That's exactly what Git and GitHub provide.

1. What is Git?

What is it?

Git is a version control system — a tool that tracks every change made to your files over time, letting you see history, undo mistakes, and work on different versions of your code simultaneously.

Definition: Git is a distributed version control system that tracks changes to files over time, enabling collaboration and history tracking.

What is GitHub?

Git and GitHub are not the same thing:

• Git is the version control tool itself, running on your computer.
• GitHub is a website that hosts Git repositories online, adding collaboration features (pull requests, issues, project boards) on top of Git.

Think of Git as the engine, and GitHub as one popular place to park and share your car (other similar platforms include GitLab and Bitbucket).

Why do we use it?

• History — see exactly what changed, when, and who changed it.
• Undo mistakes — go back to any previous saved version.
• Collaboration — multiple people can work on the same project without overwriting each other's work.
• Backup — your code is safely stored on GitHub, not just on one laptop.

2. Initializing a Repository

What is it?

A repository (often shortened to "repo") is a project folder that Git is tracking.

Simple Example

bash
mkdir my-project
cd my-project
git init

Explanation: git init turns the current folder into a Git repository by creating a hidden .git folder, which stores all the tracking history behind the scenes.

Important Points

• git init only needs to be run once per project.
• The hidden .git folder is where all of Git's tracking data actually lives — never delete it unless you want to remove all history.

3. The Basic Git Workflow: status, add, commit

git status — See What's Changed

bash
git status

Shows which files are new, modified, or staged (ready to be saved).

git add — Stage Changes

bash
git add filename.py       # stage one specific file
git add .                  # stage ALL changed files in the current folder

Explanation: "Staging" means marking changes as ready to be included in the next save point (commit). You can stage some files and leave others out, giving you control over exactly what gets saved together.

git commit — Save a Snapshot

bash
git commit -m "Add student grade calculation function"

Explanation: A commit is a permanent snapshot of your staged changes, along with a message describing what changed. -m lets you write the message directly in the command.

The Full Cycle — Simple Example

bash
# Edit some files...
git status                                    # see what changed
git add .                                      # stage everything
git commit -m "Add login validation feature"   # save the snapshot

Common Mistakes

• Forgetting git add before git commit — nothing gets committed if nothing is staged.
• Writing vague commit messages like "fixed stuff" instead of clear, descriptive ones like "Fix ZeroDivisionError in calculate_average()".
• Committing far too rarely (one giant commit at the end of a project) instead of small, frequent, logical commits.

Important Points

• git status is your best friend — run it often to see exactly what Git currently sees.
• Good commit messages describe what changed and, ideally, why.

Practice

1. Initialize a Git repository, create a text file, and commit it with a clear message.

4. Connecting to GitHub

Cloning an Existing Repository

bash
git clone https://github.com/username/repository-name.git

Explanation: This downloads a complete copy of an existing repository (including its full history) onto your computer.

Connecting a Local Repository to GitHub

bash
git remote add origin https://github.com/username/repository-name.git
git branch -M main
git push -u origin main

Explanation: remote add origin links your local repository to a specific GitHub repository (called "origin" by convention). push uploads your local commits to GitHub.

git push and git pull

bash
git push          # upload your local commits to GitHub
git pull           # download and merge new commits from GitHub into your local copy

Real-World Example

A typical workflow: pull the latest changes from your team → make your own changes → commit them → push them back up to GitHub for others to see and pull.

Common Mistakes

• Forgetting to git pull before starting new work, potentially missing your teammates' latest changes.
• Forgetting to git push after committing, meaning your changes only exist on your own computer, invisible to your team.

Important Points

• clone downloads a repository for the first time; pull updates an already-cloned repository with new changes.
• push shares your local commits with everyone else (via GitHub).

5. Branching

What is it?

A branch is an independent line of development — letting you work on a new feature or fix without touching the main, stable version of the code until you're ready.

Definition: A branch is a separate line of development that allows changes to be made independently of the main codebase.

Simple Example

bash
git branch feature-login          # create a new branch
git checkout feature-login         # switch to it

# OR, in one step:
git checkout -b feature-login

# Modern alternative:
git switch -c feature-login

Explanation

• Creating a branch essentially makes a snapshot copy of the code at that point, which you can freely modify without affecting the main branch.
• Once your feature works, you can merge it back into main.

Real-World Example

A team working on an e-commerce site might have separate branches like feature-payment-gateway, bugfix-cart-total, and main — each developer works on their own branch, merging into main only once their work is tested and ready.

Important Points

• main (or sometimes master) is typically the primary, stable branch.
• Creating a new branch for each feature/fix is standard professional practice — avoid making changes directly on main in team projects.

6. Merging

What is it?

Merging combines changes from one branch into another — typically, merging a completed feature branch back into main.

Simple Example

bash
git checkout main
git merge feature-login

Explanation: This takes all the commits made on feature-login and integrates them into main.

Merge Conflicts

What is it?

A merge conflict happens when Git can't automatically decide how to combine changes — usually because the same lines of the same file were changed differently on both branches.

<<<<<<< HEAD
print("Hello from main")
=======
print("Hello from feature-login")
>>>>>>> feature-login

Explanation: Git marks the conflicting section clearly. You must manually decide what the final code should look like, delete the conflict markers (<<<<<<<, =======, >>>>>>>), then git add and git commit to finalize the resolution.

Common Mistakes

• Panicking at a merge conflict — it's a normal, expected part of collaborative development, not a sign something is broken.
• Forgetting to remove the conflict marker lines (<<<<<<<, =======, >>>>>>>) themselves after resolving.

Important Points

• Merge conflicts happen when Git can't automatically reconcile changes — they require manual review and resolution.
• After resolving a conflict, you still need to git add the resolved file(s) and git commit.

Practice

1. Create two branches, make conflicting changes to the same line of the same file on each, merge them, and practice resolving the conflict.

7. Pull Requests (GitHub Feature)

What is it?

A Pull Request (PR) is a GitHub feature (not a raw Git command) that proposes merging changes from one branch into another — typically used to request that a teammate review your code before it's merged into main.

Typical Workflow

1. Create a new branch and make your changes.
2. Push the branch to GitHub: git push -u origin feature-login.
3. On GitHub's website, open a Pull Request comparing feature-login to main.
4. Teammates review the code, leave comments, and request changes if needed.
5. Once approved, the PR is merged into main (often with a single click on GitHub).

Real-World Example

Pull requests are the standard way professional teams review code before it becomes part of the main project — catching bugs, enforcing code style, and sharing knowledge across the team.

Important Points

• Pull Requests are a GitHub (and similar platforms') feature layered on top of Git's branching/merging — not a Git command itself.
• Code review through PRs is one of the most important collaborative practices in professional software development.

8. .gitignore

What is it?

A .gitignore file tells Git which files or folders to never track — like virtual environments, log files, or files containing secrets.

Simple Example

File: `.gitignore`

venv/
__pycache__/
*.pyc
.env
*.log

Explanation

• Each line is a pattern for files/folders Git should ignore completely — they won't show up in git status, won't be staged by git add ., and won't ever be committed.
• This is essential for excluding things like virtual environments (recreatable from requirements.txt) and files containing secrets (like API keys in a .env file).

Common Mistakes

• Forgetting to add a .gitignore file early, then accidentally committing a virtual environment folder or a secrets file — which can be tricky to fully remove from history afterward.
• Committing .env files containing real passwords or API keys, exposing them publicly if the repository is public.

Important Points

• Always set up .gitignore at the very start of a new project, before your first commit.
• Never commit files containing passwords, API keys, or other secrets.

9. README.md

What is it?

A README.md file is the front page of a repository — automatically displayed on GitHub's repository page, explaining what the project is and how to use it.

Simple Example

markdown
# My Python Project

A simple command-line student management system.

## Features
- Add, view, and update student records
- Data stored in SQLite

## Installation
\`\`\`bash
pip install -r requirements.txt
python app.py
\`\`\`

## Author
Your Name

Important Points

• Every real project should have a clear README.md — it's often the first (and sometimes only) thing someone reads before deciding whether to use or contribute to your project.
• Written in Markdown — the same lightweight formatting language used throughout this course.

Common Beginner Mistakes — Summary for This Section

• Forgetting git add before git commit.
• Writing unclear, vague commit messages.
• Making changes directly on main instead of using feature branches.
• Committing secrets or virtual environment folders due to a missing .gitignore.
• Panicking at merge conflicts instead of resolving them methodically.

Cheat Sheet — Git & GitHub

bash
git init                              # start tracking a folder
git status                             # see current changes
git add .                              # stage all changes
git commit -m "message"                # save a snapshot

git clone <url>                        # download an existing repo
git push                               # upload commits to GitHub
git pull                                # download new commits from GitHub

git branch <name>                       # create a branch
git checkout <name>                     # switch to a branch
git checkout -b <name>                  # create AND switch in one step
git merge <branch-name>                 # merge a branch into the current one

# .gitignore example
venv/
__pycache__/
.env

Interview Questions

Q1. What is the difference between Git and GitHub? Answer: Git is the version control tool itself, running locally. GitHub is a website that hosts Git repositories online and adds collaboration features like Pull Requests, issues, and project boards on top of Git.

Q2. What is the difference between `git add` and `git commit`? Answer: git add stages changes, marking them as ready to be saved. git commit actually saves a permanent snapshot of the staged changes, along with a descriptive message.

Q3. What is a branch, and why would you use one? Answer: A branch is an independent line of development, letting you work on new features or fixes without affecting the main, stable codebase until the work is complete and merged.

Q4. What causes a merge conflict, and how do you resolve one? Answer: A merge conflict occurs when Git cannot automatically reconcile changes made to the same lines of the same file on two different branches. It's resolved by manually reviewing the conflicting sections, deciding on the final content, removing the conflict markers, then staging and committing the resolved file.

Q5. What is a Pull Request? Answer: A GitHub feature for proposing that changes from one branch be merged into another, typically used to allow team members to review code before it becomes part of the main codebase.

Q6. What is the purpose of a `.gitignore` file? Answer: To tell Git which files or folders should never be tracked or committed — commonly used for virtual environments, cache files, and files containing secrets.

Practice Questions

Beginner

1. Initialize a new Git repository and make your first commit.
2. Create a .gitignore file that excludes a venv/ folder and .env files.
3. Make three separate commits to a project, each with a clear, descriptive message.
4. Create a GitHub repository and push a local project to it.
5. Write a simple README.md for a small project you've created in this course.

Intermediate

1. Create a new branch, make a change, and merge it back into main.
2. Clone an existing public repository from GitHub and explore its commit history using git log.
3. Deliberately create a merge conflict between two branches, then resolve it.
4. Practice the full collaboration cycle: create a branch, push it to GitHub, and open a Pull Request (even on a personal test repository).
5. Use git status at each step of a small project to observe how it changes as you add, modify, and commit files.

Challenge

1. Set up a small project with a proper .gitignore, README.md, at least 5 meaningful commits, and one feature branch merged into main.
2. Simulate a small team workflow (even solo): create two branches for two different "features," make changes on each, and merge both into main, resolving any conflicts that arise.
3. Research and briefly explain (in a markdown file) the difference between git merge and git rebase.