The Art of Network Engineering
Join us as we explore the world of Network Engineering! In each episode, we explore new topics, talk about technology, and interview people in our industry. We peek behind the curtain and get insights into what it's like being a network engineer - and spoiler alert - it's different for everyone!
For more information check out our website https://artofnetworkengineering.com | Be sure to follow us on Twitter and Instagram as well @artofneteng | Co-Host Twitter Handle: Andy @andylapteff
The Art of Network Engineering
Fork Yeah! Git in Network Engineering
Network engineers have traditionally drawn a line between "our tools" and "developer tools," often rejecting powerful solutions that could dramatically improve our workflows. But what if we thought about tools the same way tradespeople do? A plumber wouldn't refuse to use a hammer just because it's "for carpenters" – so why do we resist Git?
In this eye-opening discussion, we explore how Git – the version control system created by Linux founder Linus Torvalds – can transform how network teams manage configurations, collaborate on changes, and maintain system history. Far from being "just for developers," Git provides elegant solutions to problems network engineers face daily.
Think about how many times you've emailed configuration files with names like "config_v2_final_REALLY_FINAL.txt" to your team, trying to track which version is current. As our guest William Collins puts it, "If you're versioning in the file name, you've already lost." Git eliminates this chaos by providing a structured approach to tracking changes that's actually remarkably similar to how routing protocols work – distributed nodes maintaining a consistent state through carefully managed updates.
We break down the differences between Git (the technology) and platforms like GitHub (commercial services built on Git), demonstrate how branching and pull requests can formalize peer review of network changes, and show why you don't need to understand every Git command to start benefiting from it today. Whether you're backing up configurations, collaborating on documentation, or building automation workflows, Git provides the structure and accountability that network operations desperately need.
Ready to stop emailing configurations and embrace a better way? Listen now to discover why Git isn't just for developers – it's for anyone who wants to work smarter.
Find everything AONE right here: https://linktr.ee/artofneteng
This is the Art of Network Engineering, where technology meets the human side of IT. Whether you're scaling networks, solving problems or shaping your career, we've got the insights, stories and tips to keep you ahead in the ever-evolving world of networking. Welcome to the Art of Network Engineering podcast. My name is Andy Laptev and I am joined on this episode by the one, the only, the amenable. No, that's not a word. My wife can't say abominable and I think it's adorable, and I can't say whatever amenable is, because it's not even a word. Colin Doyle, how you doing, sir? I'm well, how are you? Good? Good, I'm happy to have you here. And the other guy that you see on your screen or hear in your ears is William Collins returning. Hi, william, howdy, what's up? Howdy, what's up, what's up and how from kentucky kentucky what's up.
Speaker 1:indeed, we were just talking before we we started the recording about. So the this episode is going to be about git. Right, we're g-i-t. Git, git. I don't know if I'm saying it right. It's not get, it's git. Git is not git. Git is not GitHub. They are second cousins. It's GitHub without the hub. There you go, and that's the title of the episode GitHub without the hub. So before we jump into Git, what is it and why? Network engineers should care if we pop up a level real quick and we were just talking about this before we started I think it's interesting that in network engineering in general terms, we kind of segment like which tools are for what people.
Speaker 1:And an example that we were just talking about is I worked in the trades. I've been a plumber's helper, an electrician's helper, a carpenter's helper. And if you're in the trades, you have a broad set of tools that you use, because different things are going to come up and you're going to have use cases. You're going to want things to help you Like yes, you can still buy a saw like a hand saw, but hey, they came up with electric circular saws and isn't that nice and all the time you save and how much easier it makes your life. When I was an electric, when I was a plumber's helper, sometimes we would have to hang. They were like these metal hangers that you would put up and then hammer them into a floor joist and it would help support the weight of a pipe. And never once was I like screw that hammer and those carpenter's tools because I'm a plumber's helper In the trades.
Speaker 1:You wouldn't disqualify or just say these aren't for me, these are dumb. But for some reason in network engineering and I have been guilty of this well, software development tools aren't for me. That's not networking. I don't care if it's going to make my life easier. I don't care if it's going to make my workflows more efficient. I don't care if this is going to help me find the damn version of the document we're all trying to find in emails for the hundredth time. That's not for me. So what I'm hoping, moving forward, is we can do a bunch of these software development adjacent episodes, and even there I'm already doing the thing. I'm already calling them something else. These software development tools, no, they're tools for all of us. Plumbers can use hammers, carpenters can use pipes. So we want to talk about that for a brief moment before we get into Git. Have you guys experienced that? Have you traditionally been like that's not for me.
Speaker 3:I think that I love your analogy, because we were talking about this before you started recording. But it did dawn on me that I think the barriers to entry for somebody like myself, who is a traditional networking engineer, and a new innovative tool you're talking about cross-discipline tool sharing I'm looking at the saw and I'm thinking to myself the barrier to entry to picking up a saw and using it's pretty low because I can naturally understand what it is and how to use it just by looking at it. And then I have a bunch of examples around me that I've seen other people using saws. Now if somebody walked up to me with a CNC machine, I might be like, well, why do I need that? I got a saw and I know how to do it. Sure, it takes longer, but I'm more comfortable. I might be like, well, why do I need that? I got a saw and I know how to do it. Sure, it takes longer, but I'm more comfortable. That might. That analog might work a little bit more.
Speaker 3:Where you're looking at this new innovation or this different tool that has some complexity, you don't immediately understand how it's going to work and I'll say it, it's threatening. I consider myself a subject matter expert. And then there's this point where this is something new. I consider myself a subject matter expert. And then there's this point where this is something new and I'm thinking in the time it takes for me to learn this and get all the optimizations. I've been doing this for so long that it already takes me much, much less time to execute or do networking stuff than it did when I was a lowercase sc 20 years ago. So I think it's a good analog.
Speaker 2:I think it's come from a place too of it used to be very like. Basically, git is proliferate. It's almost like a part of a tool chain that is used across, like all technical verticals. There's like a singular tool chain that really drives the way that that teams do things now to to varying degrees, and I think network engineering as a trade was just well and security are kind of the slow ones to to pick it up. So I've been using it for a long time. So I I started based on purely curiosity, like in I don't know, maybe to 2010 or something I can't remember, maybe before that, and I used it originally for not the right reason. So I had a set of files used to call them like dot files, and I basically use Git as a backup. I didn't have branching or anything. I just cloned down and bootstrapped my Linux developer environment and that was my whole original purpose, and then it just kind of morphed over time.
Speaker 3:I was going to ask, but I think you kind of answered it when you started using Git. I assume that most people are going to come to it in one of two ways they're either going to try it out as a tool for themselves, or they're going to be forced into its use because they're going to be connected to a team or project that's using it. And I believe what you were saying is that you decided to just use it as a useful tool and, humorously, use it completely incorrectly in hindsight. Yep, uh, for your own purposes, just cloud backup, backup, basically Easy cloud backup for files.
Speaker 2:This is a long time ago though, and if you look at what it I don't want to go off on a tangent here but why does it even exist? It's kind of something that you have to sort of piece through before you get into any detail. If you ask anybody, they're like okay, it's just a distributed version control system. Okay, I've heard that a thousand times. So what does that actually mean?
Speaker 2:Let's start with distributed, as in like, shared amongst many places, people and systems, and then version control, meaning it was designed not the way I used it originally, but it was designed to track changes in source code or, really technically, any set of files over time. And thinking about this right now, it's kind of funny because I've been using Git and Linux in my professional life since a long time ago, and Linux especially much farther back, and both of these technologies and I think this is important to understand is they came from the same person, Linus Tarvolts. You can't understand, I don't think, the purpose of Git without going back a little further and looking at the origins of Linux just a little bit. So I don't know if you'd want to dig in on that a little bit.
Speaker 1:I would like to dig into that. But right before we dig into that, I just want to make a comment. Something happened to my brain when you said track changes in source code, and I think this is part of the problem and there's probably cognitive biases in there somewhere. As soon as you said source code, my brain was like nope, not for me, not my tool Go away. I don't even know what source code is. So I'm just saying this out loud. I'm saying the embarrassing thing out loud, because when I hear terms that I don't feel have anything to do with me, my career, my life, my job, I think my brain disqualifies the tool wholesalely, which is unfortunate, which is probably why I'm at the point of my career and life where I'm still trying to figure out what the hell git is.
Speaker 3:So just to be aware, if you're not a software operator why should you care about source code?
Speaker 2:think about it, but it goes beyond. That was the original yep use, but now configuration files exactly. So I wanted sorts of different stuff.
Speaker 1:I wanted to build that bridge, like, just because you said it's the track changes in source code, you can track changes and other things like configuration. So don't tune out like I just did. I'm trying to pull my brain back in and anybody else's whose brain also turned off. So let's, let's go down your, your linux, linux, torvald path's funny.
Speaker 2:So Linus started working on Linux I think like early, maybe late 80s, early 90s, somewhere around that time, and he was like a comp sci student, just I think, university of Helsinki in Finland. And this was basically born from, like Linus getting incredibly irritated at only like commercial Unix offerings at the time being available. They had to like run on certain hardware like yada yada, yada. So he decides, hey, I want to run stuff on my own hardware that meets my creative thinking and tinkering, because I'm an ultra nerd. So if you look at like what has happened since he came and sort of built Linux, it's changed, kind of changed. The world Powers the internet. It's really flipped the script on proprietary software. It's democratized software development, like how you actually build software, and it dominates mobile and embedded systems.
Speaker 2:So fast forward to the early 2000s, I guess. And the Linux kernel project has grown to epic proportions. We're talking like hundreds, if not thousands, contributing worldwide. I don't know the number, but there was existing tools at the time that were used to version control the software. And speaking of open source and licensing issues that have been in the news recently, I think it was actually like a licensing dispute, if I'm not mistaken, they basically saw Linus, who is now well known to not really mess around with inefficiency he's inefficiency sort of focused to basically build his own version control system tailored specifically for the growth in the scale of the Linux kernel project.
Speaker 2:I could be wrong on this. I read this at some point a while back, but I think the original version of Git. He actually cobbled together like on a Saturday and a Sunday, like on a long weekend, basically. Git he actually cobbled together like on a Saturday and a Sunday, like on a long weekend basically, and with the goal of keeping Linux kernel dev moving fast without the reliance on anyone else's software. So that's how Git was born. It's kind of a crazy origin story, if you ask me.
Speaker 3:I like how he throws together foundational programming tools on the weekend, the same way I throw together breakfast like what's in here. You're right for one he is I. I had the opportunity to see him speak and once at an intel conference 20 some years ago, and when you mentioned that he I don't how'd you put it?
Speaker 3:like sufficiency, doesn't like optimization somebody, efficiency somebody stood up and asked him a straight up comic con type question where, like this bug and this thing, linus straight cursed the guy out. He's like why would you waste everybody? It was just, he was very spicy, it was, it was fun.
Speaker 2:Oh, he's spicy. Known for the spice he's.
Speaker 3:I think what the the light bulb moment that I had with Git was when I viewed it, when it finally clicked that within the open source community there has to be a method for allowing free and open development, but also review, because if you're doing development on code that already exists, that development is going to go one of three ways it's going to go in the bin. That development is going to go one of three ways it's going to go in the bin. It's going to be something that a community feels contributes sufficient value to the original project that it will become a part of that project and ultimately, the people that are doing development could be owners of the project, they could be people that are using the project, but there still has to be this co-development space in order for the community to thrive the way that it does. Or you've created something new and unique, and that is where I think the magic of GitHub or Git, I should say, and GitHub. They do become analogous in my head. I got to get over that.
Speaker 3:But the way Git works is really innovative, and that is that it allows you to take a project and then clone that project, so you have a local copy and then dork around with the project and then either it's yours and you can just run with what you have, or and this is, I think, where people's brains start to fold you can do a pull request, which makes it feel like you're grabbing something and bringing it back in, but in fact what you're doing is you are opening up the changes that you've made for review and revision and potentially merging back into the branch, and that's when you look at the way that projects work and, visualized, it almost looks like the way you might show evolution from one point to many things. It doesn't even need to be that complex like you were doing. It could also just be me doing version control right. I just need to make sure that if I screw something up this week, I can go back to what I had last week.
Speaker 2:You mentioned a really a point that I like to differentiate between and I think you sort of did with that blurb but the Git and GitHub, git and GitLab, like these these are like confused, so much, like so. So back to Linus being the creative genius and advocate for freedom, yada, yada yada that he is, he chose to license Git under like a true open source general public version to licensing, so making it okay, it's free to use, study, modify, share, hack, whatever you want to do with it. That's one of the reasons Git caught fire and basically became the default standard for, like, best practice, software development patterns, yada yada. This led to commercial offerings to the audience.
Speaker 2:Github, gitlab these are commercial offerings that are basically built atop the functionality of Git is the underlying technology. So GitHub it is a cloud-hosted service that basically takes Git's functionality and extends it and it adds like some social and collaborative layers on top. So you can think of it like Git being the underlying tech, with GitHub being that nice garage that you park your or Andy parks his Ferrari and tunes it and then shows it off to people, if that makes sense.
Speaker 3:Well, we have Git as a part of the tooling and some of the solutions that we have at Nokia, and I won't. This isn't going to turn into a sales or marketing thing, but when I present on that and I talk about it, I try to make it clear that the reason I'm mentioning that we're using Git isn't because you have to be familiar with Git. It's a way of signaling that we are using a baked in well-understood, well-known tool to do, in the case that I'm thinking of, of specifically configuration, version control. So it's not that you have to understand how that works. It's more of a statement on the maturity of the tool itself. Have confidence Now, to the extent that you want to interact with it the way that you interact with Git, you can do that, but you also don't have to. Either way. The fact that we can use it within these commodities, these tools that we build and sell that's exactly what you're talking about. It has sort of become de facto standard for that.
Speaker 2:So to put this back in the context- I just said something that go ahead, andy, sorry.
Speaker 1:Well, no, no, no, real quick. So I'm always trying to tie this back to network engineering, because I get kind of lost in the sauce. So what did you say? Configuration, management, configuration, version control, whatever it is.
Speaker 1:So, here's my question, because I have not used the extent of my Git. Experience has been like pulling down a repo. Why, I don't know, because something on Google told me to once because I needed a thing right, but I didn't make any changes, I didn't do a pull request, I basically just so. This is something you have to install locally, I believe, and these are some of the steps I want to walk through in a moment. But you have to install it locally. You need a GitHub account, which I guess is a repository, like you said, online.
Speaker 1:But to pull it back to networking, so when I was in production I would have a config in a router, let's say, or a switch, and maybe I had to make a change, maybe I had to add a prefix to a prefix list to allow some routing through. I would do it in the CLI, via notepad and all that stuff. Are you telling me that, like, can we change configurations and production devices by using Git, github, ci, cd pipelines? Like, how does all this magic tie together? Like, does it still work that way, or are we not talking about switch configurations? This is something not related.
Speaker 2:So it's not actually making changes, it's just storing and building. It's like a backup. So I almost want to like go on a rant here, so tying it back to network engineering like one way to think about it. Like, when you think of, like you, I think you could loosely compare Git to like a routing table, so distributed state management. It's an interesting thing the way Git works. It really isn't too far removed from network devices and routing tables.
Speaker 2:Git is fundamentally distributed. Every repo that you clone contains the full history of all the changes that have ever happened. For that thing, there's no single centralized server that everyone is going to rely on. So developers can work offline, they can commit changes locally and then later they're going to sync everything up. And if you think of like routing tables, routing protocols like BGP or OSPF, they maintain this distributed table across routers. Like each router gets its own view of the network topology and updates. It gets updated and that's based on the information shared by peers.
Speaker 2:Like Git, there's no centralized truth. The system converges through collaboration of sorts. So both rely on this decentralized nodes, that kind of share, and reconcile information to maintain a coherent system state. So when you get into change tracking, git tracks changes only it doesn't actually make changes to network devices, it just keeps track of that state via something like you all said, commits, and this is snapshots of the project state tied together in a DAG, pretty much. So when you push or pull, changes propagate between repositories and merge and reconcile the differences. So you can kind of think about routing tables as they evolve as the network conditions change. Take link failures or a route map or a policy update that triggers routers to exchange updates, like these updates propagate through the network and routers adjust their tables to reflect their new reality. So, but I guess what I'm trying to say is like both systems log into, distribute incremental updates, ensuring that all participants eventually align and have this consistent view.
Speaker 1:So if we have a golden config that I want to change, what I usually do is email people on my team and say, hey, can you review this thing? I need a peer review. Could I do that and get instead, Could I pull the repo which is the golden config for this device? Could I branch it and propose a change which is my prefix list change? Could that kick off some kind of review process? So instead of someone reviewing source code, they're reviewing my config revision and then approve it and then so, even though it doesn't push it for me, can I use that as a peer review for configs I want to change? Does that make sense?
Speaker 2:Well, human hands are going to be involved. So if you think, like what you just said is actually a really good segue, I don't want to get like too far into like a branching strategy, but basically for like you're talking about this new task or this new thing you're doing, so you would actually create. Basically, you have the main branch that is usually going to be tied back to production. Main is always production, mirrors, production, yada, yada, yada.
Speaker 2:But usually when you get just a little more mature, this isn't to the level of developing software for whatever, some big hyperscale company, but you usually have some sort of integration branch call it develop or pre-prod or something, and that's how you're going to fully test and get everything ready before you do that shift to main. When you're actually doing work, though those small tasks that you're talking about, you're going to create usually what's called a feature branch and you create that branch off of that developer pre-production branch or call it an integration branch. And that's the work that you pre-production branch or call it like an integration branch, and that's the work that you're going to test, tinker around with, commit your changes, add a nice thoughtful comment and then eventually, when you're done and you got things working. You're going to merge your local branch that you've created from develop.
Speaker 2:You're going to merge that back with develop and then eventually it's going to work its way up to production and and usually the way it works is like the integration branch and the the main branch have controls around them to where only certain things and certain triggers and certain tests complete everything and there's usually human. You can actually actually add approvers, sign commits, there's all sorts of security and controls you can put around how code is actually updated through this process. But it's usually a combination of all those things and you usually do have someone like if you do a pull request, you're going to have a set of approvers, they're going to look at it. It's usually some sort of consensus, like I need these three approvers, or maybe I need three approvers but there's like 20 people in the approvers list. So as long as one of three of those 20 people approve it, then it can actually complete that pull request and merge, if that makes sense.
Speaker 1:I don't know if you can see it happening, but I'm fighting my brain this whole time because this all sounds like software development and my brain is like not for us, not for me, not relevant. I don't know if in the 10 minutes we have left, we could go through some like how can you use this in network engineering? Because I think it's for automation. I'm not sure. I think we said that it's for, like, version control, network configurations, but I'm still not clear on that because we talked about that and I'm still confused. Dummy network engineer guy like how, how is Git helpful? For me? It's version control. I install it locally. We do things in the cloud with GitHub. I don't know what the hell GitLab is. That'll be another episode. It's awesome.
Speaker 3:Well, let me take a swing at maybe answering a top line question for some network engineers, and that is if I have a team, if I'm using this scenario where I need to take inputs or we're doing config changes, why would I use Git instead of something else? And one thing you benefit from whenever you use a tool like this is that there is a pre-baked process. There's structure. You might already be within a process that's already defined and this might feel like a lift. It is well-known enough that most folks you're going to interact with they're going to be familiar with it, but nothing else. It creates, built right into how Git functions, a methodology for creating local copies of configurations and making changes and then submitting those changes to a group that has been defined by someone else for review and either acceptance, rejection it's called a merge. We can merge it together. We can merge. We can merge it together. We can replace, we can branch it off. There's a lot of functionality within.
Speaker 3:Git that day-to-day a network operator is not going to interact with, and that's fine. You could use Git to iterate on images if you wanted to. It is simply a link in the chain of maintaining continuity of information, and this is one of the things that I constantly struggle with when I'm working with cohorts really any company that is. Somebody sends me an attachment of a Word document or a PowerPoint presentation in an email and I'm like I'm not touching that.
Speaker 1:That's just where I was going with it.
Speaker 3:I make changes and I have a local copy and there's no methodology to maintain how all these changes are working. That's just where I was going with it. Document is that if I'm working, I might have multiple copies of that Word document and I might need to either merge those into one there might be value in me branching one off and this is now. There's two separate documents and they each have value, but it's different value. So for a network operator, let's say that I have an automation to backup configurations. It is a very simple log into the box, run a command. I could use an API, but let's just make this really meat and potatoes right. It's a script. It's going to interact with the box. It's going to run a command in user space. It's going to spit out a file. Where does that file go?
Speaker 3:Now, I've certainly had that file and this is a scenario I've done. It goes on a server, somewhere in a directory, and then there might be an overwrite. There might be a crontab that periodically flushes things that are older, whatever, but it goes somewhere. If I were to incorporate Git into that workflow, it would just be an extra bit of automation where that file would get backed up. It would have to go somewhere, unless I could script on the box that it would go into Git, but then it could upload into Git and then Git becomes both.
Speaker 3:This repository has version control. It also gives people the ability to go in and this is kind of what makes it somewhat unique to go in and pull configurations and look at them, review them, have a local copy, maybe play with them in a lab. It is just formalizing some storage and collaborative working workflows that we've had historically is formalizing them with a bit of structure, and I think that where I consider the value in a networking sense, there's benefit in that structure, because if you have a method, if you have structure, you're going to cut down on the likelihood of misalignment between versions, and just having the rules already in place by virtue of the tool you're using can be super helpful.
Speaker 2:That's a really good. I love that because one thing if you're a network engineer, like, why do you think you should care about Git? What do network operators actually care about? So they care about complexity, they care about uptime. Hopefully, they care about making consistent and auditable changes. So in 2025, in our world, there's not a more powerful tool to underpin these principles than Git. So if you take a little time and if you've learned all the CLIs of all the different things, like most network engineers have, putting some of that time into Git not that hard, not that bad.
Speaker 3:Go on, Git.
Speaker 2:Do it. I think honestly a next episode or something in the future. It would be cool to do like a screen share and actually demonstrate some of the things we've talked about today. I would like to do.
Speaker 1:I would like to do a lot of hands on with this kind of stuff that so they always you always hear, like, with automation at least, like, find a use case. And, as Colin was talking about the attach word document that everybody's sharing and trying to figure out, I'm going through that right now at work. I'm collaborating with my team. We're doing edits for something that we're going to publish and we're already trying to figure out. Well, which version are we on. Is it the one with underscore Andy, or underscore whoever? Is it V2, v3? It's in the email that everybody's on that I asked somebody to look at. But, like, can you send me the current?
Speaker 3:You've already lost. If you're versioning in the file name, you've already lost and that's what I did and we all did.
Speaker 1:In these really big production environments Like here's the spreadsheet with the VLANs or here's the whatever right and which version are we on? For me, my use case at the moment is at work, like in my day-to-day. I want to leverage a technology that can stop the nightmare of which version is current and where is it. And oh, I have to download it locally because it's in the email they're on but I can't download it. So let me download it and send it, because when I try to hit the share thing in Office 365, it's not working because of a permission. I just want Git. I want it all in a repo.
Speaker 1:That sounds so much cleaner to me and easier. I just want my life to be easier and be more efficient, and this sounds like it'll do that for me right.
Speaker 3:And the next rung on the ladder because it's a common tool is integration. Where you have a network, the network is going to have network tools attached to it, like an IPAM server that's doing DHCP tracking clients. When I say tracking, it's just it has a database that's making sure that when we have network information that's assigned to an identity, that we're tracking that identity relationship. Once you have something like GitHub that is broadly understood and integrated, you now not only are backing up configs, that becomes a data source that these other network tools can now touch. And every time you have something that's more formalized like that through an integration, it's work you as a network admin don't have to do manually and beyond that, maybe build something new. So I think that if you've never used GitHub before, the best way to interact with it is to do what I did go to and I said GitHub again.
Speaker 3:But GitHub offers a tutorial that will show you how to use Git and get familiar with the GH command, the Git command. They are discreet and they have different. I created a text file that's literally a cheat sheet that I still use. But just walk through the tutorial and get a sense for some of the four, five, six basic commands. Honestly, there's a ton of stuff there. You're not gonna have to use most of it. I've done EVPN trainings where I'm, like the guide's, 2,500 pages long. Let me spend three minutes telling you what you need to know, because ultimately, you don't need to know most of this for day-to-day and Git is no different Guys.
Speaker 1:Thank you so much for this introduction to Git. I think that we could probably spend hours and hours on this, so I'm hoping, as we move forward with the show in 2025, that we can do more like these. I would love to get you guys on again and maybe we could do that screen share, walkthrough and some real use case, almost like labbing. I think for me that would help kind of solidify some of these topics.
Speaker 1:And the biggest thing I've learned in my life and even in my career. Like, content prior to investigation is no good For me to say that tool is not for me because I'm not a software developer. But then say that tool is not for me because I'm not a software developer, but then I have conversations with smart guys like you and I'm like, oh, this would make my life easier today in a problem I'm having at work. That, by the way, has nothing to do with network engineering or coding, but here is a tool that can help me. So thanks for coming on, guys, Thanks for the intro to Git. We will hopefully have a follow up where we get a little deeper and do some labbing and some I'm going to branch and merge and pull and dev and it's going to be awesome. It's going to be amazing.
Speaker 2:I'm going to be a killer soon.
Speaker 1:For all things. Art of network engineering you can check out our link tree. It's link tree forward slash. Art of net Our discord server it's all about the journey is there, which is a great community store. I've been blogging lately so I hope you're enjoying the content and the shows. Where can folks find you to find if they want to reach out and ask you about Git or anything else?
Speaker 3:Oh you go, William. I'm a ghost in the shadows. You're not going to find me online yet.
Speaker 2:William hyphen Collins LinkedIn, twitter or X Twitter, whatever. W Collins 502. I am on blue sky. I forgot my username and the cloud gambit dot com. Listen Apple podcasts. Wherever you get your podcasts, give it five stars, even if you don't listen. That's what I always really like.
Speaker 1:Colin, people can't find you anywhere. You're not even on the LinkedIn.
Speaker 3:Oh, okay, you're going to find me on LinkedIn, cdoyle-pdx, and I have a YouTube channel that I put very little content into because I just started Nokia within the last six months and I've been busy with stuff Yet another networking channel, so you can find me there. I have an EVPN video up and I show how to make a Christmas delight, which is was a lot of fun to do.
Speaker 1:Reach out to them. These guys are smart, they're awesome, they're cool. Thanks so much for listening. We'll catch you next time on the Art of Network Engineering podcast. Hey folks, if you like what you heard today, please subscribe to our podcast and your favorite podcatcher. You can find us on socials at Art of NetEng, and you can visit linktree. Forward slash Art of NetEng for links to all of our content, including the A1 merch store and our virtual community on Discord called it's All About the Journey. You can see our pretty faces on our YouTube channel named the Art of Network Engineering. That's youtubecom. Forward slash Art of NetEng. Thanks for listening.
