Home/Module 2

šŸ“ Module 2: Version Control with Git

ā±ļø Duration: approx. 90 Minutes

Learning Objectives: You will understand Git architecture (Working Directory, Staging, Repository), be able to work with branches, resolve merge conflicts, analyze Git history, and know proven branching strategies for network environments.

ā„¹ļøšŸ–„ļø Your Working Environment: Windows + VS Code + PowerShell

In this workshop, you are working on a Windows VM. Please note:

  • Open a terminal in VS Code via Terminal → New Terminal (PowerShell)
  • You are working in PowerShell on Windows
  • Creating/editing files: Use the VS Code Editor (create new file, type content, save)
  • Git commands: Are executed in the PowerShell terminal

šŸ“š Contents of This Module

  • 1. What is Git?
  • 2. The Three Zones of Git
  • 3. Essential Git Commands
  • 4. Branching Strategies
  • 5. Understanding Merge Conflicts
  • 6. Git History & Logs
  • 7. Hands-on Exercises (6 total)
  • 8. Cheat Sheet & Troubleshooting

1. What is Git?

Think of Git as save points in a video game. You can save at any time, and if something goes wrong, you simply load a previous save. Only much better: Git saves ALL save points, not just the last one.

šŸ’”Git in One Sentence
Git is a distributed version control system that records every change to your files and allows you to return to a previous state at any time – all without needing a permanent server connection.

Why Git for Network Configurations?

In the classic networking world, everyone knows the problem: "Who changed the switch port last night?" With Git, that is a thing of the past.

  • Complete History: Who made which change when – and why?
  • Rollback in Seconds: Last change was a mistake? One command, everything is fine again.
  • Parallel Work: Three people, three features, zero conflicts
  • Automatic Backup: Your code is safe on a server (GitLab, GitHub)
  • Code Review: Four-eyes principle before production
  • Audit Trail: Indispensable for compliance
ā„¹ļøComparison: Before vs. After
āŒ Without Git:
  • switch-config_v2_final_FINAL.txt
  • switch-config_backup_jan_new.txt
  • "Who changed that?!"
  • Rollback = Panic
āœ… With Git:
  • One file, complete history
  • Every change documented
  • git blame → instantly visible
  • git revert → 5 seconds

2. Understanding the Three Zones of Git

Before we start with the commands, you need to understand how Git works internally. Think of Git as a construction site with three areas:

ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”
│                        GIT - The Three Zones                             │
ā”œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¤
│                                                                          │
│   ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”    git add     ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”    git commit  │
│   │                 │ ─────────────> │                 │ ─────────────> │
│   │    WORKING      │                │    STAGING      │                │
│   │   DIRECTORY     │                │     AREA        │                │
│   │                 │ <───────────── │    (Index)      │                │
│   │  šŸ“ Your Files  │   git restore  │  šŸ“‹ Prepared    │                │
│   ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜                ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜                │
│          │                                                               │
│          │                                    │                          │
│          │                                    │                          │
│          │                                    ā–¼                          │
│          │                          ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”                 │
│          │                          │                 │                 │
│          │                          │   REPOSITORY    │                 │
│          │  <───────────────────────│    (.git)       │                 │
│          │       git checkout       │                 │                 │
│                                     │  šŸ’¾ History     │                 │
│                                     ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜                 │
│                                                                          │
ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜
šŸ“

Working Directory

The construction site: This is where you work! All the files you can see and edit. Changes here are not yet saved.

Analogy: The desk where you are currently working.

šŸ“‹

Staging Area (Index)

The shopping cart: This is where you collect changes that should be committed together. Like a shopping cart before checkout.

Analogy: The tray before taking a photo – you arrange first, then snap.

šŸ’¾

Repository (.git)

The archive: All commits, the entire history. Everything is safely stored here – forever.

Analogy: The video game archive with all save states.

šŸ’”The Workflow in One Sentence

You edit files in the Working Directory, stage them for the next commit, and commit them to the repository. Only then is the change truly saved!

Example: A Change Through All Zones

šŸ“„ PowerShell
# 1ļøāƒ£ You edit a file in VS Code (Working Directory)
# Open switch-config.yaml in VS Code and edit it

# 2ļøāƒ£ Status shows: File was changed (red = not staged)
git status
# modified:   switch-config.yaml  (red)

# 3ļøāƒ£ Move file to the Staging Area
git add switch-config.yaml

