GitHub Guide for Cybersecurity Students

How to start learning Github and make notes at the same time!

You're here to learn cybersecurity, not become a Git expert. But here's the thing - after a few weeks of classes, you'll have dozens of exercise files scattered across your computer, and trust me, you'll lose track of what you did and when. GitHub solves this problem, and as a bonus, it shows future employers that you're serious about learning.

This guide will walk you through everything you need to know. I divide it into two parts:

1. First part will show how to operate with Github from terminal

2. Second part will show usage of VSCode (or similar tool eg. Cursor) for managig your github commits and repos.

Why bother with GitHub?

Before we dive in, let's talk about what you're actually getting out of this.

First, you'll never lose your work. Your laptop dies? No problem. Everything's backed up on GitHub. Working from a different computer? Just pull your notes down and continue where you left off.

Second, and this is the big one for job hunting - that contribution graph on your GitHub profile. You know those green squares showing your activity? Employers look at that. It shows consistency, dedication, and that you're actively learning. I've seen hiring managers specifically mention they check candidates' GitHub profiles during interviews.

Third, you're building a portfolio without even trying. After a semester, you'll have a complete record of your learning journey. When you apply for internships or jobs, you can point to specific projects and say "here's what I built, here's how I solved problems."

Getting started - first setup

Create your GitHub account

Head over to github.com and sign up. Here's the important part - choose your username carefully. Don't use something like "1337hacker420" or "xXcyberninjaXx". This is going to be on your resume. Think about it like choosing an email address for job applications. Something like "john-smith-cybersec" or just "johnsmith" works fine.

Use your personal email, not your school email. School emails get deactivated after you graduate, and you don't want to lose access to years of work.

Install Git on your machine

If you're on Windows: Download Git from git-scm.com/download/win and install it with all the default settings. Open PowerShell when it's done and type git --version to make sure it worked.

If you're on Mac: Open Terminal and type git --version. Your Mac might prompt you to install command line tools - just say yes and let it do its thing.

If you're on Linux: You probably already have it, but if not: sudo apt install git

Configure Git

Now you need to tell Git who you are. Open your terminal (or PowerShell on Windows) and run these commands:

git config --global user.name "Your Name"
git config --global user.email "[e-mail]"

This information gets attached to everything you commit, so people (and future employers) know it was you who did the work.

Setting up SSH keys

This part sounds scary but it's really not. SSH keys let you connect to GitHub without typing your password every single time. You generate a key pair - one stays on your computer (private key), one goes on GitHub (public key). When you try to push code, GitHub checks if your keys match.

Generate your key:

ssh-keygen -t ed25519 -C "[e-mail]"

It'll ask where to save it - just hit Enter for the default location. Then it asks for a passphrase. You can leave it empty (just hit Enter twice) or create one for extra security. I usually skip the passphrase for my personal laptop but use one on shared computers.

Now you need to copy your public key to GitHub.

Windows:

Get-Content ~/.ssh/id_ed25519.pub | Set-Clipboard

Mac:

pbcopy < ~/.ssh/id_ed25519.pub

Linux:

cat ~/.ssh/id_ed25519.pub

Then manually copy what it prints out.

Go to GitHub, click your profile picture in the top right, go to Settings, then "SSH and GPG keys" in the left menu. Click "New SSH key", give it a name like "My Laptop", and paste your key.

Test it:

ssh -T [e-mail]

If you see something like "Hi username! You've successfully authenticated..." then you're good to go.

Part 1.

Setting up your repository

Time to create your actual workspace. Go to GitHub, click the plus sign in the top right, and select "New repository".

Name it cybersecurity-learning or whatever makes sense to you. Add a description like "My cybersecurity exercises and projects". Make it Private - you don't want your learning mistakes visible to the world yet. Check the box to add a README file.

Hit Create Repository.

Now let's get this repository onto your computer. On the repository page, click the green "Code" button and make sure you're on the SSH tab. Copy that URL (it starts with [e-mail]).

Open your terminal and navigate to where you want to keep your work:

cd Documents
git clone [e-mail]:YOUR-USERNAME/cybersecurity-learning.git
cd cybersecurity-learning

Congratulations, you now have a local copy of your repository.

How to organize your work

This part is important. A good structure makes everything easier down the road. Here's what I recommend based on how your course is structured:

cybersecurity-learning/
├── README.md
├── Module-01-Networking/
│   ├── Week-01/
│   │   ├── 1-Network-Fundamentals/
│   │   │   ├── ex1_NW1.md
│   │   │   ├── ex2_NW1.md
│   │   │   ├── ex3_NW1.md
│   │   │   └── screenshots/
│   │   ├── 2-TCP-IP-Model/
│   │   │   ├── ex1_TCP.md
│   │   │   └── ex2_TCP.md
│   │   └── Weekly-Project-Network-Scanner/
│   │       ├── README.md
│   │       ├── report.md
│   │       ├── code/
│   │       └── screenshots/
│   └── Week-02/
│       └── ...
├── Module-02-Linux/
│   └── Week-03/
│       └── ...
└── Module-03-Web-Security/
    └── ...

The naming pattern is: Module-XX-Name/Week-XX/Chapter-Name/exX_CODE.md

Why this structure? It's logical, it's searchable, and when you're looking for "that nmap exercise from week 2", you'll actually be able to find it. Files sort automatically by module and week number, which is really handy.

Let's create the basic structure for your first module:

cd cybersecurity-learning
mkdir -p Module-01-Networking/Week-01/1-Network-Fundamentals
mkdir -p Module-01-Networking/Week-01/Weekly-Project-Network-Scanner/code

The -p flag creates parent directories if they don't exist, which saves you from running mkdir multiple times.

Now edit your README.md to add some basic info about what you're learning:

# Cybersecurity Learning Journey

Started: January 2024

This repository contains my coursework, exercises, and projects from my cybersecurity studies.

## Current Focus
Module 01: Networking Fundamentals

## Structure
Each module contains weekly folders with daily exercises and a weekly project.

## Stats
Modules completed: 0
Exercises completed: 0
Weekly projects: 0

Simple, clean, and you can update it as you go.

Now let's save this structure to GitHub:

git add .
git commit -m "Initial repository structure"
git push origin main

Wait a minute - what just happened? Let's break it down:

• git add . tells Git "hey, I want to save all these changes"

• git commit -m "message" actually saves them with a description

• git push origin main uploads everything to GitHub

Go check your repository on GitHub. You should see your folders there now.

Your daily workflow

This is where it gets real. You're doing 5-8 exercises per day, plus weekly projects. Let's talk about how to handle this without it becoming a chore.

Morning routine

At the start of your study session, make sure you have the latest version of your repository. If you're only working from one computer, this step is technically optional, but it's a good habit:

cd ~/Documents/cybersecurity-learning
git pull origin main

Working on exercises

Let's walk through a real example. Say you're working on network fundamentals today.

Navigate to the right folder:

cd Module-01-Networking/Week-01/1-Network-Fundamentals

Create your exercise file:

touch ex1_NW1.md

Open it in your favorite editor. I use VSCode (code ex1_NW1.md) but use whatever you're comfortable with - Cursor, Obsidian, even Notepad works.

Alright, you've finished your exercises for the day. Time to push everything to GitHub. This should take about 2 minutes.

cd ~/Documents/cybersecurity-learning

Check what you changed:

git status

This shows you all the files you created or modified. You'll see them listed in red (meaning they're not staged yet).

Add everything:

git add .

The dot means "add everything in the current directory and subdirectories". If you only want to add specific files, you can do git add path/to/file.md instead.

Commit with a descriptive message:

git commit -m "Complete exercises 1-5: Network fundamentals"

Good commit messages matter. When you're looking back through your history, "Complete exercises 1-5: Network fundamentals" is way more useful than "update" or "day 1". Be specific enough that future you understands what you did.

Push to GitHub:

git push origin main

That's it. Your work is now backed up on GitHub, and you'll see a green square on your contribution graph for today.

Some days you might want to commit after each exercise instead of all at once. That's fine too - just means more commits, which honestly isn't a bad thing. More green squares.

Weekly projects

Projects are bigger and deserve more attention. Let's walk through how to handle them.

When you start your weekly project, create its structure:

cd Module-01-Networking/Week-01
mkdir -p Weekly-Project-Network-Scanner/code
mkdir -p Weekly-Project-Network-Scanner/screenshots
cd Weekly-Project-Network-Scanner

Create a README that outlines what you're building:

# Network Scanner Project

## Goal
Build a Python script that scans a network range and identifies active hosts.

## Requirements
- Scan IP range 192.168.1.1-254
- Identify which hosts are up
- Check for common open ports
- Generate a report

## Technologies
- Python 3
- Scapy library for packet manipulation
- Socket library for port checking

## Timeline
- Day 1: Research and planning
- Day 2-3: Core scanning functionality
- Day 4: Port detection
- Day 5: Report generation
- Day 6: Testing and documentation

As you work on the project throughout the week, commit your progress:

git add .
git commit -m "Add basic host discovery functionality"
git push origin main

Don't wait until the project is done to commit. Push small, incremental changes. If something breaks, you can always roll back to a working version.

Understanding branches

Most of the time, you don't need branches for daily exercises. You're working alone, documenting your learning in a straightforward way. The main branch is fine.

But branches become useful for weekly projects when you want to try different approaches without messing up your working code.

Think of branches as parallel timelines. You create a branch, do some experimental work, and then either merge it back into main if it worked, or delete it if it didn't.

Here's a practical example. Say you're building that network scanner and you want to try two different scanning methods.

Start your project on main:

git checkout main
# create your initial project structure
git add .
git commit -m "Initial network scanner setup"

Now try approach 1 - using raw sockets:

git checkout -b try-raw-sockets
# implement raw socket scanning
git add .
git commit -m "Implement raw socket scanning"

The -b flag creates a new branch and switches to it in one command.

Try approach 2 - using Scapy:

git checkout main  # go back to main
git checkout -b try-scapy
# implement Scapy-based scanning
git add .
git commit -m "Implement Scapy scanning"

Now you have three branches: main (original setup), try-raw-sockets, and try-scapy. You can switch between them to compare:

git checkout try-raw-sockets
# test performance

git checkout try-scapy
# test performance

Scapy is clearly better for this use case (easier to work with, more reliable). Let's keep that approach:

git checkout main
git merge try-scapy
git push origin main

Clean up the branches you don't need:

git branch -d try-raw-sockets
git branch -d try-scapy

That's really all there is to branches for your use case. You probably won't use them for daily exercises, but they're handy for projects when you want to experiment.

Working on team projects

Here's where things get interesting. Some of your weekly projects will be team assignments - maybe 2-4 students working together. This is actually where Git really shines, but it's also where things can get messy if you don't have a clear workflow.

Let me walk you through how to handle collaborative projects without stepping on each other's toes.

Setting up a shared repository

First, someone needs to create the repository. Usually, this is whoever takes the lead on organizing the project, but honestly it doesn't matter who does it. Let's say that person is you.

Create a new repository on GitHub:

• Name it something like team-project-network-security-audit

• Make it Private (unless your instructor wants it public)

• Add a README

Now here's the crucial part - adding your teammates. Go to the repository settings, click on "Collaborators" in the left menu, and add your teammates by their GitHub usernames. They'll get an email invitation to accept.

Once they accept, everyone can clone the repository:

cd ~/Documents
git clone [e-mail]:team-lead/team-project-network-security-audit.git
cd team-project-network-security-audit

Everyone now has their own copy of the repository on their computer, all connected to the same GitHub repository.

The golden rule of teamwork

Before I explain the workflow, understand this: always pull before you start working, always push when you're done.

Seriously. This prevents about 90% of merge conflicts and confusion. Put a sticky note on your monitor if you need to: "Pull first, push last."

Project structure for team work

Set up a clear structure right from the start. This prevents people from accidentally working on the same files.

team-project-network-security-audit/
├── README.md
├── documentation/
│   ├── planning.md
│   ├── methodology.md
│   └── final-report.md
├── code/
│   ├── scanner.py          # Alice's responsibility
│   ├── analyzer.py         # Bob's responsibility
│   └── reporter.py         # Carol's responsibility
├── research/
│   ├── alice-notes.md
│   ├── bob-notes.md
│   └── carol-notes.md
└── testing/
    ├── test-results.md
    └── screenshots/

See how each person has their own file to work on? This minimizes conflicts. When three people try to edit the same file at the same time, that's when merge conflicts happen.

The basic team workflow

Let me show you a realistic scenario. You're Alice, working on the scanner component.

Day 1 - Morning:

cd team-project-network-security-audit
git pull origin main

Always start with pull. Maybe Bob pushed some changes last night. You want those.

Now create your branch:

git checkout -b alice-scanner-feature

Work on your code:

# edit code/scanner.py
# test your changes
git add code/scanner.py
git commit -m "Add basic port scanning functionality"

Keep working, committing as you go:

# more changes
git add code/scanner.py
git commit -m "Add timeout handling for scans"

# even more changes
git add code/scanner.py
git commit -m "Add progress indicator"

Day 1 - Evening:

When you're done for the day and your code works, push your branch:

git push origin alice-scanner-feature

Notice you're not pushing to main yet. You're pushing your own branch.

Pull Requests (PR) - the professional way

Now comes the important part. You don't just merge your code directly into main. You create a pull request (PR) so your team can review it.

