Git Fundamentals

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Tolinski and Wes Boss.

Welcome to Syntax. Scott just tried to start the show there.

I Scott, the tasty Scott starts the hasties.

This is a show we're gonna do another fundamentals episode, and I can't believe this is not one that we thought about. Scott just messaged music. Hey. We've never really done, like, a Git episode on what are the fundamentals. Really just doing an explainer episode. So that's what we got for you today. We are sponsored by 2 awesome companies. First one is Sentry, which is gonna do all of your error and exception tracking in FreshBooks, which is cloud accounting. My name is Wes Bos. I'm a developer from The Hammer, and Scott is with me. How are you doing today, Scott?

Hey.

I am doing good.

I was trying to think of a cool nickname for her for I I it's got from Mile High. Yeah. Oh, really? Yeah. That's what they call Denver because it's a mile high in elevation.

Yeah. Our football stadium was the mile high for a long time, and now it's something else. But, yes, I am here, and I'm with Wes and the hammer, ready ready to talk about GitHub. Because if there's something that any beginner web developer knows is there's nothing more likely to make you want to run and grab your hammer from the garage and smash your computer than some good old fashioned confusion within Git.

Because this is a a topic that trips up a lot of people, especially when they've never used any kind of version control in the past.

So I'm really excited to talk about Git Fundamentals.

And I'm also excited to chat with you about it, Wes, because I don't know. We don't talk about good stuff that much even when we're just chit chatting. So Git chatting. Yeah. Git chatting. Yeah. This will be some Git chatting. And I'm excited to, just get a little bit of West Boss, get action, whatever you're doing here, and and, you know, do the same.

So I just googled the highest cities in North America, and Denver is the 2nd highest city in North America. Elevation.

In all of it in more than one way, actually.

But Wes. In many ways.

That's unreal. So does water take longer to boil up there?

Absolutely. In fact, my mother-in-law, whenever she comes here, she's always, like, having to adjust all of her recipes.

Things bake at different different lengths. Wow.

There's all sorts of stuff. In fact, when you get here, one of the first things that happens to some people is they get really bad headaches because they're getting tired really quickly.

For the 1st, like, month we lived here, you would have a beer and you'd be like, you'd be drunk just because you get drunk faster. There's all sorts of, like, weird little things. Oh, wow. Yeah. That's why, actually, the Olympic Training Center is here and everything. The athletes train pnpm elevation so that you can perform better at normal elevations. The babies are even born with a different amount of, like, like, the blood count is different within the babies. There's, like, a whole thing about that. Wow.

Alright. So you probably have used Git if you're if you're listening to this, but we're we're gonna start from the fundamentals. So bear with us. Git is a version control system, and and what that means is that you set up what's called the Git repository.

And as you write your code in a git repository, you're able to track changes for like, let's say you're working on a new feature.

You write the code for that feature.

And then, generally, Wes we maybe can talk about this a little bit later JS, like, when do you commit something. But, generally, like, when you're done that feature, you'll go ahead and commit that feature.

And then if something breaks or you need to go back to and reference what you had in the past, you don't have to make another folder of that. You're able to roll it back. You're able to view previous commits. It's sort of like little snapshots in time, and that's very important because of accidentally deleting code or or or whatnot, but also just the code bases do get fairly large. And if you were just to copy paste the entire folder every single time, it would be way too large, and there is no way for you to track who, what, and when changed at a certain point in time.

Yeah. The who, what, when, what has changed, that is really the core concepts here JS that this is a thing that allows you to, in an organized fashion, keep versions of your your Node, and that's pretty much it. Right? It JS here to allow you to have various versions Node different pathways for your code to exist in the world. And this is important for 2 major reasons for working by yourself, the history of your code, having your code stay organized in a way that if you goof up, you can go back to. Right? Maybe perhaps you installed a version of a package that is no longer compatible with your system and you want to go back. Well, this is an easy way to go exactly back to where you were before. Right? It's like a save state in a video game. You can just start over. Right? Another cool thing about it is the ease of which it makes working within teams.

Because a lot of times Wes we're working in teams, we all know the warp the the workflows that can happen with if some people are in the same file and you're saving over a file. I mean, I I know that when we were doing occasional cowboy coding Wes you're editing files live on FTP, you know, like, 20 years ago, there would be a situation where somebody would save a file and somebody else had a different local copy of that file. They saved it. They both uploaded.

1 of them is good. 1 of them is not good, and you just blew away all of the work that somebody else just did. I remember that happening. And what this allows you to do more than just that that, though, it allows you to understand exactly how the code was written and by who and when and where and what. And there's all sorts of extensions and whatever in your your code editor. In fact, I can hover in hover over any line in my code, and it's going to tell me who wrote that line Wes they wrote it.

So for me, that is, like, a very, very crucial skill. And anytime you have teams of people, even like 2 or more people working on code, these features really start to be important.

So it's funny because those things are all important for individuals, but I think Git enters like a whole another realm the moment you start working in teams because there's so many cool different flows in ways that people can commit code and share code and and add code to your repo open source or closed source wise.

I thought we would maybe breeze through this UI Vercel command line thing. Maybe talk about why Git can be a little bit scary here, and then we'll come back to the Git UI thing a little bit later in the episode.

So we wanted to to first and foremost say well, I guess for 1st and foremost, do you use a Git client?

I don't. The closest thing that I come to using a Git ESLint, and I have used a couple in the past, but I've always come back to just using the command line. But the closest thing I used to a GUI is, when I have merges that need to happen, I will jump into Versus Node and and Yarn use their GUI for that. Although I I have used better I've had to have better experiences in other applications. We'll talk about that. But I'm primarily, I'd say, 98% in the