# 4ļøāƒ£ Status shows: File is ready to commit (green = staged)
git status
# modified:   switch-config.yaml  (green)

# 5ļøāƒ£ Create commit (off to the repository!)
git commit -m "Configured VLAN 100 on switch"

# 6ļøāƒ£ Status shows: All clean
git status
# nothing to commit, working tree clean

3. Essential Git Commands

3.1 Creating or Cloning a Repository

Two ways to get a repository:

šŸ“„ PowerShell
# Option A: Clone an existing repository
git clone https://gitlab.local/netzwerk/fabric-config.git
cd fabric-config

# Option B: Create a new repository
mkdir my-project
cd my-project
git init

3.2 Tracking Changes and Committing

The daily workflow:

šŸ“„ PowerShell
# Show status - what has changed?
git status

# Stage all changes for the next commit
git add .

# Or only specific files
git add fabric.yaml
git add configs/spine-1.yaml

# Or with wildcards
git add *.yaml

# Remove changes from the Staging Area (without deleting the file!)
git restore --staged fabric.yaml

# Create a commit with a meaningful message
git commit -m "Added VLAN 100 for production"

# Upload changes to the server
git push
šŸ’”Writing Good Commit Messages

The commit message should explain what and why something was changed:

āŒ Bad:
  • "Update"
  • "Fix"
  • "Changes"
  • "asdf"
āœ… Good:
  • "Added VLAN 100 for production servers"
  • "Configured BGP peer to ISP2 (AS65002)"
  • "Adjusted MTU to 9000 for jumbo frames"
  • "Fixed typo in Spine-1 hostname"

3.3 Fetching Changes from the Server

šŸ“„ PowerShell
# Fetch and integrate the latest changes from the server
git pull

# Only fetch information (without merging)
git fetch

# What has changed on the server?
git log origin/main --oneline -5
āš ļøPull before Push!

Before you git push, always git pull first! Otherwise you risk conflicts if someone else has pushed changes in the meantime.

4. Understanding Branching Strategies

Branches are like construction zones on a highway: Traffic (production) keeps flowing while you calmly work on the side. Only when the construction is done, the new lane is opened.

4.1 Creating and Switching Branches

šŸ“„ PowerShell
# List all branches
git branch

# Create a new branch
git branch feature/vlan-200

# Switch to a branch
git checkout feature/vlan-200

# OR: Create and switch at once (recommended!)
git checkout -b feature/vlan-200

# Newer alternative (from Git 2.23):
git switch -c feature/vlan-200

# Switch back to the main branch
git checkout main

# Delete a branch (after it has been merged)
git branch -d feature/vlan-200

# Force delete a branch (even without merge)
git branch -D feature/vlan-200

4.2 Branching Strategy: GitFlow vs. Trunk-Based

There are two common strategies for network teams. The choice depends on your team size and change frequency:

🌳 GitFlow

Multiple long-lived branches for different environments.

main ─────────────────────────
└── develop ────────────────
└── feature/vlan-200 ─
└── feature/bgp-peer ──
āœ… Advantages:
  • Clear separation: Dev/Test/Prod
  • Good for release cycles
  • Easy rollback
āŒ Disadvantages:
  • Complex with many branches
  • Long lifetimes = merge hell

šŸŽÆ Trunk-Based Development

One main branch, short-lived feature branches.

main ─────────────────────────
└── feature/vlan ─┐ (1-2 days)
└──────────
└── fix/typo ─┐ (hours)
└────────────
āœ… Advantages:
  • Simple and fast
  • Fewer merge conflicts
  • Ideal for CI/CD
āŒ Disadvantages:
  • Requires good tests
  • Feature flags sometimes needed
šŸ’”Recommendation for Network Teams

For most network teams, we recommend Trunk-Based Development:

  • Create a feature branch (max. 1-2 days lifetime)
  • Small, focused changes
  • Quick merge request + review
  • CI/CD pipeline validates automatically

GitFlow only makes sense if you have strict release cycles (e.g., monthly rollouts).

4.3 Branch Naming Conventions

Consistent names make collaboration easier:

Prefix
Usage
feature/
New features (feature/vlan-200)
bugfix/
Bug fixes (bugfix/wrong-subnet)
hotfix/
Urgent fixes for production
refactor/
Code improvements (refactor/yaml-structure)
docs/
Documentation changes

5. Understanding and Resolving Merge Conflicts