Go to GitHub, and you'll see a yellow banner saying "alice-scanner-feature had recent pushes" with a button "Compare & pull request". Click it.

Fill out the pull request:

Title: "Add port scanning functionality"

Description:

## What I did
- Implemented basic port scanner using socket library
- Added timeout handling (3 seconds per port)
- Added progress indicator for user feedback

## Testing
Tested on my home network (192.168.1.0/24):
- Successfully scanned 1000 ports in ~45 seconds
- Correctly identified open ports 22, 80, 443
- Timeout handling works for unresponsive ports

## Notes for reviewers
- Check if 3 second timeout is reasonable
- Let me know if error handling needs improvement
- Haven't added threading yet - doing that next

Assign reviewers (your teammates), then create the pull request.

Reviewing code

Now Bob gets a notification that there's a pull request to review. This is super important - code review catches bugs and helps everyone learn.

Bob goes to the pull request on GitHub, looks at the code, and can:

1. Approve it if it looks good

2. Request changes if something needs fixing

3. Comment on specific lines to ask questions or suggest improvements

Real example of helpful review comments:

# Alice's code
timeout = 3

# Bob's comment on this line:
"Should this be configurable? Some networks might need longer timeouts."

This is how teams improve. Bob caught something Alice didn't think about.

Alice sees the comment and responds:

# Alice updates the code
def __init__(self, timeout=3):
    self.timeout = timeout

She commits the change to her branch:

git add code/scanner.py
git commit -m "Make timeout configurable based on review feedback"
git push origin alice-scanner-feature

The pull request automatically updates with the new commit.

Bob reviews again, sees it's fixed, and approves the PR.

Merging the pull request

Once approved, someone (usually the person who created the PR) clicks "Merge pull request" on GitHub.

Now Alice's code is in the main branch. She should clean up:

git checkout main
git pull origin main  # get the merged code
git branch -d alice-scanner-feature  # delete local branch

Handling your teammate's changes

Meanwhile, Carol has been working on the reporter component. When Alice pulls main to get the latest changes:

git pull origin main

She gets Carol's reporting code along with her own scanner code. Now everyone has all the latest work.

The merge conflict scenario

Let's be honest - merge conflicts will happen. Here's a realistic example.

Both Alice and Bob are editing the main README file to document their components. Alice pushes first:

git add README.md
git commit -m "Document scanner usage"
git push origin main

Bob finishes his section and tries to push:

git add README.md
git commit -m "Document analyzer usage"
git push origin main

Git refuses: "Failed to push some refs". Bob's local main is outdated.

Bob pulls:

git pull origin main

Git tries to merge automatically, but both Alice and Bob edited the same section of README.md. Git shows:

CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Bob opens README.md and sees:

## Usage

<<<<<<< HEAD
To use the analyzer:

python analyzer.py --target 192.168.1.0/24

=======
To use the scanner:

python scanner.py --ports 1-1000

>>>>>>> origin/main

The section between <<<<<<< HEAD and ======= is Bob's version. The section between ======= and >>>>>>> origin/main is Alice's version (from GitHub).

Bob needs to combine them manually:

## Usage

To use the scanner:

python scanner.py --ports 1-1000

To use the analyzer:

python analyzer.py --target 192.168.1.0/24

Remove the conflict markers, save the file:

git add README.md
git commit -m "Merge Alice's scanner docs with my analyzer docs"
git push origin main

Done. Conflict resolved.

Team workflow best practices

After working on several team projects, here's what actually works:

1. Divide work by files, not by lines

Bad approach: Everyone edits main.py together Good approach: Alice writes scanner.py, Bob writes analyzer.py, Carol writes reporter.py

2. Create feature branches for significant work

Don't work directly on main. Create branches, get them reviewed, then merge.

3. Keep your branches short-lived

Don't spend two weeks on a branch. Break work into smaller pieces. Merge frequently.

4. Communicate in pull request descriptions

Your teammates aren't mind readers. Explain what you did and why.

5. Review each other's code seriously

Actually read it. Look for bugs, suggest improvements, ask questions. This is how everyone gets better.

6. Pull frequently

Pull at least twice a day - morning and evening. More if your team is actively working.

7. Use meaningful branch names

Good: alice-scanner-feature, bob-fix-timeout-bug, carol-add-logging Bad: test, new-branch, alice-work

When someone isn't pulling their weight

This happens. Someone on your team isn't committing their part. Here's what you do:

Check their contribution:

git log --author="their-name" --oneline

If they have zero commits, you have evidence. Talk to your instructor.

If they're committing but their code doesn't work, you can see exactly what they did:

