April 9, 2025 • 30 mins
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
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
This is the Art of Network Engineering, where
technology meets the human sideof IT.
Whether you're scaling networks, solving problems or shaping
your career, we've got theinsights, stories and tips to
keep you ahead in theever-evolving world of
networking.
Welcome to the Art of NetworkEngineering podcast.
My name is Andy Laptev and I amjoined on this episode by the
(00:21):
one, the only, the amenable.
No, that's not a word.
My wife can't say abominableand 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 youhere.
And the other guy that you seeon your screen or hear in your
ears is William Collinsreturning.
(00:42):
Hi, william, howdy, what's up?
Howdy, what's up, what's up andhow from kentucky kentucky
what's up.
indeed, we were just talkingbefore we we started the
recording about.
So the this episode is going tobe about git.
Right, we're g-i-t.
Git, git.
I don't know if I'm saying itright.
It's not get, it's git.
Git is not git.
(01:03):
Git is not GitHub.
They are second cousins.
It's GitHub without the hub.
There you go, and that's thetitle of the episode GitHub
without the hub.
So before we jump into Git,what is it and why?
Network engineers should careif we pop up a level real quick
and we were just talking aboutthis before we started I think
it's interesting that in networkengineering in general terms,
(01:26):
we kind of segment like whichtools are for what people.
And an example that we were justtalking 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 differentthings are going to come up and
you're going to have use cases.
You're going to want things tohelp you Like yes, you can still
(01:47):
buy a saw like a hand saw, buthey, they came up with electric
circular saws and isn't thatnice and all the time you save
and how much easier it makesyour life.
When I was an electric, when Iwas a plumber's helper,
sometimes we would have to hang.
They were like these metalhangers that you would put up
and then hammer them into afloor joist and it would help
support the weight of a pipe.
And never once was I like screwthat hammer and those
(02:10):
carpenter's tools because I'm aplumber's helper In the trades.
You wouldn't disqualify or justsay these aren't for me, these
are dumb.
But for some reason in networkengineering and I have been
guilty of this well, softwaredevelopment tools aren't for me.
That's not networking.
I don't care if it's going tomake my life easier.
I don't care if it's going tomake my workflows more efficient
.
I don't care if this is goingto help me find the damn version
(02:30):
of the document we're alltrying to find in emails for the
hundredth time.
That's not for me.
So what I'm hoping, movingforward, is we can do a bunch of
these software developmentadjacent episodes, and even
there I'm already doing thething.
I'm already calling themsomething else.
These software developmenttools, no, they're tools for all
of us.
Plumbers can use hammers,carpenters can use pipes.
(02:52):
So we want to talk about thatfor a brief moment before we get
into Git.
Have you guys experienced that?
Have you traditionally beenlike that's not for me.
Speaker 3 (03:06):
I think that I love your analogy, because we were
talking about this before youstarted recording.
But it did dawn on me that Ithink the barriers to entry for
somebody like myself, who is atraditional networking engineer,
and a new innovative toolyou're talking about
cross-discipline tool sharingI'm looking at the saw and I'm
thinking to myself the barrierto entry to picking up a saw and
using it's pretty low because Ican naturally understand what
(03:29):
it is and how to use it just bylooking at it.
And then I have a bunch ofexamples around me that I've
seen other people using saws.
Now if somebody walked up to mewith a CNC machine, I might be
like, well, why do I need that?
I got a saw and I know how todo it.
Sure, it takes longer, but I'mmore comfortable.
I might be like, well, why do Ineed that?
I got a saw and I know how todo it.
Sure, it takes longer, but I'mmore comfortable.
That might.
That analog might work a littlebit more.
Where you're looking at this newinnovation or this different
(03:52):
tool that has some complexity,you don't immediately understand
how it's going to work and I'llsay it, it's threatening.
I consider myself a subjectmatter expert.
And then there's this pointwhere this is something new.
I consider myself a subjectmatter expert.
And then there's this pointwhere this is something new and
I'm thinking in the time ittakes for me to learn this and
get all the optimizations.
I've been doing this for solong that it already takes me
(04:16):
much, much less time to executeor do networking stuff than it
did when I was a lowercase sc 20years ago.
So I think it's a good analog.
Speaker 2 (04:22):
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 atool chain that is used across,
like all technical verticals.
There's like a singular toolchain that really drives the way
that that teams do things nowto to varying degrees, and I
think network engineering as atrade was just well and security
(04:43):
are kind of the slow ones to topick it up.
So I've been using it for along time.
So I I started based on purelycuriosity, like in I don't know,
maybe to 2010 or something Ican't remember, maybe before
that, and I used it originallyfor not the right reason.
So I had a set of files used tocall them like dot files, and I
(05:04):
basically use Git as a backup.
I didn't have branching oranything.
I just cloned down andbootstrapped my Linux developer
environment and that was mywhole original purpose, and then
it just kind of morphed overtime.
Speaker 3 (05:16):
I was going to ask, but I think you kind of answered
it when you started using Git.
I assume that most people aregoing to come to it in one of
two ways they're either going totry it out as a tool for
themselves, or they're going tobe forced into its use because
they're going to be connected toa team or project that's using
it.
And I believe what you weresaying is that you decided to
just use it as a useful tool and, humorously, use it completely
(05:38):
incorrectly in hindsight.
Yep, uh, for your own purposes,just cloud backup, backup,
basically Easy cloud backup forfiles.
Speaker 2 (05:45):
This is a long time ago though, and if you look at
what it I don't want to go offon a tangent here but why does
it even exist?
It's kind of something that youhave to sort of piece through
before you get into any detail.
If you ask anybody, they'relike okay, it's just a
distributed version controlsystem.
Okay, I've heard that athousand times.
So what does that actually mean?
(06:05):
Let's start with distributed, asin like, shared amongst many
places, people and systems, andthen version control, meaning it
was designed not the way I usedit originally, but it was
designed to track changes insource code or, really
technically, any set of filesover time.
And thinking about this rightnow, it's kind of funny because
(06:26):
I've been using Git and Linux inmy professional life since a
long time ago, and Linuxespecially much farther back,
and both of these technologiesand I think this is important to
understand is they came fromthe same person, Linus Tarvolts.
You can't understand, I don'tthink, the purpose of Git
without going back a littlefurther and looking at the
origins of Linux just a littlebit.
(06:47):
So I don't know if you'd wantto dig in on that a little bit.
Speaker 1 (06:50):
I would like to dig into that.
But right before we dig intothat, I just want to make a
comment.
Something happened to my brainwhen you said track changes in
source code, and I think this ispart of the problem and there's
probably cognitive biases inthere 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 sourcecode is.
So I'm just saying this outloud.
(07:12):
I'm saying the embarrassingthing out loud, because when I
hear terms that I don't feelhave anything to do with me, my
career, my life, my job, I thinkmy brain disqualifies the tool
wholesalely, which isunfortunate, which is probably
why I'm at the point of mycareer and life where I'm still
trying to figure out what thehell git is.
Speaker 3 (07:32):
So just to be aware, if you're not a software
operator why should you careabout source code?
Speaker 2 (07:37):
think about it, but it goes beyond.
That was the original yep use,but now configuration files
exactly.
So I wanted sorts of differentstuff.
Speaker 1 (07:46):
I wanted to build that bridge, like, just because
you said it's the track changesin source code, you can track
changes and other things likeconfiguration.
So don't tune out like I justdid.
I'm trying to pull my brainback 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 (08:03):
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 scistudent, just I think,
university of Helsinki inFinland.
And this was basically bornfrom, like Linus getting
incredibly irritated at onlylike commercial Unix offerings
at the time being available.
They had to like run on certainhardware like yada yada, yada.
(08:26):
So he decides, hey, I want torun stuff on my own hardware
that meets my creative thinkingand tinkering, because I'm an
ultra nerd.
So if you look at like what hashappened since he came and sort
of built Linux, it's changed,kind of changed.
The world Powers the internet.
It's really flipped the scripton proprietary software.
It's democratized softwaredevelopment, like how you
(08:48):
actually build software, and itdominates mobile and embedded
systems.
So fast forward to the early2000s, I guess.
And the Linux kernel projecthas grown to epic proportions.
We're talking like hundreds, ifnot thousands, contributing
worldwide.
I don't know the number, butthere was existing tools at the
time that were used to versioncontrol the software.
(09:10):
And speaking of open source andlicensing issues that have been
in the news recently, I thinkit was actually like a licensing
dispute, if I'm not mistaken,they basically saw Linus, who is
now well known to not reallymess around with inefficiency
he's inefficiency sort offocused to basically build his
own version control systemtailored specifically for the
(09:30):
growth in the scale of the Linuxkernel project.
I could be wrong on this.
I read this at some point awhile back, but I think the
original version of Git.
He actually cobbled togetherlike on a Saturday and a Sunday,
like on a long weekend,basically.
Git he actually cobbledtogether like on a Saturday and
a Sunday, like on a long weekendbasically, and with the goal of
(09:51):
keeping Linux kernel dev movingfast without the reliance on
anyone else's software.
So that's how Git was born.
It's kind of a crazy originstory, if you ask me.
Speaker 3 (09:56):
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 seehim speak and once at an intel
conference 20 some years ago,and when you mentioned that he I
(10:18):
don't how'd you put it?
like sufficiency, doesn't likeoptimization somebody,
efficiency somebody stood up andasked him a straight up comic
con type question where, likethis bug and this thing, linus
straight cursed the guy out.
He's like why would you wasteeverybody?
It was just, he was very spicy,it was, it was fun.
Speaker 2 (10:38):
Oh, he's spicy.
Known for the spice he's.
Speaker 3 (10:40):
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 communitythere has to be a method for
allowing free and opendevelopment, but also review,
because if you're doingdevelopment on code that already
exists, that development isgoing to go one of three ways
(11:02):
it's going to go in the bin.
That development is going to goone of three ways it's going to
go in the bin.
It's going to be something thata community feels contributes
sufficient value to the originalproject that it will become a
part of that project andultimately, the people that are
doing development could beowners of the project, they
could be people that are usingthe project, but there still has
to be this co-development spacein order for the community to
(11:23):
thrive the way that it does.
Or you've created something newand unique, and that is where I
think the magic of GitHub orGit, I should say, and GitHub.
They do become analogous in myhead.
I got to get over that.
But the way Git works is reallyinnovative, and that is that it
allows you to take a project andthen clone that project, so you
(11:46):
have a local copy and then dorkaround with the project and
then either it's yours and youcan just run with what you have,
or and this is, I think, wherepeople's brains start to fold
you can do a pull request, whichmakes it feel like you're
grabbing something and bringingit back in, but in fact what
you're doing is you are openingup the changes that you've made
(12:06):
for review and revision andpotentially merging back into
the branch, and that's when youlook at the way that projects
work and, visualized, it almostlooks like the way you might
show evolution from one point tomany things.
It doesn't even need to be thatcomplex like you were doing.
It could also just be me doingversion control right.
(12:26):
I just need to make sure thatif I screw something up this
week, I can go back to what Ihad last week.
Speaker 2 (12:30):
You mentioned a really a point that I like to
differentiate between and Ithink 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 thecreative genius and advocate for
freedom, yada, yada yada thathe is, he chose to license Git
under like a true open sourcegeneral public version to
(12:53):
licensing, so making it okay,it's free to use, study, modify,
share, hack, whatever you wantto do with it.
That's one of the reasons Gitcaught fire and basically became
the default standard for, like,best practice, software
development patterns, yada yada.
This led to commercialofferings to the audience.
Github, gitlab these arecommercial offerings that are
basically built atop thefunctionality of Git is the
(13:15):
underlying technology.
So GitHub it is a cloud-hostedservice that basically takes
Git's functionality and extendsit and it adds like some social
and collaborative layers on top.
So you can think of it like Gitbeing the underlying tech, with
GitHub being that nice garagethat you park your or Andy parks
his Ferrari and tunes it andthen shows it off to people, if
(13:38):
that makes sense.
Speaker 3 (13:40):
Well, we have Git as a part of the tooling and some
of the solutions that we have atNokia, and I won't.
This isn't going to turn into asales or marketing thing, but
when I present on that and Italk about it, I try to make it
clear that the reason I'mmentioning that we're using Git
isn't because you have to befamiliar with Git.
It's a way of signaling that weare using a baked in
(14:01):
well-understood, well-known toolto do, in the case that I'm
thinking of, of specificallyconfiguration, version control.
So it's not that you have tounderstand how that works.
It's more of a statement on thematurity of the tool itself.
Have confidence Now, to theextent that you want to interact
with it the way that youinteract with Git, you can do
that, but you also don't have to.
Either way.
(14:22):
The fact that we can use itwithin these commodities, these
tools that we build and sellthat's exactly what you're
talking about.
It has sort of become de factostandard for that.
Speaker 2 (14:30):
So to put this back in the context- I just said
something that go ahead, andy,sorry.
Speaker 1 (14:34):
Well, no, no, no, real quick.
So I'm always trying to tiethis back to network engineering
, because I get kind of lost inthe sauce.
So what did you say?
Configuration, management,configuration, version control,
whatever it is.
So, here's my question, becauseI have not used the extent of my
Git.
Experience has been likepulling down a repo.
Why, I don't know, becausesomething on Google told me to
(14:54):
once because I needed a thingright, but I didn't make any
changes, I didn't do a pullrequest, I basically just so.
This is something you have toinstall locally, I believe, and
these are some of the steps Iwant to walk through in a moment
.
But you have to install itlocally.
You need a GitHub account,which I guess is a repository,
like you said, online.
But to pull it back tonetworking, so when I was in
production I would have a configin a router, let's say, or a
(15:15):
switch, and maybe I had to makea change, maybe I had to add a
prefix to a prefix list to allowsome routing through.
I would do it in the CLI, vianotepad 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 magictie together?
Like, does it still work thatway, or are we not talking about
(15:38):
switch configurations?
This is something not related.
Speaker 2 (15:41):
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 ona rant here, so tying it back to
network engineering like oneway to think about it.
Like, when you think of, likeyou, I think you could loosely
compare Git to like a routingtable, so distributed state
management.
It's an interesting thing theway Git works.
It really isn't too far removedfrom network devices and
(16:04):
routing tables.
Git is fundamentally distributed.
Every repo that you clonecontains the full history of all
the changes that have everhappened.
For that thing, there's nosingle 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 tosync everything up.
And if you think of likerouting tables, routing
(16:26):
protocols like BGP or OSPF, theymaintain this distributed table
across routers.
Like each router gets its ownview of the network topology and
updates.
It gets updated and that'sbased on the information shared
by peers.
Like Git, there's no centralizedtruth.
The system converges throughcollaboration of sorts.
So both rely on thisdecentralized nodes, that kind
(16:50):
of share, and reconcileinformation to maintain a
coherent system state.
So when you get into changetracking, git tracks changes
only it doesn't actually makechanges to network devices, it
just keeps track of that statevia something like you all said,
commits, and this is snapshotsof the project state tied
together in a DAG, pretty much.
(17:11):
So when you push or pull,changes propagate between
repositories and merge andreconcile the differences.
So you can kind of think aboutrouting tables as they evolve as
the network conditions change.
Take link failures or a routemap or a policy update that
triggers routers to exchangeupdates, like these updates
(17:32):
propagate through the networkand routers adjust their tables
to reflect their new reality.
So, but I guess what I'm tryingto say is like both systems log
into, distribute incrementalupdates, ensuring that all
participants eventually alignand have this consistent view.
Speaker 1 (17:46):
So if we have a golden config that I want to
change, what I usually do isemail 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 thisdevice?
Could I branch it and propose achange which is my prefix list
change?
Could that kick off some kindof review process?
So instead of someone reviewingsource code, they're reviewing
my config revision and thenapprove it and then so, even
(18:09):
though it doesn't push it for me, can I use that as a peer
review for configs I want tochange?
Does that make sense?
Speaker 2 (18:15):
Well, human hands are going to be involved.
So if you think, like what youjust said is actually a really
good segue, I don't want to getlike too far into like a
branching strategy, butbasically for like you're
talking about this new task orthis new thing you're doing, so
you would actually create.
Basically, you have the mainbranch that is usually going to
be tied back to production.
Main is always production,mirrors, production, yada, yada,
yada.
(18:35):
But usually when you get just alittle more mature, this isn't
to the level of developingsoftware for whatever, some big
hyperscale company, but youusually have some sort of
integration branch call itdevelop or pre-prod or something
, and that's how you're going tofully test and get everything
ready before you do that shiftto main.
When you're actually doing work, though those small tasks that
(18:57):
you're talking about, you'regoing to create usually what's
called a feature branch and youcreate that branch off of that
developer pre-production branchor call it an integration branch
.
And that's the work that youpre-production branch or call it
like an integration branch, andthat's the work that you're
going to test, tinker aroundwith, commit your changes, add a
nice thoughtful comment andthen eventually, when you're
done and you got things working.
You're going to merge yourlocal branch that you've created
(19:23):
from develop.
You're going to merge that backwith develop and then eventually
it's going to work its way upto production and and usually
the way it works is like theintegration branch and the the
main branch have controls aroundthem to where only certain
things and certain triggers andcertain tests complete
everything and there's usuallyhuman.
You can actually actually addapprovers, sign commits, there's
(19:43):
all sorts of security andcontrols you can put around how
code is actually updated throughthis process.
But it's usually a combinationof all those things and you
usually do have someone like ifyou 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 ofconsensus, like I need these
three approvers, or maybe I needthree approvers but there's
like 20 people in the approverslist.
(20:05):
So as long as one of three ofthose 20 people approve it, then
it can actually complete thatpull request and merge, if that
makes sense.
Speaker 1 (20:12):
I don't know if you can see it happening, but I'm
fighting my brain this wholetime because this all sounds
like software development and mybrain is like not for us, not
for me, not relevant.
I don't know if in the 10minutes we have left, we could
go through some like how can youuse this in network engineering
?
Because I think it's forautomation.
I'm not sure.
I think we said that it's for,like, version control, network
(20:34):
configurations, but I'm stillnot clear on that because we
talked about that and I'm stillconfused.
Dummy network engineer guy likehow, how is Git helpful?
For me?
It's version control.
I install it locally.
We do things in the cloud withGitHub.
I don't know what the hellGitLab is.
That'll be another episode.
It's awesome.
Speaker 3 (20:55):
Well, let me take a swing at maybe answering a top
line question for some networkengineers, and that is if I have
a team, if I'm using thisscenario where I need to take
inputs or we're doing configchanges, why would I use Git
instead of something else?
And one thing you benefit fromwhenever you use a tool like
this is that there is apre-baked process.
There's structure.
You might already be within aprocess that's already defined
(21:17):
and this might feel like a lift.
It is well-known enough thatmost folks you're going to
interact with they're going tobe familiar with it, but nothing
else.
It creates, built right intohow Git functions, a methodology
for creating local copies ofconfigurations and making
changes and then submittingthose changes to a group that
(21:39):
has been defined by someone elsefor review and either
acceptance, rejection it'scalled a merge.
We can merge it together.
We can merge.
We can merge it together.
We can replace, we can branchit off.
There's a lot of functionalitywithin.
Git that day-to-day a networkoperator is not going to
interact with, and that's fine.
You could use Git to iterate onimages if you wanted to.
(22:02):
It is simply a link in thechain of maintaining continuity
of information, and this is oneof the things that I constantly
struggle with when I'm workingwith cohorts really any company
that is.
Somebody sends me an attachmentof a Word document or a
PowerPoint presentation in anemail and I'm like I'm not
touching that.
Speaker 1 (22:22):
That's just where I was going with it.
Speaker 3 (22:23):
I make changes and I have a local copy and there's no
methodology to maintain how allthese changes are working.
That's just where I was goingwith it.
Document is that if I'm working, I might have multiple copies
of that Word document and Imight need to either merge those
(22:49):
into one there might be valuein me branching one off and this
is now.
There's two separate documentsand they each have value, but
it's different value.
So for a network operator,let's say that I have an
automation to backupconfigurations.
It is a very simple log intothe box, run a command.
I could use an API, but let'sjust make this really meat and
(23:10):
potatoes right.
It's a script.
It's going to interact with thebox.
It's going to run a command inuser space.
It's going to spit out a file.
Where does that file go?
Now, I've certainly had thatfile and this is a scenario I've
done.
It goes on a server, somewherein a directory, and then there
might be an overwrite.
There might be a crontab thatperiodically flushes things that
are older, whatever, but itgoes somewhere.
(23:32):
If I were to incorporate Gitinto that workflow, it would
just be an extra bit ofautomation 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, butthen it could upload into Git
and then Git becomes both.
This repository has versioncontrol.
It also gives people theability to go in and this is
kind of what makes it somewhatunique to go in and pull
(23:53):
configurations and look at them,review them, have a local copy,
maybe play with them in a lab.
It is just formalizing somestorage and collaborative
working workflows that we've hadhistorically is formalizing
them with a bit of structure,and I think that where I
consider the value in anetworking sense, there's
benefit in that structure,because if you have a method, if
(24:14):
you have structure, you'regoing to cut down on the
likelihood of misalignmentbetween versions, and just
having the rules already inplace by virtue of the tool
you're using can be superhelpful.
Speaker 2 (24:25):
That's a really good.
I love that because one thingif you're a network engineer,
like, why do you think youshould care about Git?
What do network operatorsactually care about?
So they care about complexity,they care about uptime.
Hopefully, they care aboutmaking consistent and auditable
changes.
So in 2025, in our world,there's not a more powerful tool
(24:45):
to underpin these principlesthan Git.
So if you take a little timeand if you've learned all the
CLIs of all the different things, like most network engineers
have, putting some of that timeinto Git not that hard, not that
bad.
Speaker 3 (24:58):
Go on, Git.
Speaker 2 (24:59):
Do it.
I think honestly a next episodeor something in the future.
It would be cool to do like ascreen share and actually
demonstrate some of the thingswe've talked about today.
I would like to do.
Speaker 1 (25:12):
I would like to do a lot of hands on with this kind
of stuff that so they always youalways hear, like, with
automation at least, like, finda use case.
And, as Colin was talking aboutthe attach word document that
everybody's sharing and tryingto figure out, I'm going through
that right now at work.
I'm collaborating with my team.
We're doing edits for somethingthat we're going to publish and
we're already trying to figureout.
Well, which version are we on.
(25:32):
Is it the one with underscoreAndy, or underscore whoever?
Is it V2, v3?
It's in the email thateverybody's on that I asked
somebody to look at.
But, like, can you send me thecurrent?
Speaker 3 (25:43):
You've already lost.
If you're versioning in thefile name, you've already lost
and that's what I did and we alldid.
Speaker 1 (25:50):
In these really big production environments Like
here's the spreadsheet with theVLANs or here's the whatever
right and which version are weon?
For me, my use case at themoment is at work, like in my
day-to-day.
I want to leverage a technologythat can stop the nightmare of
which version is current andwhere is it.
And oh, I have to download itlocally because it's in the
email they're on but I can'tdownload it.
(26:11):
So let me download it and sendit, 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.
That sounds so much cleaner tome and easier.
I just want my life to beeasier and be more efficient,
and this sounds like it'll dothat for me right.
Speaker 3 (26:27):
And the next rung on the ladder because it's a common
tool is integration.
Where you have a network, thenetwork is going to have network
tools attached to it, like anIPAM server that's doing DHCP
tracking clients.
When I say tracking, it's justit has a database that's making
sure that when we have networkinformation that's assigned to
an identity, that we're trackingthat identity relationship.
(26:49):
Once you have something likeGitHub that is broadly
understood and integrated, younow not only are backing up
configs, that becomes a datasource that these other network
tools can now touch.
And every time you havesomething that's more formalized
like that through anintegration, it's work you as a
network admin don't have to domanually and beyond that, maybe
(27:16):
build something new.
So I think that if you've neverused GitHub before, the best
way to interact with it is to dowhat I did go to and I said
GitHub again.
But GitHub offers a tutorialthat will show you how to use
Git and get familiar with the GHcommand, the Git command.
They are discreet and they havedifferent.
I created a text file that'sliterally a cheat sheet that I
still use.
But just walk through thetutorial and get a sense for
(27:38):
some of the four, five, sixbasic commands.
Honestly, there's a ton ofstuff there.
You're not gonna have to usemost of it.
I've done EVPN trainings whereI'm, like the guide's, 2,500
pages long.
Let me spend three minutestelling you what you need to
know, because ultimately, youdon't need to know most of this
for day-to-day and Git is nodifferent Guys.
Speaker 1 (27:56):
Thank you so much for this introduction to Git.
I think that we could probablyspend hours and hours on this,
so I'm hoping, as we moveforward with the show in 2025,
that we can do more like these.
I would love to get you guys onagain and maybe we could do
that screen share, walkthroughand some real use case, almost
like labbing.
I think for me that would helpkind of solidify some of these
(28:18):
topics.
And the biggest thing I'velearned in my life and even in
my career.
Like, content prior toinvestigation is no good For me
to say that tool is not for mebecause I'm not a software
developer.
But then say that tool is notfor me because I'm not a
software developer, but then Ihave conversations with smart
guys like you and I'm like, oh,this would make my life easier
today in a problem I'm having atwork.
That, by the way, has nothingto do with network engineering
(28:38):
or coding, but here is a toolthat can help me.
So thanks for coming on, guys,Thanks for the intro to Git.
We will hopefully have a followup where we get a little deeper
and do some labbing and someI'm going to branch and merge
and pull and dev and it's goingto be awesome.
It's going to be amazing.
Speaker 2 (28:53):
I'm going to be a killer soon.
Speaker 1 (28:55):
For all things.
Art of network engineering youcan check out our link tree.
It's link tree forward slash.
Art of net Our discord serverit's all about the journey is
there, which is a greatcommunity store.
I've been blogging lately so Ihope you're enjoying the content
and the shows.
Where can folks find you tofind if they want to reach out
and ask you about Git oranything else?
Speaker 3 (29:13):
Oh you go, William.
I'm a ghost in the shadows.
You're not going to find meonline yet.
Speaker 2 (29:24):
William hyphen Collins LinkedIn, twitter or X
Twitter, whatever.
W Collins 502.
I am on blue sky.
I forgot my username and thecloud 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 reallylike.
Speaker 1 (29:34):
Colin, people can't find you anywhere.
You're not even on the LinkedIn.
Speaker 3 (29:37):
Oh, okay, you're going to find me on LinkedIn,
cdoyle-pdx, and I have a YouTubechannel that I put very little
content into because I juststarted Nokia within the last
six months and I've been busywith stuff Yet another
networking channel, so you canfind me there.
I have an EVPN video up and Ishow how to make a Christmas
(29:58):
delight, which is was a lot offun to do.
Speaker 1 (29:59):
Reach out to them.
These guys are smart, they'reawesome, they're cool.
Thanks so much for listening.
We'll catch you next time onthe Art of Network Engineering
podcast.
Hey folks, if you like what youheard today, please subscribe
to our podcast and your favoritepodcatcher.
You can find us on socials atArt of NetEng, and you can visit
linktree.
Forward slash Art of NetEng forlinks to all of our content,
(30:19):
including the A1 merch store andour virtual community on
Discord called it's All Aboutthe Journey.
You can see our pretty faces onour YouTube channel named the
Art of Network Engineering.
That's youtubecom.
Forward slash Art of NetEng.
Thanks for listening.
This is the Art of Network Engineering, where
technology meets the human sideof IT.
Whether you're scaling networks, solving problems or shaping
your career, we've got theinsights, stories and tips to
keep you ahead in theever-evolving world of
networking.
Welcome to the Art of NetworkEngineering podcast.
My name is Andy Laptev and I amjoined on this episode by the
(00:21):
one, the only, the amenable.
No, that's not a word.
My wife can't say abominableand 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 youhere.
And the other guy that you seeon your screen or hear in your
ears is William Collinsreturning.
(00:42):
Hi, william, howdy, what's up?
Howdy, what's up, what's up andhow from kentucky kentucky
what's up.
indeed, we were just talkingbefore we we started the
recording about.
So the this episode is going tobe about git.
Right, we're g-i-t.
Git, git.
I don't know if I'm saying itright.
It's not get, it's git.
Git is not git.
(01:03):
Git is not GitHub.
They are second cousins.
It's GitHub without the hub.
There you go, and that's thetitle of the episode GitHub
without the hub.
So before we jump into Git,what is it and why?
Network engineers should careif we pop up a level real quick
and we were just talking aboutthis before we started I think
it's interesting that in networkengineering in general terms,
(01:26):
we kind of segment like whichtools are for what people.
And an example that we were justtalking 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 differentthings are going to come up and
you're going to have use cases.
You're going to want things tohelp you Like yes, you can still
(01:47):
buy a saw like a hand saw, buthey, they came up with electric
circular saws and isn't thatnice and all the time you save
and how much easier it makesyour life.
When I was an electric, when Iwas a plumber's helper,
sometimes we would have to hang.
They were like these metalhangers that you would put up
and then hammer them into afloor joist and it would help
support the weight of a pipe.
And never once was I like screwthat hammer and those
(02:10):
carpenter's tools because I'm aplumber's helper In the trades.
You wouldn't disqualify or justsay these aren't for me, these
are dumb.
But for some reason in networkengineering and I have been
guilty of this well, softwaredevelopment tools aren't for me.
That's not networking.
I don't care if it's going tomake my life easier.
I don't care if it's going tomake my workflows more efficient
.
I don't care if this is goingto help me find the damn version
(02:30):
of the document we're alltrying to find in emails for the
hundredth time.
That's not for me.
So what I'm hoping, movingforward, is we can do a bunch of
these software developmentadjacent episodes, and even
there I'm already doing thething.
I'm already calling themsomething else.
These software developmenttools, no, they're tools for all
of us.
Plumbers can use hammers,carpenters can use pipes.
(02:52):
So we want to talk about thatfor a brief moment before we get
into Git.
Have you guys experienced that?
Have you traditionally beenlike that's not for me.
Speaker 3 (03:06):
I think that I love your analogy, because we were
talking about this before youstarted recording.
But it did dawn on me that Ithink the barriers to entry for
somebody like myself, who is atraditional networking engineer,
and a new innovative toolyou're talking about
cross-discipline tool sharingI'm looking at the saw and I'm
thinking to myself the barrierto entry to picking up a saw and
using it's pretty low because Ican naturally understand what
(03:29):
it is and how to use it just bylooking at it.
And then I have a bunch ofexamples around me that I've
seen other people using saws.
Now if somebody walked up to mewith a CNC machine, I might be
like, well, why do I need that?
I got a saw and I know how todo it.
Sure, it takes longer, but I'mmore comfortable.
I might be like, well, why do Ineed that?
I got a saw and I know how todo it.
Sure, it takes longer, but I'mmore comfortable.
That might.
That analog might work a littlebit more.
Where you're looking at this newinnovation or this different
(03:52):
tool that has some complexity,you don't immediately understand
how it's going to work and I'llsay it, it's threatening.
I consider myself a subjectmatter expert.
And then there's this pointwhere this is something new.
I consider myself a subjectmatter expert.
And then there's this pointwhere this is something new and
I'm thinking in the time ittakes for me to learn this and
get all the optimizations.
I've been doing this for solong that it already takes me
(04:16):
much, much less time to executeor do networking stuff than it
did when I was a lowercase sc 20years ago.
So I think it's a good analog.
Speaker 2 (04:22):
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 atool chain that is used across,
like all technical verticals.
There's like a singular toolchain that really drives the way
that that teams do things nowto to varying degrees, and I
think network engineering as atrade was just well and security
(04:43):
are kind of the slow ones to topick it up.
So I've been using it for along time.
So I I started based on purelycuriosity, like in I don't know,
maybe to 2010 or something Ican't remember, maybe before
that, and I used it originallyfor not the right reason.
So I had a set of files used tocall them like dot files, and I
(05:04):
basically use Git as a backup.
I didn't have branching oranything.
I just cloned down andbootstrapped my Linux developer
environment and that was mywhole original purpose, and then
it just kind of morphed overtime.
Speaker 3 (05:16):
I was going to ask, but I think you kind of answered
it when you started using Git.
I assume that most people aregoing to come to it in one of
two ways they're either going totry it out as a tool for
themselves, or they're going tobe forced into its use because
they're going to be connected toa team or project that's using
it.
And I believe what you weresaying is that you decided to
just use it as a useful tool and, humorously, use it completely
(05:38):
incorrectly in hindsight.
Yep, uh, for your own purposes,just cloud backup, backup,
basically Easy cloud backup forfiles.
Speaker 2 (05:45):
This is a long time ago though, and if you look at
what it I don't want to go offon a tangent here but why does
it even exist?
It's kind of something that youhave to sort of piece through
before you get into any detail.
If you ask anybody, they'relike okay, it's just a
distributed version controlsystem.
Okay, I've heard that athousand times.
So what does that actually mean?
(06:05):
Let's start with distributed, asin like, shared amongst many
places, people and systems, andthen version control, meaning it
was designed not the way I usedit originally, but it was
designed to track changes insource code or, really
technically, any set of filesover time.
And thinking about this rightnow, it's kind of funny because
(06:26):
I've been using Git and Linux inmy professional life since a
long time ago, and Linuxespecially much farther back,
and both of these technologiesand I think this is important to
understand is they came fromthe same person, Linus Tarvolts.
You can't understand, I don'tthink, the purpose of Git
without going back a littlefurther and looking at the
origins of Linux just a littlebit.
(06:47):
So I don't know if you'd wantto dig in on that a little bit.
Speaker 1 (06:50):
I would like to dig into that.
But right before we dig intothat, I just want to make a
comment.
Something happened to my brainwhen you said track changes in
source code, and I think this ispart of the problem and there's
probably cognitive biases inthere 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 sourcecode is.
So I'm just saying this outloud.
(07:12):
I'm saying the embarrassingthing out loud, because when I
hear terms that I don't feelhave anything to do with me, my
career, my life, my job, I thinkmy brain disqualifies the tool
wholesalely, which isunfortunate, which is probably
why I'm at the point of mycareer and life where I'm still
trying to figure out what thehell git is.
Speaker 3 (07:32):
So just to be aware, if you're not a software
operator why should you careabout source code?
Speaker 2 (07:37):
think about it, but it goes beyond.
That was the original yep use,but now configuration files
exactly.
So I wanted sorts of differentstuff.
Speaker 1 (07:46):
I wanted to build that bridge, like, just because
you said it's the track changesin source code, you can track
changes and other things likeconfiguration.
So don't tune out like I justdid.
I'm trying to pull my brainback 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 (08:03):
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 scistudent, just I think,
university of Helsinki inFinland.
And this was basically bornfrom, like Linus getting
incredibly irritated at onlylike commercial Unix offerings
at the time being available.
They had to like run on certainhardware like yada yada, yada.
(08:26):
So he decides, hey, I want torun stuff on my own hardware
that meets my creative thinkingand tinkering, because I'm an
ultra nerd.
So if you look at like what hashappened since he came and sort
of built Linux, it's changed,kind of changed.
The world Powers the internet.
It's really flipped the scripton proprietary software.
It's democratized softwaredevelopment, like how you
(08:48):
actually build software, and itdominates mobile and embedded
systems.
So fast forward to the early2000s, I guess.
And the Linux kernel projecthas grown to epic proportions.
We're talking like hundreds, ifnot thousands, contributing
worldwide.
I don't know the number, butthere was existing tools at the
time that were used to versioncontrol the software.
(09:10):
And speaking of open source andlicensing issues that have been
in the news recently, I thinkit was actually like a licensing
dispute, if I'm not mistaken,they basically saw Linus, who is
now well known to not reallymess around with inefficiency
he's inefficiency sort offocused to basically build his
own version control systemtailored specifically for the
(09:30):
growth in the scale of the Linuxkernel project.
I could be wrong on this.
I read this at some point awhile back, but I think the
original version of Git.
He actually cobbled togetherlike on a Saturday and a Sunday,
like on a long weekend,basically.
Git he actually cobbledtogether like on a Saturday and
a Sunday, like on a long weekendbasically, and with the goal of
(09:51):
keeping Linux kernel dev movingfast without the reliance on
anyone else's software.
So that's how Git was born.
It's kind of a crazy originstory, if you ask me.
Speaker 3 (09:56):
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 seehim speak and once at an intel
conference 20 some years ago,and when you mentioned that he I
(10:18):
don't how'd you put it?
like sufficiency, doesn't likeoptimization somebody,
efficiency somebody stood up andasked him a straight up comic
con type question where, likethis bug and this thing, linus
straight cursed the guy out.
He's like why would you wasteeverybody?
It was just, he was very spicy,it was, it was fun.
Speaker 2 (10:38):
Oh, he's spicy.
Known for the spice he's.
Speaker 3 (10:40):
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 communitythere has to be a method for
allowing free and opendevelopment, but also review,
because if you're doingdevelopment on code that already
exists, that development isgoing to go one of three ways
(11:02):
it's going to go in the bin.
That development is going to goone of three ways it's going to
go in the bin.
It's going to be something thata community feels contributes
sufficient value to the originalproject that it will become a
part of that project andultimately, the people that are
doing development could beowners of the project, they
could be people that are usingthe project, but there still has
to be this co-development spacein order for the community to
(11:23):
thrive the way that it does.
Or you've created something newand unique, and that is where I
think the magic of GitHub orGit, I should say, and GitHub.
They do become analogous in myhead.
I got to get over that.
But the way Git works is reallyinnovative, and that is that it
allows you to take a project andthen clone that project, so you
(11:46):
have a local copy and then dorkaround with the project and
then either it's yours and youcan just run with what you have,
or and this is, I think, wherepeople's brains start to fold
you can do a pull request, whichmakes it feel like you're
grabbing something and bringingit back in, but in fact what
you're doing is you are openingup the changes that you've made
(12:06):
for review and revision andpotentially merging back into
the branch, and that's when youlook at the way that projects
work and, visualized, it almostlooks like the way you might
show evolution from one point tomany things.
It doesn't even need to be thatcomplex like you were doing.
It could also just be me doingversion control right.
(12:26):
I just need to make sure thatif I screw something up this
week, I can go back to what Ihad last week.
Speaker 2 (12:30):
You mentioned a really a point that I like to
differentiate between and Ithink 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 thecreative genius and advocate for
freedom, yada, yada yada thathe is, he chose to license Git
under like a true open sourcegeneral public version to
(12:53):
licensing, so making it okay,it's free to use, study, modify,
share, hack, whatever you wantto do with it.
That's one of the reasons Gitcaught fire and basically became
the default standard for, like,best practice, software
development patterns, yada yada.
This led to commercialofferings to the audience.
Github, gitlab these arecommercial offerings that are
basically built atop thefunctionality of Git is the
(13:15):
underlying technology.
So GitHub it is a cloud-hostedservice that basically takes
Git's functionality and extendsit and it adds like some social
and collaborative layers on top.
So you can think of it like Gitbeing the underlying tech, with
GitHub being that nice garagethat you park your or Andy parks
his Ferrari and tunes it andthen shows it off to people, if
(13:38):
that makes sense.
Speaker 3 (13:40):
Well, we have Git as a part of the tooling and some
of the solutions that we have atNokia, and I won't.
This isn't going to turn into asales or marketing thing, but
when I present on that and Italk about it, I try to make it
clear that the reason I'mmentioning that we're using Git
isn't because you have to befamiliar with Git.
It's a way of signaling that weare using a baked in
(14:01):
well-understood, well-known toolto do, in the case that I'm
thinking of, of specificallyconfiguration, version control.
So it's not that you have tounderstand how that works.
It's more of a statement on thematurity of the tool itself.
Have confidence Now, to theextent that you want to interact
with it the way that youinteract with Git, you can do
that, but you also don't have to.
Either way.
(14:22):
The fact that we can use itwithin these commodities, these
tools that we build and sellthat's exactly what you're
talking about.
It has sort of become de factostandard for that.
Speaker 2 (14:30):
So to put this back in the context- I just said
something that go ahead, andy,sorry.
Speaker 1 (14:34):
Well, no, no, no, real quick.
So I'm always trying to tiethis back to network engineering
, because I get kind of lost inthe sauce.
So what did you say?
Configuration, management,configuration, version control,
whatever it is.
So, here's my question, becauseI have not used the extent of my
Git.
Experience has been likepulling down a repo.
Why, I don't know, becausesomething on Google told me to
(14:54):
once because I needed a thingright, but I didn't make any
changes, I didn't do a pullrequest, I basically just so.
This is something you have toinstall locally, I believe, and
these are some of the steps Iwant to walk through in a moment
.
But you have to install itlocally.
You need a GitHub account,which I guess is a repository,
like you said, online.
But to pull it back tonetworking, so when I was in
production I would have a configin a router, let's say, or a
(15:15):
switch, and maybe I had to makea change, maybe I had to add a
prefix to a prefix list to allowsome routing through.
I would do it in the CLI, vianotepad 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 magictie together?
Like, does it still work thatway, or are we not talking about
(15:38):
switch configurations?
This is something not related.
Speaker 2 (15:41):
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 ona rant here, so tying it back to
network engineering like oneway to think about it.
Like, when you think of, likeyou, I think you could loosely
compare Git to like a routingtable, so distributed state
management.
It's an interesting thing theway Git works.
It really isn't too far removedfrom network devices and
(16:04):
routing tables.
Git is fundamentally distributed.
Every repo that you clonecontains the full history of all
the changes that have everhappened.
For that thing, there's nosingle 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 tosync everything up.
And if you think of likerouting tables, routing
(16:26):
protocols like BGP or OSPF, theymaintain this distributed table
across routers.
Like each router gets its ownview of the network topology and
updates.
It gets updated and that'sbased on the information shared
by peers.
Like Git, there's no centralizedtruth.
The system converges throughcollaboration of sorts.
So both rely on thisdecentralized nodes, that kind
(16:50):
of share, and reconcileinformation to maintain a
coherent system state.
So when you get into changetracking, git tracks changes
only it doesn't actually makechanges to network devices, it
just keeps track of that statevia something like you all said,
commits, and this is snapshotsof the project state tied
together in a DAG, pretty much.
(17:11):
So when you push or pull,changes propagate between
repositories and merge andreconcile the differences.
So you can kind of think aboutrouting tables as they evolve as
the network conditions change.
Take link failures or a routemap or a policy update that
triggers routers to exchangeupdates, like these updates
(17:32):
propagate through the networkand routers adjust their tables
to reflect their new reality.
So, but I guess what I'm tryingto say is like both systems log
into, distribute incrementalupdates, ensuring that all
participants eventually alignand have this consistent view.
Speaker 1 (17:46):
So if we have a golden config that I want to
change, what I usually do isemail 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 thisdevice?
Could I branch it and propose achange which is my prefix list
change?
Could that kick off some kindof review process?
So instead of someone reviewingsource code, they're reviewing
my config revision and thenapprove it and then so, even
(18:09):
though it doesn't push it for me, can I use that as a peer
review for configs I want tochange?
Does that make sense?
Speaker 2 (18:15):
Well, human hands are going to be involved.
So if you think, like what youjust said is actually a really
good segue, I don't want to getlike too far into like a
branching strategy, butbasically for like you're
talking about this new task orthis new thing you're doing, so
you would actually create.
Basically, you have the mainbranch that is usually going to
be tied back to production.
Main is always production,mirrors, production, yada, yada,
yada.
(18:35):
But usually when you get just alittle more mature, this isn't
to the level of developingsoftware for whatever, some big
hyperscale company, but youusually have some sort of
integration branch call itdevelop or pre-prod or something
, and that's how you're going tofully test and get everything
ready before you do that shiftto main.
When you're actually doing work, though those small tasks that
(18:57):
you're talking about, you'regoing to create usually what's
called a feature branch and youcreate that branch off of that
developer pre-production branchor call it an integration branch
.
And that's the work that youpre-production branch or call it
like an integration branch, andthat's the work that you're
going to test, tinker aroundwith, commit your changes, add a
nice thoughtful comment andthen eventually, when you're
done and you got things working.
You're going to merge yourlocal branch that you've created
(19:23):
from develop.
You're going to merge that backwith develop and then eventually
it's going to work its way upto production and and usually
the way it works is like theintegration branch and the the
main branch have controls aroundthem to where only certain
things and certain triggers andcertain tests complete
everything and there's usuallyhuman.
You can actually actually addapprovers, sign commits, there's
(19:43):
all sorts of security andcontrols you can put around how
code is actually updated throughthis process.
But it's usually a combinationof all those things and you
usually do have someone like ifyou 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 ofconsensus, like I need these
three approvers, or maybe I needthree approvers but there's
like 20 people in the approverslist.
(20:05):
So as long as one of three ofthose 20 people approve it, then
it can actually complete thatpull request and merge, if that
makes sense.
Speaker 1 (20:12):
I don't know if you can see it happening, but I'm
fighting my brain this wholetime because this all sounds
like software development and mybrain is like not for us, not
for me, not relevant.
I don't know if in the 10minutes we have left, we could
go through some like how can youuse this in network engineering
?
Because I think it's forautomation.
I'm not sure.
I think we said that it's for,like, version control, network
(20:34):
configurations, but I'm stillnot clear on that because we
talked about that and I'm stillconfused.
Dummy network engineer guy likehow, how is Git helpful?
For me?
It's version control.
I install it locally.
We do things in the cloud withGitHub.
I don't know what the hellGitLab is.
That'll be another episode.
It's awesome.
Speaker 3 (20:55):
Well, let me take a swing at maybe answering a top
line question for some networkengineers, and that is if I have
a team, if I'm using thisscenario where I need to take
inputs or we're doing configchanges, why would I use Git
instead of something else?
And one thing you benefit fromwhenever you use a tool like
this is that there is apre-baked process.
There's structure.
You might already be within aprocess that's already defined
(21:17):
and this might feel like a lift.
It is well-known enough thatmost folks you're going to
interact with they're going tobe familiar with it, but nothing
else.
It creates, built right intohow Git functions, a methodology
for creating local copies ofconfigurations and making
changes and then submittingthose changes to a group that
(21:39):
has been defined by someone elsefor review and either
acceptance, rejection it'scalled a merge.
We can merge it together.
We can merge.
We can merge it together.
We can replace, we can branchit off.
There's a lot of functionalitywithin.
Git that day-to-day a networkoperator is not going to
interact with, and that's fine.
You could use Git to iterate onimages if you wanted to.
(22:02):
It is simply a link in thechain of maintaining continuity
of information, and this is oneof the things that I constantly
struggle with when I'm workingwith cohorts really any company
that is.
Somebody sends me an attachmentof a Word document or a
PowerPoint presentation in anemail and I'm like I'm not
touching that.
Speaker 1 (22:22):
That's just where I was going with it.
Speaker 3 (22:23):
I make changes and I have a local copy and there's no
methodology to maintain how allthese changes are working.
That's just where I was goingwith it.
Document is that if I'm working, I might have multiple copies
of that Word document and Imight need to either merge those
(22:49):
into one there might be valuein me branching one off and this
is now.
There's two separate documentsand they each have value, but
it's different value.
So for a network operator,let's say that I have an
automation to backupconfigurations.
It is a very simple log intothe box, run a command.
I could use an API, but let'sjust make this really meat and
(23:10):
potatoes right.
It's a script.
It's going to interact with thebox.
It's going to run a command inuser space.
It's going to spit out a file.
Where does that file go?
Now, I've certainly had thatfile and this is a scenario I've
done.
It goes on a server, somewherein a directory, and then there
might be an overwrite.
There might be a crontab thatperiodically flushes things that
are older, whatever, but itgoes somewhere.
(23:32):
If I were to incorporate Gitinto that workflow, it would
just be an extra bit ofautomation 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, butthen it could upload into Git
and then Git becomes both.
This repository has versioncontrol.
It also gives people theability to go in and this is
kind of what makes it somewhatunique to go in and pull
(23:53):
configurations and look at them,review them, have a local copy,
maybe play with them in a lab.
It is just formalizing somestorage and collaborative
working workflows that we've hadhistorically is formalizing
them with a bit of structure,and I think that where I
consider the value in anetworking sense, there's
benefit in that structure,because if you have a method, if
(24:14):
you have structure, you'regoing to cut down on the
likelihood of misalignmentbetween versions, and just
having the rules already inplace by virtue of the tool
you're using can be superhelpful.
Speaker 2 (24:25):
That's a really good.
I love that because one thingif you're a network engineer,
like, why do you think youshould care about Git?
What do network operatorsactually care about?
So they care about complexity,they care about uptime.
Hopefully, they care aboutmaking consistent and auditable
changes.
So in 2025, in our world,there's not a more powerful tool
(24:45):
to underpin these principlesthan Git.
So if you take a little timeand if you've learned all the
CLIs of all the different things, like most network engineers
have, putting some of that timeinto Git not that hard, not that
bad.
Speaker 3 (24:58):
Go on, Git.
Speaker 2 (24:59):
Do it.
I think honestly a next episodeor something in the future.
It would be cool to do like ascreen share and actually
demonstrate some of the thingswe've talked about today.
I would like to do.
Speaker 1 (25:12):
I would like to do a lot of hands on with this kind
of stuff that so they always youalways hear, like, with
automation at least, like, finda use case.
And, as Colin was talking aboutthe attach word document that
everybody's sharing and tryingto figure out, I'm going through
that right now at work.
I'm collaborating with my team.
We're doing edits for somethingthat we're going to publish and
we're already trying to figureout.
Well, which version are we on.
(25:32):
Is it the one with underscoreAndy, or underscore whoever?
Is it V2, v3?
It's in the email thateverybody's on that I asked
somebody to look at.
But, like, can you send me thecurrent?
Speaker 3 (25:43):
You've already lost.
If you're versioning in thefile name, you've already lost
and that's what I did and we alldid.
Speaker 1 (25:50):
In these really big production environments Like
here's the spreadsheet with theVLANs or here's the whatever
right and which version are weon?
For me, my use case at themoment is at work, like in my
day-to-day.
I want to leverage a technologythat can stop the nightmare of
which version is current andwhere is it.
And oh, I have to download itlocally because it's in the
email they're on but I can'tdownload it.
(26:11):
So let me download it and sendit, 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.
That sounds so much cleaner tome and easier.
I just want my life to beeasier and be more efficient,
and this sounds like it'll dothat for me right.
Speaker 3 (26:27):
And the next rung on the ladder because it's a common
tool is integration.
Where you have a network, thenetwork is going to have network
tools attached to it, like anIPAM server that's doing DHCP
tracking clients.
When I say tracking, it's justit has a database that's making
sure that when we have networkinformation that's assigned to
an identity, that we're trackingthat identity relationship.
(26:49):
Once you have something likeGitHub that is broadly
understood and integrated, younow not only are backing up
configs, that becomes a datasource that these other network
tools can now touch.
And every time you havesomething that's more formalized
like that through anintegration, it's work you as a
network admin don't have to domanually and beyond that, maybe
(27:16):
build something new.
So I think that if you've neverused GitHub before, the best
way to interact with it is to dowhat I did go to and I said
GitHub again.
But GitHub offers a tutorialthat will show you how to use
Git and get familiar with the GHcommand, the Git command.
They are discreet and they havedifferent.
I created a text file that'sliterally a cheat sheet that I
still use.
But just walk through thetutorial and get a sense for
(27:38):
some of the four, five, sixbasic commands.
Honestly, there's a ton ofstuff there.
You're not gonna have to usemost of it.
I've done EVPN trainings whereI'm, like the guide's, 2,500
pages long.
Let me spend three minutestelling you what you need to
know, because ultimately, youdon't need to know most of this
for day-to-day and Git is nodifferent Guys.
Speaker 1 (27:56):
Thank you so much for this introduction to Git.
I think that we could probablyspend hours and hours on this,
so I'm hoping, as we moveforward with the show in 2025,
that we can do more like these.
I would love to get you guys onagain and maybe we could do
that screen share, walkthroughand some real use case, almost
like labbing.
I think for me that would helpkind of solidify some of these
(28:18):
topics.
And the biggest thing I'velearned in my life and even in
my career.
Like, content prior toinvestigation is no good For me
to say that tool is not for mebecause I'm not a software
developer.
But then say that tool is notfor me because I'm not a
software developer, but then Ihave conversations with smart
guys like you and I'm like, oh,this would make my life easier
today in a problem I'm having atwork.
That, by the way, has nothingto do with network engineering
(28:38):
or coding, but here is a toolthat can help me.
So thanks for coming on, guys,Thanks for the intro to Git.
We will hopefully have a followup where we get a little deeper
and do some labbing and someI'm going to branch and merge
and pull and dev and it's goingto be awesome.
It's going to be amazing.
Speaker 2 (28:53):
I'm going to be a killer soon.
Speaker 1 (28:55):
For all things.
Art of network engineering youcan check out our link tree.
It's link tree forward slash.
Art of net Our discord serverit's all about the journey is
there, which is a greatcommunity store.
I've been blogging lately so Ihope you're enjoying the content
and the shows.
Where can folks find you tofind if they want to reach out
and ask you about Git oranything else?
Speaker 3 (29:13):
Oh you go, William.
I'm a ghost in the shadows.
You're not going to find meonline yet.
Speaker 2 (29:24):
William hyphen Collins LinkedIn, twitter or X
Twitter, whatever.
W Collins 502.
I am on blue sky.
I forgot my username and thecloud 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 reallylike.
Speaker 1 (29:34):
Colin, people can't find you anywhere.
You're not even on the LinkedIn.
Speaker 3 (29:37):
Oh, okay, you're going to find me on LinkedIn,
cdoyle-pdx, and I have a YouTubechannel that I put very little
content into because I juststarted Nokia within the last
six months and I've been busywith stuff Yet another
networking channel, so you canfind me there.
I have an EVPN video up and Ishow how to make a Christmas
(29:58):
delight, which is was a lot offun to do.
Speaker 1 (29:59):
Reach out to them.
These guys are smart, they'reawesome, they're cool.
Thanks so much for listening.
We'll catch you next time onthe Art of Network Engineering
podcast.
Hey folks, if you like what youheard today, please subscribe
to our podcast and your favoritepodcatcher.
You can find us on socials atArt of NetEng, and you can visit
linktree.
Forward slash Art of NetEng forlinks to all of our content,
(30:19):
including the A1 merch store andour virtual community on
Discord called it's All Aboutthe Journey.
You can see our pretty faces onour YouTube channel named the
Art of Network Engineering.
That's youtubecom.
Forward slash Art of NetEng.
Thanks for listening.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Intentionally Disturbing
Join me on this podcast as I navigate the murky waters of human behavior, current events, and personal anecdotes through in-depth interviews with incredible people—all served with a generous helping of sarcasm and satire. After years as a forensic and clinical psychologist, I offer a unique interview style and a low tolerance for bullshit, quickly steering conversations toward depth and darkness. I honor the seriousness while also appreciating wit. I’m your guide through the twisted labyrinth of the human psyche, armed with dark humor and biting wit.