A merge conflict occurs when two people have changed the same line in the same file. Git cannot automatically decide which version is correct – you need to help.

5.1 How a Conflict Occurs

Situation:

Alice (main):        Bob (feature/vlan):
─────────────        ───────────────────
vlan_id: 100         vlan_id: 200     ← Same line!
name: Prod           name: Dev

When merging: šŸ’„ CONFLICT!
Git doesn't know: 100 or 200?

5.2 Detecting a Conflict

šŸ“„ PowerShell
# Attempt to merge
git merge feature/vlan-200

# Output on conflict:
# Auto-merging fabric.yaml
# CONFLICT (content): Merge conflict in fabric.yaml
# Automatic merge failed; fix conflicts and then commit the result.

# Status shows:
git status
# both modified: fabric.yaml

5.3 Conflict in the File

This is what a conflict looks like in the file:

šŸ“„ fabric.yaml
vlans:
<<<<<<< HEAD
  - id: 100
    name: Production
=======
  - id: 200
    name: Development
>>>>>>> feature/vlan-200

The Conflict Markers Explained:

  • <<<<<<< HEAD – Start of your current version (main)
  • ======= – Separator between the versions
  • >>>>>>> feature/vlan-200 – End of the other version

5.4 Resolving a Conflict

You have three options:

šŸ“„ fabric.yaml
# Option 1: Keep ONLY your version
vlans:
  - id: 100
    name: Production

# Option 2: Keep ONLY the other version
vlans:
  - id: 200
    name: Development

# Option 3: COMBINE both (usually the best solution!)
vlans:
  - id: 100
    name: Production
  - id: 200
    name: Development

After editing:

šŸ“„ PowerShell
# Conflict is resolved - stage the file
git add fabric.yaml

# Complete the merge
git commit -m "Merge feature/vlan-200: Keep both VLANs"

# Push
git push
šŸ’”Avoiding Conflicts
  • Small, focused commits (less overlap)
  • Regularly run git pull
  • Short branch lifetimes
  • Communicate with the team: "I'm working on fabric.yaml!"

6. Understanding Git History and Logs

Git history is your record of all changes. Used correctly, it answers questions like: "Who changed that?", "When was that introduced?" and "What was the reason?"

6.1 git log – Searching the History

šŸ“„ PowerShell
# Simple history (compact)
git log --oneline
# a1b2c3d Added VLAN 100
# d4e5f6g Configured BGP peer
# 7h8i9j0 Initial commit

# Last 5 commits with details
git log -5

# Nice graphical view
git log --oneline --graph --all

# Filter by author
git log --author="alice" --oneline

# Filter by date
git log --since="2024-01-01" --until="2024-01-31"

# Search by keyword in commit message
git log --grep="VLAN" --oneline

# Changes to a specific file
git log --oneline -- fabric.yaml

# With diff (what was changed?)
git log -p -2  # Last 2 commits with changes

6.2 git diff – Showing Differences

šŸ“„ PowerShell
# Unstaged changes vs. last version
git diff

# Staged changes vs. last version
git diff --staged

# Difference between two commits
git diff a1b2c3d d4e5f6g

# Difference between branches
git diff main feature/vlan-200

# Show only file names (not the content)
git diff --name-only main feature/vlan-200

# Changes to a specific file
git diff fabric.yaml

6.3 git blame – Who Wrote This Line?

The most powerful tool for debugging: Shows for each line who last changed it.

šŸ“„ PowerShell
# Blame for a file
git blame fabric.yaml

# Output:
# a1b2c3d (Alice  2024-01-15 10:30)  vlans:
# a1b2c3d (Alice  2024-01-15 10:30)    - id: 100
# d4e5f6g (Bob    2024-01-16 14:22)      name: Production  ← Bob changed this!
# 7h8i9j0 (Alice  2024-01-15 10:30)    - id: 200

# Only specific lines (10-20)
git blame -L 10,20 fabric.yaml

# Ignore whitespace changes
git blame -w fabric.yaml
šŸ’”Blame Without Blaming

Despite the name, git blame is not about assigning blame! It is a tool to find out who you can ask about the "why" of a change. That person best knows what they were thinking.

6.4 git show – Details About a Commit

šŸ“„ PowerShell
# Details of the last commit
git show

# Details of a specific commit
git show a1b2c3d

# Only the changed file names
git show --stat a1b2c3d

# Show a specific file from an old commit
git show a1b2c3d:fabric.yaml

6.5 Undoing Changes

