Git and GitHub Mastery: From Basics to Collaboration

Git solves the collaboration problem

Git is a version control system created by Linus Torvalds in April 2005 to track who changed which line of code, when, and why. Before Git, developers working on Linux couldn't determine who made breaking changes, leading to constant conflicts and confusion.

April 2005

Git created in just a few days

Linus Torvalds developed Git to solve collaboration chaos

Centralized vs. Distributed version control

Centralized systems store all code on one server; if the server goes down or you lose internet, you cannot work. Distributed systems like Git give every developer a complete copy of the project history, allowing offline work and eliminating single points of failure.

Git's distributed model eliminates server dependency

Git is now ubiquitous

Approximately half of the world's software projects use Git today. It became so popular that Microsoft acquired GitHub for $8 billion in 2018.

~50%

of world's software projects use Git

Git's dominance in version control

Git is the tool, GitHub is the platform

Git is software that tracks code changes locally on your computer. GitHub is an online platform (created in April 2008) where you host Git repositories remotely so others can access and collaborate on your code.

Git manages code locally; GitHub hosts it online

GitHub Desktop simplifies Git workflows

GitHub Desktop is a GUI application that eliminates the need to memorize terminal commands. It makes Git accessible to non-technical users by providing a visual interface for commits, branches, and merges.

Installing Git on Windows, Mac, and Linux

On Windows, download from git-scm.com and run the installer. On Mac, use Homebrew (brew install git) after installing Homebrew. On Linux, use apt (apt-get install git). After installation, verify with 'git --version'.

Git installation steps across platforms

Configure Git with your identity

Run 'git config --global user.name "Your Name"' and 'git config --global user.email "your@email.com"' so that every commit is attributed to you. This is essential for collaboration.

Code moves through four locations in Git

Working Directory (your local files) → Staging Area (files ready to commit) → Local Repository (committed snapshots on your machine) → Remote Repository (code on GitHub). You control this flow with git add, git commit, git push, and git pull.

Git's four-location workflow

git init: Initialize a repository

Converts a folder into a Git repository by creating a hidden .git folder. This folder contains all version control data. Run 'git init' once per project.

git status: Check repository state

Shows which files are untracked, modified, or staged. Run it frequently to understand what Git sees. Output includes branch name, commits, and file status.

git add: Stage files for commit

Moves files from working directory to staging area. Use 'git add filename' for one file or 'git add .' to stage all changes. You can selectively stage only the files you want to commit.

git commit: Save a snapshot

Creates a checkpoint with a message describing changes. Use 'git commit -m "message"'. Good commit messages use present tense (e.g., 'Add login feature' not 'Added login feature').

git log shows all commits

Displays full commit history with hash, author, date, and message. Use 'git log --oneline' to see commits in one line per entry, making it easier to scan history.

Branches allow parallel development

A branch is a pointer to a commit. Create a feature branch to work independently without affecting the main branch. If the feature fails, delete the branch; if it succeeds, merge it back.

Typical branching workflow

Branching best practices

Create one branch per feature. Use descriptive names (e.g., 'feature/user-login'). Keep branches short-lived; merge as soon as work is complete. Delete merged branches. Never develop directly on main.

Best practices for branch management

Merging combines branches

Use 'git merge branch-name' to integrate a feature branch into main. Git automatically combines changes if they don't conflict. A merge commit is created to record the merge.

Merge conflicts require manual resolution

Conflicts occur when the same file is edited differently in two branches. Git marks conflicting sections with <<<<<<, ======, and >>>>>>. You must manually choose which version to keep, then commit the resolution.

Stash saves work without committing

Use 'git stash' to temporarily save uncommitted changes and clean your working directory. Retrieve them later with 'git stash pop'. Useful when you need to switch branches urgently without committing incomplete work.

Stashing workflow for temporary storage

Rebase replays commits on a new base