command line. Yeah. I would say I am just about the exact same.

Versus Node specifically is really the only GUI that I use for Git. And I do have a handful of extensions installed, whether it's GitLens to see, you know, who committed what or there's some Git history ones where you can get that neat little subway graph looking type thing of your code so you can see where exactly, you know, branches happen and things like that. So I do have a lot of extensions there. But when it comes to committing, staging and all those things, which we'll define later in this episode, I'm pretty much doing it all through the command line.

The version control tab in Vercel Node is very good, though, if you ever are interested in using it. There are some things they can't do, but I do occasionally come to the the what's changed panel in Versus Code to sort of see which files have been recently changed or, hey, I just did this thing, and I didn't intend for it to hit this file. But, oh, there it is. It's in the the files that's been changed, writing git commit messages. Sometimes I I do use this because it's it's easy, but I almost always just default back to the terminal because of straight up muscle memory.

Yeah. I was thinking the other day, probably about, like, a week ago, like, I would love somebody asked me, like, hey. Can you do a Git course? And I was like, like, what would I do in a Git course? Because, like I thought about that too. Almost all of my my Git stuff is, like, the stuff we're gonna talk about today. And then when it comes to complicated rebases and squashes and and rolling back things, I usually have to do a a little bit of googling here or there to find out what I'm actually doing.

Yeah. There's a lot of, like, complex Git that scares me still just because I don't need it yet. I I haven't found the times where I'm, like, really needing it.

Cool. So let's get into Git Node zero one. Actually, before we even get to this is Git o o one. I don't think that's a thing, but I'm talking about, like, installing Git. Do you have to install Git? What do you do to get Git up and running? How do you Git running? Man, that that's a good question. Because it feels like a whole other lifetime ago that I

lasted dealt with this. I've probably installed Git, like, twice over my entire last 10 years, and that's because that's when you get a new laptop, you have to install it. It does it come with Xcode? I don't even know. On a Mac? See, that's a great question. You need Xcode. If you're on a Mac, you need the Xcode command line tools, but I don't believe it does come with Git.

I believe you do need to install it from git hyphenscm.com.

I'll have the link in the show notes. It's like a click installer. It's if you're on Mac or Windows. I remember this. It's just been so long. And then the first time you use it, it says, oh, I need Xcode developer tools, and you have to download a 90 gig file from Apple, in order to make it work. An entire day. So just like if you're, like, sitting down to play a video game, make sure you turn the console on early so that it can install the latest updates just like that.

I believe it probably does come with most Linux distros just because that is something that you do in Linux JS you live in the command line to get it. And Windows definitely doesn't come with it, but, again, it's just a click through installer. I believe that process is pretty simple on Windows as well.

Yeah. Yeah. So the first thing we need to do if we are going to be starting a repo or JS Wes Wes mentioned, it's a repository.

Right? You'll often heard that hear them referred to as repos just because it's easier to say.

So to initialize a repo, let's say you have a folder full of your code and you want this code to be tracked by this version control system. You would have to be in that directory and you would type in your command line once it gets installed, git space in it for git initialize.

Do you know what git init actually does, Wes?

In the folder that you're working in, generally, it's the root of your actual project. When you type that, it will create a hidden folder that's called dot git, and, usually, you don't see that folder because most editors JS well as most, by default, your finder and Windows Explorer will hide hidden folders from you. And if you enable your I I recommend turning it on if you're a new developer so you can see them, but it'll still make it sort of grayed out so you know that it's a hidden folder. And and inside of that Scott git folder, it contains information about your repository. So that that tracks things like, where are you currently in your thing? So, like, have you made any commits? Have you made any changes? Have there been new files added since, since you've you've done the last commit? It also keeps all of the changes that you've done, in a very small fashion, so it tracks all of the changes that went through. And then it also tracks origins, which is we'll talk about that. But, generally, if you wanna push your your GitHub repo to somebody else, you wanna you wanna get it from your computer to another computer, most likely, that's, like, GitHub, then you it will keep track of different spots where you can you can put that. Those are called origins.

Yeah. Cool.

So we have our folder. And if your code is not living anywhere else, as in you haven't pushed it to a remote location like GitHub or Bitbucket or whatever, if you delete that .git folder, there goes your whole history. That thing that's all if you're only keeping it in Node location, whatever. All of the information your your entire application needs to have that version controls in that that git folder. So if you don't have it remotely saved anywhere, that history is gonna be all gone the moment you you delete that, which might be helpful if you're trying to declare bankruptcy and yet maybe you've, like, goofed it up enough where you're just like, you know what? Screw it. Starting over. Because that's certainly a thing I feel like that can happen at the end, you know, at the beginning. Lots of times. Yeah.

Yeah. Definitely. Especially when you're learning. I think people people often forget just if you've never worked in a version control system, how different or weird it can feel at first, when you're first learning, especially if you've worked in different ways prior to that. If you're coming brand new to programming, maybe it gets just embedded as something you've done because of your boot camp taught you or something. But, for a lot of us, we had done many other means of working in files or even version control before this.

So now we have the next major command, which you're going to need to know is add. So we would like to say get add. Now get add has a whole bunch of options. And the funniest thing about Git ads options are is I feel like everybody kind of tells you to use different ones in different tutorials, which is this funny. People just be like, all right, we're going to do Git ad space then Node. And then somebody's also we're gonna Git ad space hyphen a. Now what do you do specifically, Wes, with your Git add? And then and then maybe you can talk about what does Git add do. So what I'll do is if I wanna add absolutely everything that is in the current folder,

I do get add space a, and and that will add absolutely everything.

When I've made changes after commit, we'll talk about what that is in a second.

