{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreidu6f43yfphrkwitl63ci7cgqgxwlxvcz4tx3lltdehgibtuk75ri",
"uri": "at://did:plc:yamgjp3fq22zggtm5g7ply4n/app.bsky.feed.post/3meqmeeydnag2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreic7smrrvxbtptaswwzwvfs4nr2ws5ur5sgwey6zs22rxj5lrkfuce"
},
"mimeType": "image/webp",
"size": 36936
},
"description": "Time to get practical. Set up Git, version control your network configs, learn branching and merging the hard way (by breaking things), and open your first pull request on GitHub.",
"path": "/git-in-practice-version-control-for-network-engineers/",
"publishedAt": "2026-02-13T13:28:24.000Z",
"site": "https://artofinfra.com",
"tags": [
"last post",
"Git Bash",
"VS Code",
"github.com",
"WSL",
"git-scm.com",
"Git Cheat Sheet - General CommandsWe’ve created a handy list and PDF cheat sheet of the most useful Git CLI commands covering the basics, branching, merging, rebasing, and more. Yours to keep as a quick reference for everyday tasks.Art of InfraDan Jones",
"SSH",
"Join Now",
"README",
"branches",
"Starship",
"Part 1",
"Part 3: Git Mastery for Network Engineers"
],
"textContent": "In the last post, we covered _why_ version control matters and some of the key concepts behind Git. We didn't touch a terminal. That changes now!\n\nThis is the hands-on section. By the end, you'll have Git installed, a repository created, branches worked with, a merge conflict resolved, and your first pull request opened on GitHub. Every example uses network config files because that's the world we work in.\n\nIn the next post, we go deeper into Git and version control with an _optional_ **Git Mastery** section. We'll go through some more advanced features, the \"why and when\" to use certain commands, and some more complex scenarios.\n\n**Let's get to it!**\n\n* * *\n\n## Prerequisites\n\nYou'll need three things:\n\nA machine to work on with either Linux, macOS, or Windows. If you're on Windows, I'd recommend using WSL (Windows Subsystem for Linux) to follow along, but Git Bash works too. I'll be using macOS.\n\nA text editor. VS Code is the go-to for most and is what we'll be making use of (as well as some Nano), but anything works. Nano, Vim, Sublime, whatever you're comfortable with.\n\nA GitHub account. If you don't have one, head to github.com and sign up. The free tier is all we'll need. GitHub is the most popular platform for devs and open-source projects.\n\n🧠\n\nVS Code and other editors have built-in Git support, but understanding the terminal commands underneath matters. When things break, the GUI won't save you; the CLI will.\n\n### Installing Git\n\n**Linux (Debian/Ubuntu):**\n\n\n sudo apt update && sudo apt install git -y\n\n\n**macOS:**\n\n\n # If you have Homebrew, highly recommend it.\n brew install git\n\n # Or just run 'git' in terminal, macOS will prompt to install Xcode CLI tools which includes Git\n\n\n**Windows (WSL):**\n\nIf you're running WSL, follow the Linux instructions above. If you're not using WSL, download Git from git-scm.com.\n\nVerify it's installed:\n\n\n git --version\n # git version 2.43.0 (or similar)\n\n\nGit Cheat Sheet - General CommandsWe’ve created a handy list and PDF cheat sheet of the most useful Git CLI commands covering the basics, branching, merging, rebasing, and more. Yours to keep as a quick reference for everyday tasks.Art of InfraDan Jones\n\n### Initial Configuration\n\nBefore you do anything with Git, you need to tell it who you are. This information gets attached to every commit you make.\n\n\n git config --global user.name \"Your Name\"\n git config --global user.email \"your.email@example.com\"\n # You can set your git email and name per repo, or globally, like above.\n\nUse the same email you signed up to GitHub with, this is how GitHub links commits to your account.\n\nSome other sensible defaults while we're here:\n\n\n # Set the default editor (VS Code in this case). Recommended.\n git config --global core.editor \"code --wait\"\n\n # Set the default branch name to 'main'. This will be default in Git v3.0.\n git config --global init.defaultBranch main\n\nYou can check your config at any time:\n\n\n git config --list\n\n\n### Setting Up SSH Authentication for GitHub\n\nYou _can_ use HTTPS to connect to GitHub, but SSH is cleaner and easier in the long run. No typing passwords every time you push. Let's set it up once and forget about it.\n\n**Generate an SSH key:**\n\n\n ssh-keygen -t ed25519 -C \"your.email@example.com\"\n\n\nHit enter to accept the default file location. Add a passphrase if you want (recommended), or leave it blank.\n\n**Start the SSH agent and add your key:**\n\n\n eval \"$(ssh-agent -s)\"\n ssh-add ~/.ssh/id_ed25519\n\n\n**Copy your public key:**\n\n\n cat ~/.ssh/id_ed25519.pub\n\n\nCopy the entire output.\n\n**Add it to GitHub:**\n\nGo to GitHub > Settings > SSH and GPG keys > New SSH key. Give it a name (like \"Home Laptop\"), paste the key, and save.\n\n**Test the connection:**\n\n\n ssh -T git@github.com\n # Hi username! You've successfully authenticated...\n\n\nDone. You won't need to think about this again.\n\n* * *\n\n## Your First Repository\n\nLet's create a repo that simulates managing network device configurations. This is the kind of thing you'd realistically use Git for day one.\n\n**Create the project directory and initialise Git:**\n\n\n mkdir network-configs\n cd network-configs\n git init\n\n\nYou'll see:\n\n\n Initialized empty Git repository in /your-directory/network-configs/.git/\n\n\nThat `.git` folder is where Git stores everything. Don't touch it, just know it's there. If you're on Linux, Mac or WSL, you can use `ls -al` to view the hidden folder.\n\n**Create your first config file:**\n\n\n mkdir configs\n\n\nCreate a file called `configs/core-sw01.cfg` with the following example content:\n\n\n ! core-sw01 - Core Switch 01\n ! Site: London DC\n !\n hostname core-sw01\n !\n vlan 10\n name MANAGEMENT\n vlan 20\n name SERVERS\n vlan 30\n name USERS\n !\n interface Vlan10\n description Management VLAN\n ip address 10.0.10.1 255.255.255.0\n !\n interface Vlan20\n description Server VLAN\n ip address 10.0.20.1 255.255.255.0\n !\n interface Vlan30\n description User VLAN\n ip address 10.0.30.1 255.255.255.0\n !\n ip default-gateway 10.0.10.254\n !\n line con 0\n logging synchronous\n line vty 0 4\n transport input ssh\n !\n end\n\n\n**Check the status:**\n\n\n git status\n\n\n\n On branch main\n\n No commits yet\n\n Untracked files:\n (use \"git add <file>...\" to include in what will be committed)\n \tconfigs/\n\n nothing added to commit but untracked files present (use \"git add\" to track)\n\n\nGit sees the file but isn't tracking it yet. This is an important point, **Git doesn't automatically track everything** in the folder. You choose what to include.\n\n**Stage and commit:**\n\n\n git add configs/core-sw01.cfg\n git commit -m \"Add initial config for core-sw01\"\n\n\n\n [main (root-commit) a1b2c3d] Add initial config for core-sw01\n 1 file changed, 34 insertions(+)\n create mode 100644 configs/core-sw01.cfg\n\n\nThat's your first commit. Let's break down what just happened.\n\n💡\n\nYou can also use `git add .` to add all files to the staging area, instead of manually adding the files you wish to be part of the next commit.\n\n`git add` moves the file into the **staging area**. Think of this as a \"ready to commit\" zone. You can stage multiple files and commit them together as one logical change.\n\n`git commit -m` creates the snapshot with a message describing what you did.\n\n**View the history:**\n\n\n git log\n\n\n\n commit bcd39c8 (HEAD -> main)\n Author: Your Name <your.email@example.com>\n Date: Tue Feb 10 02:50:21 2026 +0000\n\n Add initial config for core-sw01\n\n\nOne commit, one entry. As you make more changes, this log grows and becomes your audit trail.\n\nFor a more compact view:\n\n\n git log --oneline\n\n\n\n a1b2c3d (HEAD -> main) Add initial config for core-sw01\n\n\nthe Aoi discord community\n\nJoin our new ****Discord community**** where we discuss everything; infra, networking, cloud, AI and much more. Come vent, discuss tech problems, or just have a place to hang out with like-minded individuals.\n\n\n Join Now\n \n\n## Making Changes and Tracking Them\n\nNow let's make some changes. You've been asked to add a new VLAN for a guest wireless network.\n\nOpen `configs/core-sw01.cfg` and add the following after the existing VLAN definitions:\n\n\n vlan 40\n name GUEST_WIFI\n\n\nAnd add a new interface section:\n\n\n interface Vlan40\n description Guest WiFi VLAN\n ip address 10.0.40.1 255.255.255.0\n\n\nBefore committing, let's see what Git thinks has changed:\n\n\n git status\n\n\n\n On branch main\n Changes not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n \tmodified: configs/core-sw01.cfg\n\n\nWant to see the actual changes?\n\n\n git diff\n\n\n\n @@ -9,6 +9,8 @@ vlan 20\n name SERVERS\n vlan 30\n name USERS\n +vlan 40\n + name GUEST_WIFI\n !\n interface Vlan10\n description Management VLAN\n @@ -22,6 +24,10 @@ interface Vlan30\n description User VLAN\n ip address 10.0.30.1 255.255.255.0\n !\n +interface vlan40\n + description Guest WiFi VLAN\n + ip address 10.0.40.1 255.255.255.0\n +!\n ip default-gateway 10.0.10.254\n\n\nLines starting with `+` are additions. Lines with `-` are removals. This is the same format you'll see in pull requests on GitHub. Get used to reading diffs, it's one of the most useful skills in Git (albeit made easier when using the GitHub GUI later).\n\nStage and commit:\n\n\n git add configs/core-sw01.cfg\n git commit -m \"Add VLAN 40 for guest WiFi network\"\n\n\nCheck the log:\n\n\n git log --oneline\n\n\n\n b2c3d4e (HEAD -> main) Add VLAN 40 for guest WiFi network\n a1b2c3d Add initial config for core-sw01\n\n\nTwo commits in the books with a clear history, you can see exactly what changed and when.\n\n## Setting Up .gitignore\n\nBefore we go further, let's talk about files you _don't_ want in Git. There's always going to be stuff in your project directory that shouldn't be tracked; credentials, temporary files, IDE settings, lab-specific files, poem(s) to your loved one.\n\nBy telling Git what to ignore, these files and directories will never be tracked or pushed to remote(s).\n\nCreate a `.gitignore` file in the root of your repo:\n\n\n # Credentials and secrets\n *.key\n *.pem\n secrets/\n .env\n\n # Editor and IDE files\n .vscode/\n\n # OS files\n .DS_Store\n Thumbs.db\n\n # Lab and temp files\n *.bak\n *.tmp\n lab-notes/\n\n\nCommit it:\n\n\n git add .gitignore\n git commit -m \"Add .gitignore for credentials, temp files, and IDE settings\"\n\n\nThis is one of those things that's easy to forget early on and a pain to fix later, especially if you accidentally commit a private key. Once something's in Git history, it's there. Removing it later is a headache you don't want. Set up `.gitignore` early.\n\n## Connecting to GitHub\n\nWe've been working locally so far. Let's push this to GitHub so it's backed up and shareable.\n\n**Create a new repository on GitHub:**\n\nGo to GitHub > New Repository. Give it a name (e.g., `network-configs`), leave description empty, no README, no `.gitignore`, no license. We already have content locally. Visibility; we can leave on public, since the work we're doing isn't private nor contain anything sensitive. _Public means the anyone can view this project (ideal for open-source projects) whereas Private is limited to you and your team._\n\n💡\n\nA README file is the primary documentation file in a repository, serving as the introduction for users and developers. It acts as a guide, outlining what the project does, how to install it, and how to use it.\n\nWe won't be creating one in this demo, but feel free to have a go at creating one yourself later.\n\n**Link your local repo to GitHub:**\n\nUpon creation of your repo in GitHub, you'll receive instructions/ commands on how to set it up with your username and such. Copy the git remote add line.\n\n\n git remote add origin git@github.com:yourusername/network-configs.git\n\nThis tells Git \"there's a remote copy of this repo at this address, call it `origin`.\"\n\n**Push your commits:**\n\n\n git push -u origin main\n\n\nThe `-u` flag sets `origin main` as the default upstream, so future pushes just need `git push`.\n\nHead to your repo on GitHub. You'll see your config file, your commits, your history, all there!\n\nClick the commits link:\n\nCheck out and compare the differences in configuration between each commit.\n\nLook at that! We're doing things!\n\n## Working with Branches\n\nHere's where it gets interesting and where Git starts paying for itself on real projects. Let's say, for example, you've been asked to implement a new QoS policy, but you want to develop and test it without affecting the known-good config on `main`. Well this is where branches come in.\n\n**Create and switch to a new branch:**\n\n\n git switch -c feature/qos-policy\n\n\n\n Switched to a new branch 'feature/qos-policy'\n\n\nYou're now on a separate branch. Any changes you make here won't affect `main`.\n\nIf at anytime you need to check which branch you're on, use the command `git branch`. A little `*` will show next to your working branch.\n\n_Or be me and install_ Starship_on Mac and customise your shell;_\n\nYes, I'm up at 3am writing this on a Monday.\n\nCreate a new file called `configs/qos-policy.cfg`:\n\n\n ! QoS Policy - Core Network\n !\n class-map match-any VOICE\n match dscp ef\n match dscp cs5\n !\n class-map match-any VIDEO\n match dscp af41\n match dscp cs4\n !\n class-map match-any NETWORK-CONTROL\n match dscp cs6\n match dscp cs7\n !\n policy-map WAN-EDGE-OUT\n class VOICE\n priority percent 10\n class VIDEO\n bandwidth percent 30\n class NETWORK-CONTROL\n bandwidth percent 5\n class class-default\n bandwidth percent 55\n random-detect\n !\n\n\nStage and commit:\n\n\n git add configs/qos-policy.cfg\n git commit -m \"Add WAN edge QoS policy for voice and video traffic\"\n\n\nNow switch back to `main`:\n\n\n git switch main\n\n\nLook in your `configs/` directory, you'll notice `qos-policy.cfg` isn't there. It only exists on the `feature/qos-policy` branch. Switch back and it reappears:\n\n\n git switch feature/qos-policy\n ls configs/\n # core-sw01.cfg qos-policy.cfg\n\n\nWatch how the file disappears and reappears in the explorer navigation to the left as we switch branches.\n\nThis is the power of branches. You can have multiple pieces of work in progress without them interfering with each other.\n\n## Merging a Branch\n\nYou're happy with the QoS policy, right? Time to bring it into `main`!\n\n**Switch to the branch you want to merge _into_ :**\n\n\n git switch main\n\n\n**Merge:**\n\n\n git merge feature/qos-policy\n\n\n\n Updating c4f589f..42960a7\n Fast-forward\n configs/qos-policy.cfg | 25 +++++++++++++++++++++++++\n 1 file changed, 25 insertions(+)\n create mode 100644 configs/qos-policy.cfg\n\n\nThe QoS config is now on `main`. Git did a \"fast-forward\" merge here because there were no conflicting changes; it just moved `main` forward to include the new commits.\n\n⚡\n\nA fast-forward merge is a way of integrating changes where the main branch pointer (HEAD) is simply moved forward to the latest commit of a feature branch. We'll explain fast-forward merges, HEAD and more in the next post.\n\n**Clean up the branch:**\n\n\n git branch -d feature/qos-policy\n\n\nGood practice is to delete branches once they're merged. Keep your home in order!\n\n**Push changes to remote (GitHub):**\n\n\n git push origin main\n # or use 'git push' since we set the remote earlier.\n\n## Infrastructure worth reading about\n\nPractical takes on networking, cloud, and automation from someone who actually runs the gear. No fluff, no vendor pitches.\n\nSign me up\n\nEmail sent! Check your inbox to complete your signup.\n\nNo spam. Unsubscribe anytime.\n\n## Dealing with Merge Conflicts\n\nMerge conflicts sound intimidating, but they're just Git saying \"two changes touched the same lines, and I need you, _a human_ , to decide which one wins\". Let's deliberately create one so you know how to handle it.\n\n**Set up the scenario, two branches modifying the same ACL:**\n\nFirst, create an ACL file on `main`:\n\n\n # Make sure you're on main\n git switch main\n\n\nCreate `configs/acl-vlan10.cfg`:\n\n\n ! ACL for VLAN 10 Management Access\n !\n ip access-list extended MGMT-ACCESS\n permit tcp 10.0.10.0 0.0.0.255 any eq 22\n permit tcp 10.0.10.0 0.0.0.255 any eq 443\n deny tcp any any log\n !\n\n\nAdd and commit the new file:\n\n\n git add configs/acl-vlan10.cfg\n git commit -m \"Add management ACL for VLAN 10\"\n\n\n**Now simulate two engineers making different changes:**\n\nEngineer A creates a branch and adds SNMP access:\n\n\n git switch -c feature/add-snmp-access\n\n\nEdit `configs/acl-vlan10.cfg` , add a new permit line before the deny:\n\n\n permit udp 10.0.10.0 0.0.0.255 any eq 161\n\n\nSo the ACL section now looks like:\n\n\n ip access-list extended MGMT-ACCESS\n permit tcp 10.0.10.0 0.0.0.255 any eq 22\n permit tcp 10.0.10.0 0.0.0.255 any eq 443\n permit udp 10.0.10.0 0.0.0.255 any eq 161\n deny tcp any any log\n\n\n\n # Make sure you're on the add-snmp-access branch - `git branch`\n git add configs/acl-vlan10.cfg\n git commit -m \"Add SNMP access to management ACL\"\n\n\n**Engineer B makes a different change on another branch:**\n\n\n git switch main\n git switch -c feature/add-icmp-access\n\n\nEdit `configs/acl-vlan10.cfg` , add an ICMP permit before the deny:\n\n\n # Remember, the changes we made earlier are on another branchs, so do not appear here.\n\n permit icmp 10.0.10.0 0.0.0.255 any\n\n\nSo this version looks like:\n\n\n ip access-list extended MGMT-ACCESS\n permit tcp 10.0.10.0 0.0.0.255 any eq 22\n permit tcp 10.0.10.0 0.0.0.255 any eq 443\n permit icmp 10.0.10.0 0.0.0.255 any\n deny tcp any any log\n\n\n\n git add configs/acl-vlan10.cfg\n git commit -m \"Add ICMP access to management ACL\"\n\n\nSwitching between all three branches shows the differences.\n\n**Now merge both into main:**\n\n\n git switch main\n git merge feature/add-snmp-access\n # This works fine, fast-forward merge\n\n\n\n git merge feature/add-icmp-access\n # CONFLICT!\n\n\n\n Auto-merging configs/acl-vlan10.cfg\n CONFLICT (content): Merge conflict in configs/acl-vlan10.cfg\n Automatic merge failed; fix conflicts and then commit the result.\n\n\n**Don't panic!** Open the file now and you'll see something like this:\n\n\n ip access-list extended MGMT-ACCESS\n permit tcp 10.0.10.0 0.0.0.255 any eq 22\n permit tcp 10.0.10.0 0.0.0.255 any eq 443\n <<<<<<< HEAD\n permit udp 10.0.10.0 0.0.0.255 any eq 161\n =======\n permit icmp 10.0.10.0 0.0.0.255 any\n >>>>>>> feature/add-icmp-access\n deny tcp any any log\n\n\nGit is showing you both versions. Everything between `<<<<<<< HEAD` and `=======` is what's currently on `main` (the SNMP line from the first merge). Everything between `=======` and `>>>>>>> feature/add-icmp-access` is the incoming change.\n\n💡\n\nIn Git, HEAD is ****a reference to the current commit on the currently checked-out branch****. It represents the tip of the branch, pointing to the latest commit you're working on. HEAD can be thought of as the \"current branch marker\" or the pointer to the active branch.\n\n**In this case, we want both.** Edit the file to remove the conflict markers and keep both lines:\n\n\n ip access-list extended MGMT-ACCESS\n permit tcp 10.0.10.0 0.0.0.255 any eq 22\n permit tcp 10.0.10.0 0.0.0.255 any eq 443\n permit udp 10.0.10.0 0.0.0.255 any eq 161\n permit icmp 10.0.10.0 0.0.0.255 any\n deny tcp any any log\n\n\n**Mark it as resolved and commit:**\n\n\n git add configs/acl-vlan10.cfg\n git commit -m \"Merge ICMP access - resolve conflict with SNMP addition\"\n\n\nThat's it. Conflict resolved. In the real world, most conflicts are this straightforward: two people added something in the same place and you just need to combine them sensibly.\n\n**Clean up:**\n\n\n git branch -d feature/add-snmp-access\n git branch -d feature/add-icmp-access\n\n\n**Push changes to remote (GitHub):**\n\n\n git push origin main\n\nFrom here, running the below command will give you a visual overview of the different branches and _how they came to be one_.\n\n\n git log --oneline --graph --decorate --all\n\n## Pull Requests - The GitHub Workflow\n\nSo far, we've been merging locally. In a team environment (and even when working solo), **pull requests** (PRs) are a better workflow (I should really practice what I preach). A PR is like saying \"I've made changes on a branch, please review them before they go into main\".\n\nThis ties back to the change management scenario from Part 1. PRs give you review, approval, discussion, and an audit trail, all built in.\n\n**Let's walk through it.**\n\nCreate a new branch and make a change:\n\n\n git switch -c feature/ntp-config\n\n\nCreate `configs/ntp.cfg`:\n\n\n ! NTP Configuration - All Devices\n !\n ntp server 10.0.10.10 prefer\n ntp server 10.0.10.11\n ntp source Vlan10\n ntp authenticate\n ntp authentication-key 1 md5 NTPsecure123\n ntp trusted-key 1\n !\n\n\nAdd and commit this new file:\n\n\n git add configs/ntp.cfg\n git commit -m \"Add NTP configuration with authentication\"\n\n\n**Push the branch to GitHub:**\n\n\n git push origin feature/ntp-config\n\n\n**Now go to GitHub.** You'll see a banner saying \"feature/ntp-config had recent pushes\" with a \"Compare & pull request\" button. Click it.\n\nGive the PR a meaningful title and description:\n\n * **Title:** Add NTP configuration with authentication\n * **Description:** Adds NTP config pointing to our management VLAN time servers (10.0.10.10 and 10.0.10.11) with MD5 authentication enabled. This will be applied to all network devices.\n\n\n\nClick \"Create pull request\"\n\nOn the PR page, you can see the diff (exactly what changed), leave comments on specific lines, request reviews from team members, and have a discussion before anything touches `main`.\n\nOnce you're happy (or once your reviewer approves), hit \"Merge pull request\" on GitHub. You'll get an option to delete the branch on GitHub. You can delete this branch since it won't be used again.\n\nWithin your repo in GitHub, if you select the \"Commits\" button again, you should now see the merge of the PR.\n\nThen clean up locally:\n\n\n git switch main\n git pull origin main\n git branch -D feature/ntp-config\n\n\n`git pull` fetches the merged changes from GitHub. Your local `main` is now up to date.\n\n👨💻\n\nIf you were to use just `git pull` , an error will flag stating there is no tracking information. This is because of Git not being aware of what branch in the remote maps to what branch locally.\nTo fix this, run `git branch --set-upstream-to=origin/main main` and try `git pull` again, or use the command we have in the code block above.\n\nUsing `-D` (uppercase, rather than lowercase) is because of the local repo does not have awareness that the local branch has been merged into main in GitHub. Using a `-d` here will throw out an error, prompting you to use `-D` to force delete the branch.\n\n* * *\n\n## Useful Commands for Day-to-Day Work\n\nHere's a handful of commands that you'll use constantly once Git is part of your workflow.\n\nGit Cheat Sheet - General CommandsWe’ve created a handy list and PDF cheat sheet of the most useful Git CLI commands covering the basics, branching, merging, rebasing, and more. Yours to keep as a quick reference for everyday tasks.Art of InfraDan Jones\n\nAlso a nifty cheat sheet for your perusal.\n\n**See what's changed (before staging):**\n\n\n git diff\n\n\n**See what's staged (before committing):**\n\n\n git diff --staged\n\n\n**Compact commit history:**\n\n\n git log --oneline\n\n\n**See history with a branch graph:**\n\n\n git log --oneline --graph --all\n\n\nThis is useful when multiple branches are in play. You get a visual representation of how branches diverge and merge.\n\n**Temporarily shelve your work:**\n\n\n # You're mid-change but need to switch branches urgently\n git stash\n\n # Come back later\n git stash pop\n\n\n`git stash` is like a quick save. It takes your uncommitted changes, stores them, and gives you a clean working directory. `git stash pop` brings them back.\n\nWe'll dive further into this in the next post.\n\n**Check which branch you're on:**\n\n\n git branch\n\n\nThe one with the asterisk `*` is your current branch.\n\n**Discard changes to a file (before staging):**\n\n\n git checkout -- configs/core-sw01.cfg\n\n\nThis resets the file to the last committed version. Useful when you've made changes and want to start over. Be careful , this is destructive and can't be undone.\n\n* * *\n\n## Quick Recap, The Workflow\n\nHere's the day-to-day Git workflow in a nutshell: the loop you'll repeat constantly:\n\n 1. **Pull** latest changes: `git pull`\n 2. **Branch** for your change: `git switch -c feature/your-change`\n 3. **Make** your changes\n 4. **Stage** them: `git add <files>`\n 5. **Commit** with a clear message: `git commit -m \"What and why\"`\n 6. **Push** to GitHub: `git push`\n 7. **Open a PR** , get it reviewed, merge\n 8. **Clean up** : switch back to main, pull, delete the branch.\n\n\n\nThat's the entire cycle. It becomes second nature quickly.\n\n* * *\n\n## What's Next\n\nYou now have _working_ knowledge of Git, enough to start using it for real projects. You can track configs, collaborate with branches, handle conflicts, and use pull requests for proper change management.\n\nIn the next post (completely optional), we go deeper into Git and version control with **Git Mastery**. We'll go through some more advanced features, the \"why and when\" to use certain commands, and some more complex scenarios.\n\nThe configs you write, the automation scripts you build, the Terraform files you'll create later, they all live in Git. This is the foundation.\n\n* * *\n\nPart 3: Git Mastery for Network Engineers",
"title": "Git in Practice - Version Control For Network Engineers",
"updatedAt": "2026-02-14T12:12:26.574Z"
}