Instead of merging (which creates a merge commit), rebasing replays your branch's commits on top of the target branch. This keeps history linear and avoids merge commit clutter. Use 'git rebase main' from your feature branch.

When to merge vs. rebase

Use merge to preserve history and show that branches existed. Use rebase to keep history clean and linear. Many organizations prefer rebase to avoid merge commit bloat.

Tags mark important commits

Use tags to mark releases (e.g., v1.0, v1.1). Two types: annotated tags (with message) and lightweight tags (just a name). Create with 'git tag -a v1.0 -m "Release 1.0"' or 'git tag v1.0'.

Prevent tracking of unnecessary files

Create a .gitignore file and list files/folders to ignore (e.g., .env, node_modules/, build/). Git will not track these files. Essential for hiding secrets, build artifacts, and dependencies.

Using .gitignore to exclude files

Git doesn't track empty directories

To include an empty directory, add a .gitkeep file inside it. This allows Git to track the directory structure without actual content.

Create and manage repositories on GitHub

Sign up at github.com, create a new repository, choose public or private, optionally add README and .gitignore. Clone to your machine with 'git clone <url>' and start pushing code.

Creating a GitHub repository

Push and pull to sync with GitHub

Use 'git push origin main' to upload commits to GitHub. Use 'git pull origin main' to download changes from GitHub. 'git fetch' downloads without merging; 'git pull' downloads and merges.

Collaborate with pull requests

Create a pull request (PR) to propose merging a branch into main. Team members review, comment, and approve before merging. PRs enable code review and discussion before integration.

GitHub Desktop eliminates command-line complexity

Download from desktop.github.com. Provides visual interface for cloning, committing, branching, and pushing. Ideal for beginners or those uncomfortable with terminal commands. Handles authentication automatically.

Workflow in GitHub Desktop

Clone repository → make changes → stage files (click +) → write commit message → commit to branch → publish branch → create pull request. All done through GUI without terminal.

Git features built into VS Code

VS Code has built-in Git support. Stage files, write commit messages, and push directly from the editor. Use the Source Control panel (Ctrl+Shift+G) to manage commits without terminal.

Git Graph extension visualizes history

Install 'Git Graph' extension in VS Code to see a visual representation of commits and branches. Helps understand project history and branch relationships at a glance.

Fork creates a personal copy of someone else's repo

Click 'Fork' on GitHub to create your own copy of a repository. You have full control over your fork. Use forks to contribute to open-source projects or experiment without affecting the original.

Pull requests enable open-source contributions

After forking and making improvements, create a pull request to propose merging your changes into the original repository. Maintainers review and decide whether to accept. Only contribute meaningful changes.

Collaboration workflow: issues, branches, PRs

Create issues to assign tasks. Team members create branches for each issue. After completing work, they push and create pull requests. Maintainer reviews and merges. Issues are closed when merged.

Typical multi-user collaboration workflow

Handling merge conflicts in teams

When two team members edit the same file, conflicts arise. Communicate with teammates, resolve conflicts manually by choosing which changes to keep, then commit the resolution.

Write meaningful commit messages

Use present tense ('Add login feature' not 'Added login feature'). Be specific about what changed and why. Good messages help future developers understand history.

Never push secrets to GitHub

Never commit passwords, API keys, or database credentials. Use .env files and add them to .gitignore. If secrets are exposed, they can be exploited by attackers.

Review code before committing

Always check what you're about to commit. Use 'git status' and 'git diff' to review changes. Avoid committing unintended changes.

Keep branches short-lived

Merge feature branches into main as soon as work is complete. Long-lived branches cause integration problems and merge conflicts.

AI can generate commit messages

Tools like GitHub Copilot can automatically generate meaningful commit messages based on your code changes. This saves time and ensures consistency.

AI assists with code review and suggestions

AI can suggest improvements, catch bugs, and help with code generation. Pair programming with AI is becoming more common in modern development workflows.