I use git add dash p. Have you ever used dash p? I have not to use the dash p. The best. So that I don't know what the p stands for. Progressive, maybe? Partial? Porcupine. Porcupine. It basically, what it does is it it takes every single change that you've done since you last did a commit, and it will allow to you to Wes, Node, each of those changes. So it it it shows you the diff right in your command line, and you put your fingers on the y and the end keys, and you just go through every single change that you've done. Cool. And it will just show you because sometimes, like, I've done this many times, JS you just blindly add everything that has changed, and then maybe you accidentally made a change or put a console log in somewhere that you shouldn't have. And this allows you to have a quick little review of all of the changes you've made before you go and and send that off to a team member or something like that. Cool. So by default, when you do a git init, none of your files are being tracked.

And if you wanna track changes to those files, you have to first add them to the repo, and then you also when they've changed, you have to add them as well.

A really important part to remember before you do your 1st git add JS make sure you create a Scott git ignore file.

And in that in that file, you list all of the folders and files that you do not wish to be part of your git repo because you don't want everything to be part of your Git repo. Like, what are some ideas some things that shouldn't be part of repo, like passwords, environmental variables Files. D s store is one that always pops up on a Mac for some reason.

Large files like videos, sometimes even if you've got lots of images, that's not necessarily a good spot for putting them in in a git repo because it gets it gets really, really big. So, generally, you wanna ignore all of those those things, and they will still live on your computer, but they will not be part of your Git repo, and they will not be pushed to other people who use that Git repo. And then, also, if you lose those files, you're you're kinda out of luck as well because they're not they're not backed up in in any way.

Yeah. Cool. So I I actually pretty much always do Git add and then period, which to my understanding, just adds everything that has been changed.

It's just like a blanket ad. Yeah. The difference between dash capital a and dash period is that if you are in a subfolder, add dash a will add everything that is tracked by the repo, and the the period will add everything that is in that current folder. So that might it's usually not a difference, but it actually it might be something that you want. But, yeah, I only want to add the changes to this controller's folder, not not the package JSON or whatever I did to to upgrade that.

Yeah. Well, here's a a good little tip. What I would do if I were you is is probably do what Wes is doing with the hyphen a flag, the git add hyphen a, and then just alias that in your your bash to like get add or just add or something so that you never have to think about it again because it's not one of those things you I mean, there are features in here like such as the the patch prompt that Wes is saying. But, like, I don't ever you know, day to day, I don't need to look if I needed these, I would look them up. So I most always alias my get add to something else. So, like Wes mentioned, Sanity time you add a file to your project or any time a file has been changed, you need to add it as like saying, hey, these changes have happened.

Once those changes have happened, you need to commit those changes. Node, the commit is where you're basically solidifying those changes as something that has happened, where the ad, it's it's not putting it it's not writing it into Yes. You have to git commit.

You do that by typing git commit. And if you just type git commit, git is going to yell at you because all commits need what is called a commit message. Now a commit message is a simple sentence that defines, what has happened in this commit.

This way, when you're reading over your past commits, you don't see a list of, okay, 10 files changed or whatever. You see those nice and simple sentences.

Now the upside to this is that you can write really nice commit messages, and commit messages can even be used to generate, change logs and things like that. Or you could just write, get commit messages that are helpful, such as ads, new protections to this feature, blah blah blah. And it doesn't have to be a in-depth or whatever, but it should be descriptive about what the code contains. So that way, when you're you're looking at back on it later, you can say, alright. This is the one I wanna go to. This is the specific commit I want to go to. So you do that with git commit hyphen m, and then you have the string or the text of your commit message.

Yeah. And, generally, those those commit message will be something like add support for IE 6 or fixes.

Often what will happen is you you have, like, a bug tracker, whether that's GitHub or, like a Jira or something like that. And sometimes in that commit message, you'll put a reference to an issue number.

In that way, if you want more information about what this thing was adding or fixing or removing, you can always look that up and reference it in your your project management software.

Yeah. Yeah. There there is, like, dos and don'ts with commit messages, and and sometimes you'll see people that'll that'll post a commit message just as, like, fix it bug.

Okay. That's most of my commit messages.

No.

I hate that. I hate that. Match the keyboard. Yeah. No. I Yeah. For, like, important stuff, I will, but sometimes it's just like I'm building a course, and I just need to make sure that what is up, and I'll just mash the keyboard or whatever. I know that's not the best, but, like, when it's when it's professional stuff, I will do a good message. I should add this. Sometimes I'll be working, and maybe I'll upgrade my npm package Scott JSON. And then I'll also fix something on the Node page, and then I'll also change a price.

Right there, I kinda just hit 3 different things that are totally unrelated.

So if that's the case, what you can do is you can git add package JSON package lock, and then git commit, updated dependencies. K. Those 2 are done. Then git add, index dot HTML.

Git commit, change the homepage, and then git add prices dot JS.

Git commit, change the prices. And in that way, if you're ever looking back at, like, what happened, you know, like, it's not just like, I did these 3 things and I I looped I bunched them all up ESLint 1. You're able to to pick them. And in that case, you don't get add dash a. You just get add the files that have changed.

Yeah.

Word.

Next tool. So we have we've created the repository.

We've added things to the repository. We've written them into stone with commit. Now we're ready to go put those up somewhere else.

Because if code is living just on your computer, then it is basically at any any given point subject to the ticking time bomb that, you know, hardware tech JS. If you bump your computer or your daughter spills something on it or whatever, your son decides to, I don't know, pick it up and slam it down, you are then lost. You know, all that work you just did was lost. So what we then have next is going to be pushing the code. Now you can push a code to any remote location.

It has to be specified as an origin.