git log --author="their-name" -p

The -p flag shows the actual code changes. You can see if they're really working or just committing nonsense.

GitHub also shows contribution graphs on the repository page. Click "Insights" then "Contributors" to see who did what.

Protecting the main branch

For important team projects, consider protecting the main branch. This prevents anyone from pushing directly to main without a pull request.

Go to repository Settings → Branches → Add rule. Set branch name pattern to main and check "Require pull request before merging".

Now everyone must use branches and pull requests. No one can accidentally push broken code to main.

This is how real software teams work. It's a good habit to learn.

Quick team workflow reference

Daily routine for each team member:

Morning:

git pull origin main
git checkout -b your-name-feature
# work on your part

Throughout the day:

git add your-files
git commit -m "Descriptive message"
# repeat as needed

Evening:

git push origin your-name-feature
# Create pull request on GitHub
# Ask teammates to review

When teammate creates PR:

• Go to GitHub

• Review their code

• Comment, approve, or request changes

When your PR is approved:

• Merge it on GitHub

• Locally: git checkout main

• git pull origin main

• git branch -d your-branch-name

The cycle continues until the project is complete.

Common team workflow problems

Problem: Someone pushed broken code to main, now everyone's build is broken.

Solution: Find the commit that broke it using git log. Revert it:

git revert broken-commit-hash
git push origin main

Everyone pulls and they get the fix.

Problem: Two people accidentally worked on the same file.

Solution: Whoever pushes second will get a conflict. Follow the merge conflict resolution steps above. Next time, communicate better about who's working on what.