šŸ“„ PowerShell
# Discard local changes (not staged)
git restore fabric.yaml

# Move staged changes back to Working Directory
git restore --staged fabric.yaml

# Undo last commit (keeps changes)
git reset --soft HEAD~1

# Completely delete last commit (changes gone!)
git reset --hard HEAD~1

# "Reverse" a commit (new commit that undoes the old change)
git revert a1b2c3d
# ā˜ļø Safe for shared branches! Creates a new commit.
āš ļøReset vs. Revert
  • git reset – Changes the history. Never use on shared branches!
  • git revert – Creates a new commit. Safe for shared branches.

Rule of thumb: Anything you have pushed, only undo with revert!

7. Hands-on Exercises

Now it gets practical! The following 6 exercises are split into two phases:

šŸ“‹ Phase 1: Local Git (Exercises 1-3)

Practice Git basics on the console – everything local on your desktop, no server needed.

🌐 Phase 2: GitLab Integration (Exercises 4-6)

Collaboration with GitLab – push, pull, merge requests and team workflows.

āš ļøāš™ļø One-Time Setup: Configure Git

Run these commands once in the PowerShell terminal:

šŸ“„ PowerShell
git config --global user.name "Your Name"
git config --global user.email "your.email@company.com"
git config --global http.sslVerify false

The last line is necessary because our GitLab server uses a self-signed SSL certificate.

āš ļøāš™ļø One-Time Setup: Configure Git

Run these commands once in the PowerShell terminal:

šŸ“„ PowerShell
git config --global user.name "Your Name"
git config --global user.email "your.email@company.com"
git config --global http.sslVerify false

The last line is necessary because our GitLab server uses a self-signed SSL certificate.

šŸ“‹ Phase 1: Local Git on the Console

šŸ”§Exercise 1: Create a Local Repository and Make First Commits (15 Min)