So what we first want to do is to get remote add origin and then paste in the long string that either GitHub or any of these other clients may give you these on the web cloud hosting services.

Right? The GitHub is really just a service to host your code on the cloud. That's all it JS, just like some of its competitors.

So we do git remote, add origin, then the long string, and that sets the origin of our code to be living elsewhere out in Git land. And then we do git push origin and then the branch name, whether it's git push origin main to push the main branch, then it all goes up to your origin, and it will live there where you can then have other people pull it down or you can pull it down from another computer or whatever. It is then basically out there living on the cloud.

The origins are just other Git repos somewhere else. So the whole idea with Git repos is that they're decentralized, meaning that, of course, you have your your repo on your computer, but that's not the the main repo out there. That's not the end all repo. You could have another repo on another computer. And if those are origins and if they have the same Git history, you're able to push code from your repo to another. And, generally, you're not pushing you you theoretically could push code from your laptop to your coworker's laptop, but, generally, that doesn't happen because these things are not network accessible. Like, there's firewalls and stuff in the way, but things like GitHub are are network accessible, so you can you can push it up. So there's people that, like, always get, like, bent out of shape when we talk about this whole, like, commit and then push to GitHub because that's where it lives, but that is pretty much how most of us use it at the end of the day. So you it's no problem thinking about it in that regard. Yeah. Totally.

Let's talk about the next one, which is pulling. You you wrote your Node, you push it up to GitHub, and then you have a coworker, or maybe you you went home and your laptop is not the same as your work laptop, but you wanna work on the same project because you are overworked and you have to do evening work as well.

So, what do you do in that in that case? Wes, now the you gotta think about, okay, like, where's the most recent version of my code? Well, you hopefully, you remember to push to GitHub, but at the end of the day and then you can go on your laptop. And if you have the same repo on your computer, if you don't, you can just clone it. We'll talk about that in a second, but you just get pull, and then you you specify where you'd like to pull it from, and it will bring down all of the changes. And and that's key because it's not like downloading the entire repo again, and that can get very, very large, especially if you've got, like like, your Git repo has a list of every single change that has ever happened. So if you've got 6 years worth of it and if some guy in in marketing accidentally get committed a 500 meg video at one point in time, that's gonna be in your git repo, and it's gonna be in your git history. But by git pulling, it will only pull down the very small actual changes, that happened to your computer.

Word.

Let's say you pulled some code in, you fire up that that that project, and all of a sudden, things start breaking in production.

Perhaps you wanna yes. Perhaps you wanna be able to pinpoint the exact commit.

Hey. There's that word commit. Perhaps you wanna pinpoint that exact commit where things went so wrong.

And so you could do that with one of our sponsors today, which is Sentry. Now Sentry at century.i0 is a perfect place to keep track of all your errors and exceptions.

And all of those errors and exceptions JS is very one of these cool, cool services that I've been personally using for a long time and couldn't get along without. Basically, what this thing allows you to do is see every error that your users hitting on your site. Allows you to categorize and see how many times in the past given amount of time span this thing is even happen. Right? JS this thing happened once in the past, you know, a 100 days? Maybe it's not something you need to worry about as much. Maybe it's just somebody's extension going around. Either way, we have the ability to see, categorize, track, log all of our errors and exceptions and see how they're doing. And it's even connected to GitHub or any of your favorite version control managers. So I can create an issue in GitHub from Sanity, then somebody else can come in and fix it, push that code up to GitHub, fix it. We can Yarn it as change and say, hey, it was fixed in this particular commit. That way, when it breaks again, we know who to blame. So head on to century at Scott I o. Use the coupon code Sanity treat, all lowercase, all one word, and you will get 2 months for free. Highly recommended.

So let's say you had and by the way, this is no longer the ad transition. So let's say that you Node longer or let's say you wanted to work on some code that already exists in GitHub and you were wondering or GitLab or any of these. You're wondering, you say, I wanna, like, play around with this. I want to try it out or I have some some improvements to to help them out with it. What do I do? Well, this is where the next one comes in, which is clone. Now people who are new to GitHub may head to a specific repositories page. They may see the download button and say, oh, download. Let me click download. They click the download button and presents them with a Node that shows clone with HTTPS along with opening GitHub disk and then downloads it. You're like, okay. Well, I'll do the downloads it. But before you do that, this is the better way, which is to clone the Deno. And we can clone the repo using this string, which is basically the URL to to the repo and you run git clone, you copy and paste the string and you paste it in there, which is the address to the repo.

And what does it do? It fetches the entire history as well as the entire repo.

So that way you can make modifications to it, add them, commit them, and push them back up. And then then we get to do some of the cool fun stuff that we're gonna be talking about next.

So next, we have branches.

Branches are key for working on features.

Or if you want to like, right now, I'm working on my master Gatsby website, and I'm at the same time, I'm also upgrading a couple of the back end components.

I'm I'm doing a little bit to the the bundlers, and the whole site is sort of in development right now. However, I need to keep, like, a a working copy of the website because sometimes what happens is I'm in the middle of building a feature, and then I have to jump back to the main website and fix something really quickly. So if I was right now, the current branch that you get by default and get is called master, but they are talking about changing it to main. I think they already did. Did they?

I haven't seen that yet. Well, then maybe they haven't, but I I my my neural, or at least my current repos are a main. Oh, cool. Yeah. It was just there's a github.comforward/githubforward/renaming.

