Git & GitHub roadmap

Version control is a system that records changes to your files over time. Instead of saving messy duplicates like report final and report final v2, it tracks every single edit inside one tidy project folder.

Imagine an infinite undo history that never forgets. If a change breaks your code, you can easily inspect past versions and restore a working state. It protects your hard work and provides complete peace of mind.

• Tracks changes across all project files systematically
• Eliminates the need for duplicate file copies
• Allows you to revisit any past point safely
• Forms the foundation of modern software teamwork

Setting up Git tells the tool who you are before you begin tracking work. You configure your name and email address in your terminal, which labels every future save you make.

Think of it like stamping your signature in an office sign-in book. Once configured, you run git init inside an empty directory to create your very first repository. This hidden database stores your whole version history locally.

• Configures your username and email address globally
• Signs your personal identity to each recorded edit
• Initialises a new repository using the git init command
• Stores history in a hidden dot git folder

Saving in Git is a deliberate two-step process. First, you stage files using git add, which gathers the specific edits you wish to save. Then, you run git commit to permanently snapshot those staged changes.

Think of staging like placing items into a parcel and committing like sealing the box with an informative label. A clear message explains why you made the change so your future self understands it.

• git add stages files ready for saving
• git commit creates a permanent snapshot of changes
• Good messages explain why changes were introduced
• Small, frequent commits are easier to manage

Inspecting your history helps you understand how a project developed over time. Running git log shows a chronological list of commits, who made them, and when they occurred.

When you need more detail, git diff compares files line by line, highlighting additions in green and deletions in red. It is like reading the minutes of a meeting alongside the exact tracked changes of a document.

• git log lists past commits and author details
• git diff shows exact line changes between edits
• Shows precisely who altered what and when
• Helps diagnose when a bug was introduced

A branch is an independent line of development created from your main project. It allows you to build a new feature or experiment freely without risking your stable code.

Think of it as working on a photocopy of a master blueprint. You can sketch ideas, test alterations, and discard the draft if it fails, leaving the original blueprint untouched until you are ready.

• Isolates experimental work from stable production code
• Allows multiple features to progress side by side
• Fast and lightweight to create or delete
• Switched easily with the switch or checkout command

Merging brings the work from one branch back into another, usually returning completed features into the main branch. Git usually stitches the different file histories together automatically.

Occasionally, two branches alter the exact same line of code, triggering a merge conflict. Git stops and asks you to pick the correct version. Resolving conflicts calmly is a normal part of collaborating on software.

• Combines histories from separate branches into one
• Usually completes automatically without manual intervention
• Conflicts occur when identical lines are edited differently
• Resolving conflicts simply means selecting the right code

Mistakes happen to everyone, and Git provides specific tools to reverse them. Commands like git restore discard uncommitted local changes, returning files to their last clean state.

For committed work, git revert creates a brand new commit that safely undoes previous edits without erasing history. Advanced tools like git reset can rewind commits entirely, but should be used cautiously on shared code.

• git restore discards unwanted edits in working files
• git revert safely reverses past commits with new ones
• git reset rewinds history and requires extra care
• Never rewrite history that colleagues rely upon

Rebasing takes commits from your branch and replays them on top of another branch. This moves the starting point of your work forward, keeping the project log straight and linear.

Imagine taking a stack of post-it notes and lifting them to place them on top of a fresh pile of papers. However, you must never rebase branches shared publicly, as changing past commit histories confuses teammates.

• Replays your commits on top of another branch
• Creates a cleaner, linear history without merge commits
• Keeps your feature branch updated with main
• Avoid rebasing branches that other people share

A remote is a copy of your Git repository hosted on the internet, typically on GitHub. Setting up a remote allows you to share your work and collaborate with others globally.

You use git push to upload your local commits to the server, and git pull to download changes made by colleagues. This keeps your local laptop synchronised with the team copy.

• Remotes store your repository on a cloud server
• git push sends your commits to GitHub
• git pull fetches and integrates remote updates locally
• Ensures team members work from the same baseline

A pull request, or PR, is a formal proposal to merge changes from your branch into another branch on GitHub. It gives teammates a dedicated space to view differences and discuss your code.

Think of it as submitting an essay to a colleague for proofreading before publication. It encourages dialogue, catches errors early, and ensures the team agrees with your solution before it becomes permanent.

• Proposes merging code from your branch into main
• Shows an organised view of all file changes
• Provides a forum for questions and suggestions
• Protects main code from accidental unreviewed bugs

Code review is the practice of reading and evaluating someone else's pull request before approving it. Reviewers look for logic bugs, test coverage, and clear structure.

Good reviews are friendly, constructive, and focused on the code rather than the person. Receiving feedback helps you learn different approaches, while reviewing peers helps you understand the wider codebase and build collective ownership.

• Ensures code quality and catches hidden defects early
• Keeps comments polite, specific, and genuinely constructive
• Shares knowledge and coding standards across the team
• Treats feedback as an opportunity for mutual learning

GitHub Actions is an automation platform built into GitHub. It listens for events, like pushing a commit, and automatically runs predefined scripts in the cloud.

Imagine an assistant checking your work instantly. It can run automated tests, check code formatting, and deploy your site to the web whenever you update main. This ensures broken code is caught before reaching users.

• Automates repetitive testing and deployment workflows
• Triggers jobs automatically on push or pull request
• Configured using simple YAML files in your repository
• Prevents broken code from reaching production servers

Your GitHub profile serves as a living portfolio for developers and hiring managers. It showcases the projects you have built, your contributions, and your areas of interest.

Adding a profile README and clear documentation to your personal repositories makes your work approachable. A good README explains what the application does, how to run it locally, and the technical decisions you made.

• Acts as a public portfolio of your technical skills
• Special profile READMEs introduce you and your goals
• Clear project documentation invites people to test code
• Shows consistency, curiosity, and collaboration habits