Create a local Git repository on the desktop and make your first commits.

  1. Open VS Code and start a terminal:

    Open VS Code via the desktop icon. Then open a terminal via the menu: Terminal → New Terminal (or keyboard shortcut Ctrl+`). A PowerShell terminal appears at the bottom where you can run all Git commands.

    VS Code with PowerShell terminal opened at the bottom: Terminal → New Terminal
    šŸ” Enlarge
    VS Code: Open terminal via Terminal → New Terminal
  2. Navigate to the desktop and create a folder:
    šŸ“„ PowerShell
    cd ~\Desktop
    mkdir git-exercise
    cd git-exercise
  3. Initialize a Git repository:
    šŸ“„ PowerShell
    git init
    
    # Explore the repository
    git status
    
    # Which branch? (should be main or master)
    git branch
  4. Open the folder in VS Code and create the first file:

    First, open the created folder in VS Code: File → Open Folder and navigate to Desktop\git-exercise. Click "Select Folder".

    Now you can see the empty folder in the sidebar on the left. Create a new file by clicking the šŸ“„ New File icon in the sidebar (or Ctrl+N) and save the file as vlans.yaml. Enter the following content:

    VS Code: git-exercise folder opened, create new file via the New File icon in the sidebar
    šŸ” Enlarge
    VS Code: Open folder and create a new file
    šŸ“„ vlans.yaml
    # VLAN configuration for my network
    vlans:
      - id: 100
        name: Production
        description: Production servers
    
      - id: 200
        name: Development
        description: Development environment
  5. Check status – file is "untracked":
    šŸ“„ PowerShell
    git status
    # Untracked files:
    #   vlans.yaml
  6. Stage and commit the file:
    šŸ“„ PowerShell
    git add vlans.yaml
    git status
    # Changes to be committed:
    #   new file: vlans.yaml (green!)
    
    git commit -m "Added VLAN configuration: Prod + Dev"
    
    # Success message:
    # [main abc1234] Added VLAN configuration: Prod + Dev
    #  1 file changed, 11 insertions(+)
  7. View the history:
    šŸ“„ PowerShell
    git log --oneline
    git log
āœ… Successful when: git log shows your first commit.
šŸ”§Exercise 2: Create Branches and Merge (15 Min)

Create a feature branch, work in it, and merge it back.

  1. Create a new branch:
    šŸ“„ PowerShell
    # Create branch AND switch to it
    git checkout -b feature/vlan-300
    
    # Check which branch we are on
    git branch
    # * feature/vlan-300
    #   master
  2. Make a change in the new branch:

    Open vlans.yaml in VS Code and add the following at the end:

    šŸ“„ vlans.yaml (add at the end)
    
      - id: 300
        name: Guests
        description: Guest network with internet access
  3. Commit:
    šŸ“„ PowerShell
    git add vlans.yaml
    git commit -m "Added VLAN 300 for guests"
  4. Switch back to the master branch and check:
    šŸ“„ PowerShell
    git checkout master
    
    # Check: VLAN 300 is NOT here yet!
    Get-Content vlans.yaml
  5. Merge the feature branch:
    šŸ“„ PowerShell
    git merge feature/vlan-300
    
    # Output:
    # Updating abc1234..def5678
    # Fast-forward
    #  vlans.yaml | 4 ++++
    #  1 file changed, 4 insertions(+)
  6. Check the result and clean up:
    šŸ“„ PowerShell
    # Now VLAN 300 is also in main!
    Get-Content vlans.yaml
    
    # Log shows the merge
    git log --oneline
    
    # Delete the feature branch
    git branch -d feature/vlan-300
āœ… Successful when: VLAN 300 is in the master branch and the feature branch has been deleted.
šŸ”§Exercise 3: Simulate and Resolve a Merge Conflict (20 Min)

This exercise simulates a real merge conflict – the most important exercise!

  1. Make sure you are on master:
    šŸ“„ PowerShell
    git checkout master
  2. Create Branch A – Alice sets MTU to 9000:
    šŸ“„ PowerShell
    git checkout -b feature/mtu-change-alice

    Create a new file interfaces.yaml in VS Code with the following content:

    šŸ“„ interfaces.yaml
    interfaces:
      Ethernet1:
        description: Uplink to Spine
        mtu: 9000
    šŸ“„ PowerShell
    git add interfaces.yaml
    git commit -m "Set MTU to 9000 (jumbo frames)"
  3. Switch back to master and create Branch B – Bob wants MTU 1500:
    šŸ“„ PowerShell
    git checkout master
    git checkout -b feature/mtu-change-bob

    Create the file interfaces.yaml in VS Code (it does not exist on this branch yet!) with the following content:

    šŸ“„ interfaces.yaml
    interfaces:
      Ethernet1:
        description: Uplink to Spine
        mtu: 1500
    šŸ“„ PowerShell
    git add interfaces.yaml
    git commit -m "Keep MTU at standard 1500"
  4. Merge Alice first (no problem):
    šŸ“„ PowerShell
    git checkout master
    git merge feature/mtu-change-alice
    # āœ… Fast-forward, all good
  5. Merge Bob → CONFLICT!
    šŸ“„ PowerShell
    git merge feature/mtu-change-bob
    
    # šŸ’„ CONFLICT (content): Merge conflict in interfaces.yaml
    # Automatic merge failed; fix conflicts and then commit.
    
    git status
    # both modified: interfaces.yaml
  6. View and resolve the conflict:

    Open interfaces.yaml in VS Code. You will see the conflict markers. VS Code offers buttons like "Accept Current Change", "Accept Incoming Change" or "Accept Both Changes". Choose MTU 9000 – remove the conflict markers and keep:

    šŸ“„ interfaces.yaml
    interfaces:
      Ethernet1:
        description: Uplink to Spine
        mtu: 9000
  7. Complete the merge:
    šŸ“„ PowerShell
    git add interfaces.yaml
    git commit -m "Merge: Keep MTU 9000 (jumbo frames required)"
  8. Clean up:
    šŸ“„ PowerShell
    git branch -d feature/mtu-change-alice
    git branch -d feature/mtu-change-bob
    
    # View the history with the merge
    git log --oneline --graph --all
āœ… Successful when: You understand how conflicts arise and are resolved!

🌐 Phase 2: GitLab Integration

ā„¹ļøGitLab Access

For the following exercises, you will use the GitLab server:

  • URL: https://198.18.133.100/
  • Username: root
  • Password: C1sco12345

āš ļø The browser will show a security warning (self-signed certificate). Click on "Advanced" → "Proceed to 198.18.133.100".

šŸ”§Exercise 4: Create a GitLab Project and Connect It (15 Min)

Create a project in GitLab and connect your local repository to it.

  1. Log into GitLab and create a new project:
    • Open https://198.18.133.100/ in the browser
    • Login with root / C1sco12345
    • Click on "New project" → "Create blank project"
    • Project name: netzwerk-config
    • Deactivate "Initialize repository with a README" (we already have a local repo!)
    • Click on "Create project"
  2. Connect local repository with GitLab:
    šŸ“„ PowerShell
    # Make sure you are in your local repo
    cd ~\Desktop\git-exercise
    
    # Add GitLab as remote
    git remote add origin https://198.18.133.100/gitlab-instance-668e631e/netzwerk-config.git
    
    # Check if remote is configured
    git remote -v
  3. Push local commits to GitLab:
    šŸ“„ PowerShell
    git push -u origin master
    
    # On the first push, you will be prompted for username and password:
    # Username: root
    # Password: C1sco12345
  4. Verify in GitLab:

    Switch to the browser and reload the project page. You should now see your files (vlans.yaml, interfaces.yaml) and all commits!

āœ… Successful when: Your files and commits are visible in GitLab.
šŸ”§Exercise 5: Working with GitLab – Push, Pull & Branches (15 Min)

Practice the workflow with GitLab: push changes and verify in the browser.

  1. Create a new branch and push a change:
    šŸ“„ PowerShell
    git checkout -b feature/bgp-config

    Create a new file bgp.yaml in VS Code with the following content:

    šŸ“„ bgp.yaml
    # BGP configuration
    bgp:
      local_as: 65001
      router_id: 10.0.0.1
      neighbors:
        - peer: 10.0.0.2
          remote_as: 65002
          description: ISP Uplink
    šŸ“„ PowerShell
    git add bgp.yaml
    git commit -m "Added BGP configuration for ISP uplink"
    
    # Push branch to GitLab
    git push -u origin feature/bgp-config
  2. Verify in GitLab:
    • Switch to GitLab in the browser
    • In the project, you can now see the branch feature/bgp-config
    • Click on the branch and see the bgp.yaml file
    • Check the history under "Repository → Commits"
  3. Switch back to master and merge:
    šŸ“„ PowerShell
    git checkout master
    git merge feature/bgp-config
    git push
    
    # Clean up
    git branch -d feature/bgp-config
    git push origin --delete feature/bgp-config
  4. Verify in GitLab:

    Reload the project page in GitLab. The bgp.yaml should now be visible in the master branch. The feature branch is deleted.

āœ… Successful when: bgp.yaml is visible in the master branch on GitLab and the feature branch is deleted.
šŸ”§Exercise 6: Create a Merge Request in GitLab (20 Min)

Create a Merge Request (MR) – the professional way to integrate changes. In real teams, changes are never merged directly, but always through an MR with review.

  1. Create a feature branch and make a change:
    šŸ“„ PowerShell
    git checkout -b feature/monitoring

    Create a new file monitoring.yaml in VS Code with the following content:

    šŸ“„ monitoring.yaml
    # Monitoring configuration
    monitoring:
      snmp:
        community: public
        version: 2c
        targets:
          - 10.0.0.1
          - 10.0.0.2
      syslog:
        server: 10.0.100.50
        port: 514
        level: informational
    šŸ“„ PowerShell
    git add monitoring.yaml
    git commit -m "Monitoring configuration: SNMP + Syslog"
    
    # Push branch to GitLab
    git push -u origin feature/monitoring
  2. Create a Merge Request in GitLab:
    • Switch to GitLab in the browser
    • GitLab shows a banner at the top: "Create merge request" – click on it
    • Alternatively: In the left menu "Merge requests" → "New merge request"
    • Source Branch: feature/monitoring
    • Target Branch: master
    • Title: Add monitoring configuration
    • Description: Adds SNMP and Syslog monitoring configuration
    • Click on "Create merge request"
  3. Review the Merge Request:
    • In the MR, you can see the "Changes" tab – all changes are visible here
    • You can add comments to individual lines (code review!)
    • The "Commits" tab shows all commits in this MR
  4. Merge the Merge Request:
    • Click the "Overview" tab at the top
    • Click the blue "Merge" button
    • Optional: Enable "Delete source branch" (recommended!)
    • After the merge, the change is in the master branch
  5. Update locally:
    šŸ“„ PowerShell
    git checkout master
    git pull
    
    # Check: monitoring.yaml should now be there
    dir
    Get-Content monitoring.yaml
    
    # Clean up the local branch
    git branch -d feature/monitoring
āœ… Successful when: The Merge Request is merged in GitLab and you have fetched the change locally with git pull.

8. Cheat Sheet & Troubleshooting

šŸ“‹ Git Cheat Sheet – Complete Overview

Basic Commands

git init
Create new repo
git clone <url>
Clone a repo
git status
Show status
git add .
Stage all changes
git add <file>
Stage a file
git commit -m "msg"
Create a commit
git push
Upload to server
git pull
Fetch from server

Branches

git branch
List branches
git branch <name>
Create a branch
git checkout <name>
Switch branch
git checkout -b <name>
Create + switch
git merge <branch>
Merge a branch
git branch -d <name>
Delete a branch

History

git log --oneline
Compact history
git log --graph
Graphical history
git diff
Show changes
git diff --staged
Staged changes
git blame <file>
Line-by-line author
git show <commit>
Commit details

Undoing Changes

git restore <file>
Discard local change
git restore --staged <file>
Unstage
git revert <commit>
Undo commit (safe!)
git reset --soft HEAD~1
Undo last commit
git reset --hard HEAD~1
āš ļø Commit + changes gone!

šŸ”„ Common Errors and Solutions

āŒ "fatal: not a git repository"

You are not in a Git folder.

āœ… cd C:\Users\admin\Desktop\git-exercise
āŒ "Your branch is behind origin/main"

Someone pushed changes that you do not have yet.

āœ… git pull
āŒ "error: failed to push some refs"

The server has newer commits than you.

āœ… git pull --rebase; git push
āŒ "You have unstaged changes"

You want to switch branches but have unsaved changes.

āœ… git stash; git checkout <branch>; git stash pop
āŒ "Merge conflict in ..."

Two changes to the same location.

āœ… Open file in VS Code, remove markers, git add, git commit
āŒ SSL certificate problem

Self-signed certificate on the GitLab server.

āœ… git config --global http.sslVerify false
āŒ Pushed a wrong commit!

A commit on the server needs to be undone.

āœ… git revert <commit-hash>; git push

āš ļø Do NOT use git reset on shared branches!

⚔ Save Time: Set Up Git Aliases

Run these commands in the PowerShell terminal to configure shortcuts:

šŸ“„ PowerShell
# Shortcuts
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit

# Pretty logs
git config --global alias.lg "log --oneline --graph --all"
git config --global alias.last "log -1 HEAD"

# Branch overview
git config --global alias.branches "branch -a"

# Who did what?
git config --global alias.who "shortlog -sne"

Usage: git st instead of git status, git lg for pretty logs, etc.

ā“ Quiz: Test Your Git Knowledge (5 Min)

Try to answer the questions without scrolling back.

1. What are the three zones of Git and what happens in each?

Show Answer

Working Directory: This is where you edit your files.
Staging Area: This is where you collect changes for the next commit (git add).
Repository: This is where commits are permanently stored (git commit).

2. What is the difference between git add and git commit?

Show Answer

git add moves changes to the Staging Area (preparation).git commit saves the contents of the Staging Area as a new snapshot in the repository.

3. Why should you write meaningful commit messages?

Show Answer

So that colleagues (and yourself in 6 months) can understand why a change was made. Good messages describe the "what" and "why", not the "how". Example: fix: Corrected VLAN 100 on Leaf-3 (wrong interface)

4. What does git log --oneline do?

Show Answer

Shows the commit history in compact form — one commit per line with a short hash and message. Ideal for a quick overview of the latest changes.

5. How can you undo a change that you have not yet committed?

Show Answer

With git checkout -- filename or git restore filename, the file is reset to the state of the last commit. Already staged changes must first be unstaged withgit restore --staged filename.

Summary

āœ… What You Learned

Concepts

  • ā˜‘ļø The three zones: Working Dir, Staging, Repository
  • ā˜‘ļø Branches as parallel development lines
  • ā˜‘ļø GitFlow vs. Trunk-Based Development
  • ā˜‘ļø How merge conflicts arise and are resolved

Practical Skills

  • ā˜‘ļø Create and explore a local repository
  • ā˜‘ļø Commit and push changes
  • ā˜‘ļø Create, switch, and merge branches
  • ā˜‘ļø Analyze history with log, diff, blame
  • ā˜‘ļø Detect and resolve conflicts
  • ā˜‘ļø GitLab: Push, Pull, Merge Requests
ā„¹ļøNext Steps

In the next module, you will learn about GitLab – the platform that extends Git with merge requests, CI/CD pipelines, and collaboration features. There, we will put together everything you have learned here!