Just showing some some stuff about some tips on on how to actually change to your main repo instead of master repo. Okay. Cool. So if I have everything in my main branch and I wanna work on this feature, I will switch branches, and that will allow me to edit all of the files and whatnot. And and by switching to a new branch, it basically it doesn't take a copy, but it gives you your entire website. You can make changes to it. You can add. You can commit. You can even push to your branch on GitHub. However, if you need to go back to what the website was at any time and and work on that, you can it's called checking out. So you can check out to your your master branch again, and then you do a quick fix, and then you can jump back to, the feature that you're working on. You can check out that branch, and you can go back and forth. And then the the whole idea is that, at a certain point, that feature will be done, and you will merge, which we haven't talked about yet. But you basically, you'll take those changes

and sort of feather them in on top of your your main branch that you have. Does that make sense? I think so. Yeah. To me, that definitely makes a lot of sense. So you way you can think about it JS, like, they often illustrate this in train tracks or whatever. Maybe you're going in Node specific direction. You wanna branch out. You go slightly different direction. Right? So you're now on a whole other train track, and then you can bring that other previous train track or any sort of changes that's happened to your code. You could bring that into the current one or you can bring the current one into the other one. There's some fancier stuff with rebase or whatever, but I think for Git Fundamentals, we should stay away from rebase.

So this is really the the standard flow that you'll see a lot of people working with is is merging of code and checking out branches. Okay.

Actually, I aliased my checkout to be branch, and I aliased get checkout hyphen b to b new branch, and I've never used them. I Node these aliases thinking they'd be like, oh, yeah. This makes so much more sense. Unfortunately, I, I just never remember. So I always just do git checkout b, whatever.

So we have the ability to check out, create new branches. We have the ability to then code with Git merge. Now sometimes you end up having what are called merge conflicts. That's when the two lines of code or perhaps many more than that, they're butting heads in terms of maybe these 2 things were changed at a similar time, and they're not compatible.

And whatever it JS, is that the code, the computer Sanity understand the correct way to merge this code together and have it work or make sense. Right? It just doesn't understand which thing is the most recent version in in terms of, like, correct everything. It it it's not a perfect system, so it's not always going to magically understand exactly what you want to merge. And you will have these things where you have to go essentially line by line to determine or group by group which code you would like to use. And sometimes you wanna use both, so you end up doing a little bit of merge or let's let's merge both of the lines or whatever and then modify it by hand. It's not always a perfect system, and merge conflicts can be the bane of one's existence when working in Git, especially for those who are brand new to this.

Yeah. We should say, like, I I don't know if this is obvious or not to people that are are new to Git, but Git literally tracks every single character that has changed inside of its files, not just what files change. And if you're like let's say you crack open a 30 line CSS file, and right in the middle of that CSS file, you add a new selector with some new properties and values. Git is smart enough to know, oh, you added this. Let me just slip that in. If you were to merge it, it says, oh, yeah. You're just gonna slip this in. However, if you had, like, like let's go back to the example I was just talking about with branches Wes I'm working on a feature. I changed the background of the home page to red.

And then, while while I was doing that, somebody else or or even myself went to the master branch or the main branch and changed the background to be blue, and then I tried to merge that branch into my main branch, then it's gonna say, okay.

There's 2 changes here. You want red.

It's currently blue, but it was green initially.

What do you want? Like, do you wanna do you wanna keep this existing Node? Or yeah. Or do you wanna keep it? And and if that's the case, then you have to manually jump in there or, open up those diff files in your text editor, and you have to select which ones you want. Or, in my case, usually, I just open it up in Versus Node, and you just delete the parts that you don't want. And you keep the parts you do want, and then you you commit it again saying, I fixed the merge conflict, and then that will then go away. Yeah. Definitely a very common flow of things that you you hit.

Okay. So next we have is GitFetch.

Now when might you use GitFetch? Well, GitFetch is usually used to it it just gets all all everything. Right? That's what it does?

Git fetch is kind of like Git pull, except when you do a git pull, you're pulling the changes into whatever you're currently working on, whatever branch or whatever you're working on. With a with a git fetch, it will, stage. It will pull all of the things from that origin, but it won't switch your branch. It won't make any change. They'll just it sort of puts them in a staging area. So if you want them, you can Yeah. A good,

a good use case for this might be let's say you have a coworker who's working on a specific branch, They might push that branch to origin, and then maybe you wanna modify that branch yourself with them. You could then get fetch, then you would then have access to that branch on your then local. So then at that point, you could then get check out that branch name and have access to that code and push to that origin. And then from there, you'll have access to that branch itself. So that is get fetch. It's not something I use a ton. I do use it occasionally, but I think the larger your team gets, the more likely you might have to use this.

Yeah. That's it's almost like, you can also use it to just cherry pick things that you want. So maybe, like, sometimes what happens is you're working on a feature, and you run into a bug. So somebody else will go and fix that feature, and and then they say, okay. Can you test this with whatever it is you're working on? So now you're in a weird spot where your main or master branch is not up to date. It has the bug. The code you're working on your branch doesn't has the bug, and you don't wanna merge you don't wanna your coworker doesn't wanna merge it until you test it. So if that was the case, then you'd go ahead and fetch their branch and either merge it into what you're working on or make another branch where you're just playing around with it, and then you you run it and test it. And, sometimes if that's the case, you can just merge 1 or 2 of those files that are Node, or you can you can merge the entire thing. But I think that's that's a pretty advanced use case. Totally.

Next is going to be Gitstash, which is basically commonly used on people. I it is funny. I have not used Git stash in a very long time because it's the kind of thing that I felt like I used a lot more when I was 1st learning Git, and you were just, like, giving you made some modifications to some code and then you wanted to pull in some other Node, and it's like, wait a second. You have files that have been modified, but they have not been added and they've not been committed. What what do you want us to do with these files? Because if you pull this in or whatever, there's a chance that these these files are gonna be deleted or, you know, lose your changes. What do you wanna do with them? And sometimes you just wanna say, I don't I don't really care about these changes I made. Maybe these changes I made were superfluous. Maybe they're just, like, not necessary.