Problem: Someone committed a huge binary file (screenshot that's 50MB) and now the repository is slow.

Solution: Remove it from history (this is complicated, ask your instructor for help). Better: use .gitignore to prevent committing large files in the first place.

Problem: Teammate isn't responding to pull request reviews.

Solution: Set a team agreement on response time. "All PRs reviewed within 24 hours" is reasonable. If someone consistently ignores reviews, escalate to instructor.

Making team work smoother

Create a CONTRIBUTING.md file in your repository:

# Contributing Guidelines

## Branch Naming
- Feature: `name-feature-description`
- Bug fix: `name-fix-description`
- Example: `alice-add-logging`, `bob-fix-timeout`

## Commit Messages
- Start with verb: "Add", "Fix", "Update", "Remove"
- Be specific: "Add port scan timeout" not "update code"

## Pull Requests
- Describe what you changed and why
- Include testing notes
- Request review from at least one teammate

## Code Review
- Review within 24 hours
- Be constructive, not critical
- Suggest improvements, don't just say "this is wrong"

## Merge Conflicts
- Don't panic
- Read the conflicted section carefully
- Keep what makes sense from both versions
- Test after resolving
- Ask for help if stuck

Everyone reads this on day one, and you avoid a lot of confusion.

Final thoughts on teamwork

Working on team projects with Git feels awkward the first time. You'll make mistakes - push to the wrong branch, forget to pull, create merge conflicts. That's fine. Everyone does this.

By your third team project, it'll feel natural. You'll wonder how people ever collaborated on code without version control.

The key is communication. Git is just the tool. Talk to your teammates about who's doing what, review each other's work, and help each other when things go wrong.

And remember - the commit history tells the truth. If someone says they "worked all weekend" but has zero commits, well, the evidence speaks for itself.

Tracking your progress

After a few weeks of consistent commits, go look at your GitHub profile. That contribution graph with the green squares is actually pretty motivating. I've had weeks where I committed just to keep the streak going.

The graph shows employers that you're consistently learning and working. It's not just about having a good portfolio project - it's about showing you put in the work day after day.

You can make this more visible by keeping your main README updated. Every week or two, edit it to reflect your progress:

# Cybersecurity Learning Journey

Started: January 15, 2024

## Current Status

Modules completed: 1/5
Exercises completed: 47
Weekly projects: 3

Currently working on: Module 02 - Linux Security (Week 2 of 4)

## Completed Work

### Module 01: Networking Fundamentals
- Week 01: Network basics, TCP/IP model
- Week 02: Network protocols and services
- Week 03: Network security fundamentals
- Week 04: Advanced networking concepts

Weekly Projects:
1. Network Scanner
2. Packet Analyzer
3. Simple Firewall
4. Network Monitoring Tool

### Module 02: Linux Security (In Progress)
- Week 05: Linux basics and shell scripting
- Week 06: File permissions and user management

## Skills Developed
- Network scanning and reconnaissance
- Python scripting for security tools
- Packet analysis with Wireshark
- Linux command line proficiency
- Basic penetration testing methodology

## Next Up
- Complete Module 02: Linux Security
- Start Module 03: Web Application Security
- Begin working on TryHackMe boxes

Update this every week or two. It takes five minutes and gives anyone looking at your repository a clear picture of your learning journey.

Making some work public

Everything we've set up so far is private, which is good for learning. But eventually, you'll want to showcase your best work.

There are a few ways to handle this. The cleanest approach is to create a second repository for your portfolio.

After you've completed a few weekly projects and you're happy with them, create a new repository on GitHub called cybersecurity-portfolio and make it Public.

Clone it to your computer:

cd ~/Documents
git clone [e-mail]:YOUR-USERNAME/cybersecurity-portfolio.git
cd cybersecurity-portfolio

Now copy your best project from your private repository:

cp -r ~/Documents/cybersecurity-learning/Module-01-Networking/Week-01/Weekly-Project-Network-Scanner ./

Clean it up - remove any personal notes, make sure your code is well-commented, write a professional README. Then push it:

git add .
git commit -m "Add network scanner project"
git push origin main

Now that project is public and you can link to it on your resume or LinkedIn. Your private repository still has all your raw learning materials, mistakes and all.

When things go wrong

Something will eventually break. Here are the most common issues and how to fix them.

"Permission denied (publickey)"

Your SSH key isn't working. First, check if your SSH agent is running:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Try connecting again:

ssh -T [e-mail]

If it still doesn't work, you might need to regenerate your SSH key and add it to GitHub again.

"Failed to push some refs"

Someone (probably you from another computer) made changes on GitHub that you don't have locally. Pull first:

git pull origin main

If there are conflicts, Git will tell you which files. Open those files and you'll see something like this:

<<<<<<< HEAD
Your local changes
=======
Remote changes from GitHub
>>>>>>> origin/main

Edit the file to keep what you want, remove those marker lines, then:

git add .
git commit -m "Resolve merge conflict"
git push origin main

"I committed sensitive data"

If you haven't pushed yet:

git reset --soft HEAD~1  # undo the commit but keep your changes
# edit files to remove sensitive data
git add .
git commit -m "Your message"

If you already pushed, it's more complicated. Honestly, the easiest solution is to delete the repository and start fresh. Before you do that, copy any files you want to keep to a safe location outside the repository.

This is why you should always check what you're committing with git status before you push.

Preventing sensitive data leaks

Create a .gitignore file in your repository root:

cd ~/Documents/cybersecurity-learning
touch .gitignore

Add patterns for files you never want to commit:

# Sensitive stuff
*.key
*.pem
credentials.txt
passwords.txt
secrets/

# OS junk
.DS_Store
Thumbs.db

# Editor files
.vscode/
.idea/

# Temporary files
*.tmp
*.log
temp/

Git will ignore files matching these patterns. They won't show up in git status and won't be committed even if you do git add .

Part 2. Working with Git in VSCode

VSCode has built-in Git integration that makes version control more visual and intuitive. Since you'll be working in the editor anyway, using its Source Control features is often more efficient than switching to terminal. This section covers the same Git operations you learned earlier, but through VSCode's graphical interface.

Cloning a repository in VSCode

Open VSCode and access the command palette:

• Mac: Cmd+Shift+P

• Windows/Linux: Ctrl+Shift+P

Type Git: Clone and press Enter. Paste your repository URL ([e-mail]:YOUR-USERNAME/cybersecurity-learning.git) and select a location to save it. VSCode will download the repository and prompt you to open it.

If you already cloned the repository using terminal, navigate to the folder and run:

cd ~/Documents/cybersecurity-learning
code .

Understanding the Source Control panel

The Source Control panel is located in the left sidebar (third icon from the top, resembling a branch diagram). This panel contains several key areas:

CHANGES section Files you've modified but haven't staged yet appear here. Each file shows a status indicator:

• M = Modified file

• U = Untracked (new file not yet added to Git)

• D = Deleted file

STAGED CHANGES section Files ready to be committed appear in this section after you stage them.

Commit message input Text box at the top where you write your commit description.

Action buttons

• Checkmark icon: Commit staged changes

• Three dots (...): Additional Git operations (pull, push, branch management)

Status bar indicators (bottom of window)

• Branch name (e.g., "main")

• Sync arrows with numbers showing commits to push/pull

• Additional Git status information

Making and committing changes

Let's walk through a complete example. Open README.md and add a line:

# Cybersecurity Learning Journey

Started: January 2024

test

Save the file (Cmd+S or Ctrl+S). The Source Control panel now shows README.md under CHANGES with an M indicator.

Viewing the diff

Click on README.md in the Source Control panel. VSCode displays a split view:

• Left side: Original content (deletions in red)

• Right side: Modified content (additions in green)

This visual comparison helps you review exactly what changed before committing.

Staging changes

Hover over README.md in the CHANGES section. A plus (+) icon appears on the right. Click it to stage this file.

The file moves to STAGED CHANGES, indicating it's ready for commit.

To stage all changed files at once, click the plus icon next to "Changes" at the section header.

Writing a commit message

In the text box at the top of Source Control, type a descriptive message:

Add test line to README

Commit messages should be concise but informative enough that you'll understand what changed when reviewing history later.

Committing

Click the checkmark icon or press Cmd+Enter (Mac) / Ctrl+Enter (Windows/Linux).

Your changes are now committed to the local repository.

Pushing to GitHub

Click the circular arrows icon in the status bar and select "Sync Changes" or "Push". VSCode uploads your commit to GitHub.

File status indicators

VSCode uses colors and letters to communicate file status:

In the file explorer:

• Green: New file (untracked by Git)

• Orange/Yellow: Modified file

• Red: Deleted file

• Gray: Ignored file (listed in .gitignore)

In Source Control panel:

• U: Untracked (new file)

• M: Modified

• D: Deleted

• A: Added (newly staged file)

• C: Conflict (requires resolution)

In the status bar:

• Branch name indicates current working branch

• Up arrow with number: commits waiting to be pushed

• Down arrow with number: commits to pull from remote

• Asterisk or other indicators: uncommitted changes exist

Daily workflow

Starting your work session

1. Open VSCode

2. Open Source Control panel (Cmd+Shift+G / Ctrl+Shift+G)

3. Click the three dots (...) → Pull

This ensures you have the latest changes from GitHub.

During your work

1. Edit and save files as needed

2. Open Source Control to review changes

3. Click on files to view diffs before staging

4. Stage files using the plus icon

5. Write a commit message

6. Click the checkmark to commit

7. Click sync arrows to push

You can commit after each exercise or batch several together. Choose what makes sense for your workflow.

Ending your work session

Check the status bar before closing VSCode. If you see numbers next to the sync arrows, you have unpushed commits. Click the arrows and push to ensure your work is backed up on GitHub.

Working with multiple files

When you complete several exercises in one session, you'll have multiple files in the CHANGES section. You have two approaches:

Single commit for all files:

1. Click the plus icon next to "Changes" to stage everything

2. Write a commit message: Complete exercises 1-5: Network fundamentals

3. Click commit

4. Push

Individual commits per file:

1. Stage ex1_NW1.md individually

2. Commit with message: Add exercise 1: Basic network commands

3. Stage ex2_NW1.md

4. Commit with message: Add exercise 2: Network configuration

5. Continue for remaining files

6. Push once after all commits

The individual approach creates more detailed history but requires more steps. Choose based on your preference and the logical grouping of your work.

Viewing commit history

Timeline view

Open any file and click the clock icon in the top-right corner of the editor. This displays every commit that modified the current file, allowing you to see how it evolved over time.

Git Graph extension

For a comprehensive view of your repository history:

1. Open Extensions panel (Cmd+Shift+X / Ctrl+Shift+X)

2. Search for "Git Graph" by mhutchie

3. Install the extension

4. Click "Git Graph" in the status bar

This displays a visual tree showing all commits, branches, and their relationships.

Resolving merge conflicts

Conflicts occur when the same file is modified in two different locations (e.g., on your laptop and school computer). When you pull changes that conflict with your local work, VSCode shows the file under MERGE CHANGES with a C indicator.

Click the conflicted file. VSCode displays:

<<<<<<< HEAD (Current Change)
Your local version
=======
Version from GitHub (Incoming Change)
>>>>>>> origin/main

Above the conflict markers, VSCode provides buttons:

• Accept Current Change: Keep your local version

• Accept Incoming Change: Use the version from GitHub

• Accept Both Changes: Keep both versions

• Compare Changes: View side-by-side comparison

Click the appropriate button. The conflict markers disappear. Stage the file, commit with a message like Resolve merge conflict in README, and push.

Branch management in VSCode

Creating a branch

Click the branch name in the status bar (bottom-left corner). Select "Create new branch" from the menu, type a name (e.g., try-scanner-v2), and press Enter.

You're now working in a new branch. Changes here won't affect the main branch.

Switching branches

Click the branch name in the status bar and select a different branch from the list.

Merging branches

When your experimental branch contains work you want to keep:

1. Switch to the target branch (usually main)

2. Open Source Control → three dots (...) → Branch → Merge Branch

3. Select the source branch to merge

4. Resolve any conflicts if they occur

5. Push the merged changes

Deleting branches

After merging, clean up unused branches:

1. Source Control → three dots (...) → Branch → Delete Branch

2. Select the branch to remove

Common operations

Undoing the last commit (before pushing)

Source Control → three dots (...) → Commit → Undo Last Commit

Your changes return to the uncommitted state. Fix what you need, then commit again.

Discarding changes to a file

Right-click the file in Source Control → Discard Changes

The file reverts to its last committed state. This operation is permanent and cannot be undone.

Viewing specific commit details

Install the GitLens extension for enhanced Git capabilities:

1. Extensions panel → search "GitLens" by GitKraken → Install

2. Open any file to see inline commit information

3. Click on commit annotations for full details

Syncing across multiple computers

Always pull before starting work. Commit your local changes first if you forgot to pull. Then sync will prompt you to pull, potentially creating conflicts you'll need to resolve.

Keyboard shortcuts

Mac:

• Cmd+Shift+G: Open Source Control panel

• Cmd+K then Cmd+C: Commit

• Cmd+K then Cmd+P: Push

• Cmd+Enter: Commit staged changes

Windows/Linux:

• Ctrl+Shift+G: Open Source Control panel

• Ctrl+K then Ctrl+C: Commit

• Ctrl+K then Ctrl+P: Push

• Ctrl+Enter: Commit staged changes

Useful settings

Open Settings (Cmd+, / Ctrl+,) and search for these options:

Git: Autofetch Enable to automatically check for new commits on GitHub. VSCode will show notification if new commits are available.

Git: Confirm Sync Disable to skip confirmation dialog when syncing. Only disable once you're comfortable with Git operations.

Files: Auto Save Set to "afterDelay" so files save automatically after you stop typing. Reduces risk of losing work.

SCM: Default View Mode Set to "tree" to display files organized by folder structure in Source Control panel.

Recommended extensions

GitLens (by GitKraken) Displays commit information inline in your code, showing who changed each line and when. Provides enhanced blame annotations and powerful history browsing.

Git Graph (by mhutchie) Creates a visual representation of your commit tree, showing branches and merge relationships graphically.

Git History (by Don Jayamanne) Allows browsing file history, comparing commits, and searching through commit messages.

Install from Extensions panel (Cmd+Shift+X / Ctrl+Shift+X), search by name.

Troubleshooting

"Git not found" error

Git isn't installed on your system. Return to the Initial Setup section and install Git.

Authentication failed when pushing

SSH keys aren't configured correctly. Test in terminal:

ssh -T [e-mail]

If this doesn't confirm authentication, revisit the SSH setup section.

Source Control panel is empty

You're not in a Git repository. Either clone an existing repository or initialize a new one using "Initialize Repository" in the Source Control panel.

Hundreds of files showing in CHANGES

Missing or incomplete .gitignore file. System files like .DS_Store or dependency folders like node_modules/ are being tracked. Create .gitignore in repository root and add patterns for files to ignore.

VSCode versus terminal

Both interfaces access the same underlying Git functionality. Choose based on the task:

VSCode advantages:

• Visual diff view shows exactly what changed with color coding

• Point-and-click interface reduces command memorization

• Integrated with your editor workflow

• Harder to execute destructive operations accidentally

Terminal advantages:

• Required for initial repository setup

• Better for complex operations (rebasing, cherry-picking)

• Necessary for automation and scripting

• Faster for users comfortable with command line

Learn both approaches. Use VSCode for daily work and terminal when you need more control or are troubleshooting issues.

Wrapping up

That's really everything you need to know to use GitHub effectively for your cybersecurity studies. The daily workflow is simple:

1. Do your work and document it

2. git add .

3. git commit -m "descriptive message"

4. git push origin main

Do this consistently and you'll build both a valuable knowledge repository and an impressive GitHub profile.

The key is consistency. Commit every day, even if it's just one exercise. Those green squares add up, and future employers will notice.

A few final tips:

• Never commit real IP addresses, passwords, or sensitive information. Use examples or sanitize your screenshots.

• Write commit messages that future you will understand.

• Update your README regularly so people can see your progress.

• Keep your private repository for learning, create a public portfolio for showcasing.

• Don't stress about making mistakes - that's what private repositories are for.

Start simple. You don't need to understand every Git command or use advanced features. Master the basics first, and the rest will come naturally as you need it.