So I could do Git stash and Git stash does exactly like what it sounds like. And it pulls up the corner of the rug, grabs your little dust bucket, sweep, sweep, sweeps it right under that rug.

I I like to think of more of JS putting it on the shelf That was on the shelf. For a quick second. And then if you want so what I use this a lot for is sometimes you you clone a repo. Somebody says, oh, can you take a look at this? Okay. You you fork or clone the repo onto your thing. You open it up, and you start working on it, and they go, oh, I just added some more code. Mhmm.

I just pushed it up. And you go, okay. So now I need to pull their most recent version down, but you can't pull when you have what are I refer to as dirty changes, which is code that has changed on your computer but has not yet been added or committed in any way. So if that's the case, then you Scott stash, and that will take all of your changes that you did and bring it right back to the where you had it before you typed a single character.

Then you can do a git pull and and get their latest changes, and then you do git stash apply, and then that will take it back off the shelf and try to put it back on top of whatever you were doing. And in some cases, that that makes a merge conflict, but in in many cases, it just JS is great. So you you sort of just, like, rewind a second, bring it up to date, and then go, okay. Good. Now now let's bring in those changes that I was just working on. Yeah. That's a try. I I have not used it in that way, but that that makes a lot of sense. Alright. The last 1 we have here is GitFork.

This is actually not part of Git. So if you just type GitFork, it won't do anything. But the whole idea is that with GitHub, somebody has, like, a repo. Like, for example, I I submitted a a change to Gatsby the other day so that it would fix something that was was breaking, something on Windows. So what I had to do is I needed my own copy of of Gatsby.

And if I wanted to to work on it, I could certainly just get clone it. But then if I wanted to push my changes back up to GitHub, I don't have I'm not part of the Gatsby team. I'm not allowed to just push changes to Gatsby. So I need my own version of the of that git repo. So that's called Wes Bos forward slash Gatsby. So I made all my changes.

I get out of them. I get committed them. I get pushed them. But when I get pushed them, they go up to my own Gatsby repo.

And then I guess the the last thing we have here is that I can now take my fork.

And the difference between a fork and a branch is that a fork is its is an entire repository that can have many branches, whereas a branch is just Node branch.

And from a fork, you can make a pull request onto the main in my case, it was the main Gatsby repo saying, okay, here are my changes in my repo.

Here is your repo. I'm suggesting that we take my master branch

and apply these changes onto your master branch, or you can obviously change which what the branches are. Cool. That's, I think that's an important piece to to cover here. You often hear people talking about forking. And another thing you're also gonna hear people talking about is pull Wes. This is not an ad transition, even though it sounded it was.

And so we have 2 different types of ways of getting code from 1 branch into another branch or even 1 fork into another fork, And that is going to be the merge or pull request. Now a merge is what happens when you run the git merge command on 2 different branches of code and it tries to merge them. What git pull request does git pull request. There's no command git pull request. What pull request does is it basically allows you to request code to be added. And is this the same do they use pull request in GitLab as well? Is this, like, universal? Because I'm assuming, yes. I I haven't used GitLab in a while, but when I did, it was the the same process. So, basically, what it's doing is it's creating an issue in the repository that says, hey. I have some code here, and I would like it to be added. And whatever your Git client is, whether it's GitHub, Bitbucket, whatever, they give you tools to be able to look at the Node, see what the files have changed, maybe do a little review. GitHub has some really neat stuff where you can do line by line code review when someone can look at it and say, I like this, but I hate this. Now change this because this is no good. You could do all this and then request for changes to be made. People can make those changes. They can submit it again to be pulled. And then with the click of a button, you can say, Wes, please merge this code into this particular branch. So poll request is a bit more formalized version, a bit more of a way to have proper authorization and proper eyes on the code before it is brought into the actual code base. You'll often see pull Wes as being the primary way in which people merge code in large or team based code bases.

We use the words Git and GitHub, and oftentimes, I think beginners may kind of like this as being the exact same thing. Right? Git is just the the interface for working with GitHub. And, no, GitHub is a service online for your code to live. It can do a lot of fancy stuff of which we don't have the time to get into too much here, but there are lots of other ones of these such as GitLab and Bitbucket are the 2 biggest ones.

GitLab is an open source project.

Bitbucket is from Atlassian. I never I never say their name correctly. And so there's alternatives here, and they function very similarly to GitHub, and they have very similar features. So if you aren't down with GitHub and their Microsoft ownership or whatever, feel free to use any of these other ones. I have used all 3.

Personally, I don't know. I dig them. The only reason I drop bit Bitbucket in the general is because they don't have labels for their issues. What's up with that?

Oh, man. Yes. I I use GitLab for almost everything that I do just because my stuff GitLab or GitHub? Sorry. GitHub for everything I do just because, like, that's where all the community is, and that's where most open source is.

However, I believe GitLab allows you to have on-site.

Yes. They do. Because that's that's huge for a lot of these companies don't want to push their entire business and all of the code behind it onto a server owned by Microsoft.

They want to own all of their code in house.

So if that's the case, they have to, yeah, they have to host their own version of the get GitHub type thing,

in house on their own. It's relatively easy. In fact, I think I'm not positive, but this I'm pretty sure DigitalOcean JS, like, a one click install there. So,

definitely something you can do. GitHub does it too. It's called GitHub Enterprises.

Often, you'll you'll hear the the big bucks talking about JS on prem, which means on premises. That's like just like I want to use GitHub, but I want to use that on my own servers. I

got racks of servers that we can work on. Of servers and racks of cache. Let's go ahead and get that enterprise going. Let's talk about common issues really quick, stuff that people hit. We talked about merge conflicts already. They can be confusing. Sometimes a gooey is a nice thing to step in there and help you what's changed exactly.

Again, we talked about a little bit about the Versus Node interface for that. Not great, not always the easiest to parse exactly what what changed. Another one is gonna be files tracked unintentionally, and this goes all the way back to the beginning of the episode where we talked about using a git ignore file. Too often, you create a repo, you do git in it, whatever, and you're all just, like, jazzed on creating the project. And next thing you know, you got CSS stores and who knows what in your repo.

And, unfortunately, those are hard to get rid of.

Once you once you track them, they're not great to get rid of. So, Wes, next comes the next question is, how do I delete this particular file from GitHub?

Yeah. I I have to Google it every time. For, like, 5 years. Yeah.

I have a little alias in my z s h file called g r I, which means git removed ignored. Want that? Just Just because sometimes I'll commit and then go, oh, it didn't get into my git ignore. And that can also be a security issue if you accidentally because even if you delete it from your git repo, it's still in your history. And anyone that has access to that can see it, especially, like like, let's say 3 years ago, you accidentally committed a password to your environmental variable, and then 3 years later, you hire a contractor and give them access to your your Git repo. Wes, that contractor can go back into your git git history and and see that type of thing, so you need to be be very sure. And how do you do that? It's, use git r m dash r, and I have a little little thing g r I. It does git Wes files dash dash ignore dash dash exclude standards pipe XRX.

It's this massive thing. I'll paste it in. It doesn't work all the time, but in a lot of cases, I just have to run g r I, and it will remove the files from the repo and all history without removing them from your local

file system. That sounds great.

Another question people often ask is about, like, maybe along the lines of WordPress or Drupal or like or you have these CMS based sites where people are they they're used to working in a different flow. They get into Git, and they say, well, wait a second. There's so much information in my database. How the heck do I how do I get that into my Git repo? You don't. You don't. That is not the place for Git. There are well, unless, of course, there are certain solutions baked into WordPress or Drupal. I know Drupal has one to call. I believe, is called features Wes you can basically take all of your database stuff and throw them into a written code modules of which then you can commit, push up, and then pull down in your your, production version of your site and have that just work. So you don't store database and get, you probably could try it. I don't think it's a good idea in any regard. So, I would never do that. So that that's a when they're first running into this stuff, because you wanna make sure that your, database data is always the freshest.

That's why you have to find some better way to track it or export it or whatever. And this is an ad transition into FreshBooks.

I'm talking about FreshBooks, cloud accounting software. Wes, do you wanna talk more about FreshBooks software?

Yes. FreshBooks is the small business accounting software that makes billing painless.

It's funny, actually. I have a call with my accountant next week because, taxes in Canada got pushed. Mhmm. Yes. They got get put they got pushed because of coronavirus.

And so I've I've I've put off making my payments because I owe a bunch of taxes. I'm I'm I'd rather it sit in my account and collect interest than than there. So, I have a call next week with my my accountant, and, I don't Node. In February or January, I already gave him all of my, invoices, all of my revenue, all of my expenses, all of my different taxes, all of the different, currencies that I build in because that that's like another thing JS I have to say, okay, Node this much in US. I made this much in Canadian. I made this much in pounds.

And then he has to report those as as income to the government in Canadian dollars using some posted rates and whatnot. So it's just there's a lot going on running a business. It's very complicated. And, like, the one thing you don't want us to be in trouble with your taxes. So, having nice clean books is key. So check out FreshBooks .comforward/ syntax, and make sure you use syntax in the how did you hear about a section

for the next time that you, need to send in voice or track your time or any expense that you have. So maybe you, need to track one of these expenses to buy Git Git client because a lot of these, you have to buy because they're nice software. Now Git client or Git UI is going to be a software that could help you with all of these things, whether it is seeing your project to better in terms of what's committed and not or just simply giving you really neat little graphics into, the path and branches and all those things that happen within your code, the history of it. Now there is a massive amount of Git clients. I've included a link from Git's own website sharing some of these. And, some of them are prettier than others. Some of them are intentionally not like pretty, pretty, pretty. But if I'm gonna go away from the command line and get into a client, I want a pretty I want a pretty app. And for me, I think the the prettiest one is going to be the GitKraken. Although I see you have under Git clients, you also have CLI. So you're you're thinking that a a Git client is also a CLI. I I'm pretty sure you're accurate on that. I'm not.

Yeah. Any client is something that adds additional ease of use or features on top of what the Git command line already already has. So there was a popular one called GitHub for the longest time, but Git, probably about a year ago released their own CLI. It's called GH or GitHub. And you can brew installer, I don't know, Windows. You can buy like a CD ROM or something like that for Windows. Oh, and install it.

It allows you to do the stuff that's not part of Git, like pull requests and issues and repos and all that stuff. It allows you to do all of that via your command line. I've actually installed it and never used it because I just I just use the website. But, like, some of this stuff is old habits die Yarn, and I should probably be checking it out. Same with me. In fact, as we Yarn doing this episode and not as we're like, right right now now, I just downloaded

GitKraken because, hey, woah, Wes, did you ever realize that that Node, like, let's get cracking? Oh, I didn't realize that at all. Because it's spelled the Kraken with a k, just like the, the Seattle hockey team, which I'm wearing their hat of currently currently wearing a Seattle Kraken hat. Wow. This is a lot of layers deep here. So I, I'm gonna give Kraken a try because it is the prettiest of the bunch. And,

there's a whole bunch of these, man. These things go all out. GitHub Desktop is super good. I use that for a while, and we also use that when we were we were teaching because it's super easy for beginners to just visualize what's going on. There's a sync button as well. I think I was if I could remember,

because, like, pull and push and all that kinda hard. But if you just press Wes sync button, it'll ask you for a commit message, and it'll zip them up to the Internet. Yeah. Check that one out as well. These are all cool. I'm gonna I'm gonna try to give some of these a try. And if you type in ESLint Versus Node extensions, there's just, like, about a gazillion of them. So there is a lot of options out there for people who are visual workers.

I personally would say, hey, if you are the type of person who really likes a good g y, still try to try the command line because the command line is where it's at for this stuff. I really think that you'll want to you'll you'll want to spend the time to learn the command line stuff.

Oh, the 1 command I forgot is git status. That if if you wanna, like, know where am I at at any given time, git status. That will tell you, like, what's changed and whatnot.

I always just use the the GUI in Versus Node for that personally. Oh, because it'll tell you what has changed and whatnot.

Cool. But I I think that's a good one because that that is crucial to understanding what exactly has happened here. Cool. So that is it, for Git.

Do you have any additional anything, or should we hop into sick picks? Let's hop into some sick picks. Cool. Sick picks. Well, sick picks are the section of this show where we get to talk about things that we find to be sick.

Do you have any sick picks that you are just dying to talk about? I do. And I sick pick this. This is another one of my sick follow ups. I don't know. Node, like, 2 years ago, I sick pick my Yeti Rambler or whatever it's called. It's like a it's a mug, a coffee mug with a nice handle, made by Yeti. And whenever anyone buys anything Yeti, people always roll their eyes because it's super expensive, and it seems unnecessary given that the alternatives are often a third of the price. The culture's kind of too. That might be a turnoff. Yeah. The there's quite a bit. There's, actually, there's this, the Instagram called, I won't say it because there's kids listening, but s h I t I. And it's like you have this, like, badge that you can get for your crappy Coleman cooler and slap it on, and it looks like a fake Yeti. Anyway That's fine.

Their cups are, like, double walled stainless, and they keep your drink hot for for absolutely ever. And that's Scott, like you can go to Target and this is a 100 of these things. Like, sucking air out of 2 stainless steel things is not new. But I was just looking at our entire cupboard of these cups, and every single one, the Ozark Trail ones, the ones that I got out of conference, the whatever. Like, the knockoff ones that you get, all of them are peeling and faded, and the paint on them just doesn't hold up at all. And I put them all in the dishwasher because, like, I don't have time to hand wash it. And the Yeti one is the only one that looks almost brand new Aside for a couple of scrapes that I've had just from dropping it and whatnot. So I'm going to go out on a limb and the coolers might not be worth your money versus the knockoffs, but the the drinkware absolutely

is. That's pretty sick. Yeah.

Yeah. Cool. My sick pick is going to be a podcast. I love me some podcasts. I'm a big, big fan.

This is a podcast for music fans, and I I'm gonna have a lot of podcast picks here. So if you're not a music fan, don't worry. I'll get you next week. So this podcast is I've been I've been discovering a lot It's called What Had Happened Wes, and it is featuring the legendary Prince Paul along with Open Mike Eagle. And if you're into music of any kind, this is a really, really fascinating podcast. Because, if you never heard of prince Paul, he's a a famous rap producer, but he's been around for a long time and been a part of some very, very, very influential projects. And even JS, like, crossed over not necessarily crossed over, but he, like, really or he really took the like, the sample based music to a place that it hasn't been. He's extremely influential from all of the Node La Soul albums. He won some Grammys doing the Chris Rock albums, and he's done so many so many great thing. Handsome Boy Modeling School Wes like a really huge project with a bunch of mainstream rock artists and a whole bunch of cool stuff.

But this podcast is called what it had had what what had happened was and it's each one is, like, sort of an hour or so on different moments in music history of some of the biggest, most influential albums that existed, and Prince Paul is just, like, the most humble, down to earth guy. The the personalities really make this podcast because he can talk about these events, and he just seems so grounded and normal and humble and whatever into the point where it's like, it's absolutely fascinating to hear somebody who who JS, like, originated so many different things. Just be like, oh, yeah. That Wes just sort of my style. So I was just doing like this and do it like this. And these these do we did this and we just went and tried this. It was just it's very fascinating look into the music industry, he has a lot of thoughts on. So I had what what had happened was my new favorite podcast, and it's like a limited one kind of thing. So, I think there's only gonna be 10 episodes.

So shameless plugs, what do you got for me? I'm going to shamelessly plug either my current or upcoming course.

Mastergatsby.com is going to be my next course, which is learning React Gatsby.

We do all the CSS in it, which a lot of people have been asking for for a while, serverless functions, lots of custom React hooks, things like that. It's a really fun one. I'm really excited about it. I'm pretty proud, so check it out, mastergatsby.com.

Cool. I'm gonna shamelessly plug my latest course, which is going to be, React Node zero one. Essentially, it's going to be React for everybody, but it's going to be brand new from the ground up for Wes twenty and beyond. For as far out beyond as possible, we're gonna be doing a hooks first approach. We're gonna be teaching react to brand new people. So if you are interested in learning react from me, this will be like my 5th time doing a react basics course. I'm very excited. I have a lot of material and a lot to say about the basics of React. Head on over to level up tutorials.comforward/prosign up for the year and save 25%.

Beautiful. I still appreciate you not calling it React for beginners.

Yes. Yes. That is yes. That is the story of how Wes and I met. React React for Everybody. That's my brand. Deno pnpm anybody stomps on the Everybody brand. I'm I'm there used to be, like, grumble about it.

Awesome. Alright. I think that's it. Thanks so much for tuning in, and we will catch you on Monday.

Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to