Speaker 1: So today I want to talk about Git and GitHub, but specifically through the lens of beginners. Because the pathway to learning Git and GitHub for somebody who isn't comfortable with command line interfaces or the file system and is just new to programming and version control in general is not very friendly. It's confusing, it's intimidating, and it can be depressing. So we're going to fix that today. I am going to cover some basic terminology, how Git basically works, and then we're going to jump over to a demo where I'm going to show how to set up a repository on GitHub, and we will use GitHub Desktop to push and pull files to that repository. And as a solo learner, that is really all you need to know how to do to get started. There are a lot more advanced features in Git, but they're mostly relevant to working in teams and professional teams and doing rollbacks and things like that. As a solo learner, you do not need to know those things right up front. So we're going to cover just the basics and get you started with the minimum amount of pain that I can manage. I'm Eric Wise from Skill Foundry, where we teach people how to code the right way. So before we jump into specifics of Git and GitHub, we need to talk about versioning. So what is versioning? Versioning is just a fancy word that means that we're going to track changes. And specifically, we're going to take snapshots of these changes. So when we make changes to a file, we are going to take a snapshot so that we can go back to it and view the changes in our history. And if we did something we didn't like that we regret, we can roll those changes back. So this is just a history of our files. That's what versioning really means. Now, Git is a version control system or VCS. Now, that's just a word for a program that manages versioning. And Git is really similar to other version tools that you might be familiar with, like Google Drive or Dropbox or OneDrive. So if you install these tools, you can have folders on your computer. And as you make changes to files in those folders, they get synced to the cloud, usually automatically. Now, the difference is in a version control system like Git, it's specific to what programming teams want to do. And the syncing is typically done manually. You generally do not want your changes every time you hit save on your local machine to go commit to a repository that a team of programmers is sharing. Programmers tend to be more deliberate about it. So we manually set our checkpoints and sync up to the master repository. So what is GitHub then? Well, GitHub is a service that is built on top of Git. So Git is an open source project. It does version control management. GitHub is a cloud service owned by Microsoft that runs on top of Git. And basically, they're just managing everything for you. They own the servers and the hardware and they do all the backups and everything in your repository so that you don't have to worry about that kind of stuff. And GitHub is a pretty ubiquitous term because it's the most popular host for Git solutions. But you don't have to use GitHub as your host. There's other hosts like GitLab that you can use, or you can even host Git yourself on your local server or a NAS drive or your own machine. However, in the modern days, most people don't do this unless they're working on something that has some security concerns that would prevent it from being hosted in the cloud. Because setting up and hosting Git yourself, it requires hardware, it requires a backup strategy. That kind of stuff is a big pain in the butt. So most people just go to a cloud host like GitHub or GitLab to service their Git needs. Now let's talk about how Git works. And the way Git works, specifically through the lens of GitHub, is that up in the cloud, you have a container of all your files that has a name. And these containers are called repositories. And in that repository, you might have some web files like index, app.js, styles, whatever. When a new developer comes onto your team, the first thing they do is clone the repository. And cloning means we take a copy of what is current in that repository. And then the developer gets to work. They start making changes. They might edit files, they might add files, they might remove files, you know, any sort of changes they want to make to this repository structure, they can make those changes. And when they reach a point where they want to take a snapshot, then the developer will commit those changes and then push them up to the GitHub repository, and their changes will become the new master that everybody shares. Now let's talk about some common Git commands that you'll need to be aware of as a beginner. And the first one is clone. And all that does is download your initial copy of a repository from wherever it's hosted, like on GitHub. Cloning is one-time use. You only have to clone one time. It pulls down everything, it sets up Git for tracking, and you're ready to go. Adding means adding a file to a commit. And you're going to do this one time per commit. So every time you make changes to a file, and you would like it to be committed, you are going to add it. And this gives you some flexibility, because you only have to add the files that have changes that you want to commit together. So you can be working on a lot of different things simultaneously, and only add the things that are relevant to a group, or a bug fix, or a feature request, or something like that. So you can be very granular with what you add to the commit. And a commit itself just stages changes with a message. So when you add something, it puts it into a commit. A commit is just a group of changes. Now the message you give it, it should tell other developers what you've been working on, and why. And if you're in a professional environment, you might even have ticketing systems where features and bugs have ticket numbers. And then your commit message will usually reference that, like iFixBug number 157. But either way, a commit is creating a snapshot or a version. And once that snapshot is created, you need to push it up to the repository in the cloud. So that's going to update the server version. And then your teammates are going to pull that version down, which pulls all the commits from the repository. And surprise. That's really it for beginners. If you're a solo developer, that's all the terminology you really need to understand. But I do want to cover a few more things, just kind of foreshadow some things that if you get into a professional environment, you're going to be faced with. And the first thing is called a merge conflict. So here's the scenario. You're working on a development team. And developer A changes a file, they commit it, and they push it up to the shared cloud repository. And then developer B comes along, and they have not pulled from the repository. So they're working on the older version of the code. And they happen to go in and change a file that you already changed. And then they commit it, and they try to push it. And basically what happens is GitHub, up in the repository, it sees these changes come in, and it looks at it, and it says, oh, both of you made changes to the same file. And developer B, you were working on an older version. So guess what? Now you need to tell me what you want to do. Because we have a conflict. You've both made changes to the same file, and you weren't in sync anymore. So developer B has three choices. They can either take developer A's version. And sometimes you might look at that, and you're like, oh, you know, we actually accidentally worked on the same bug. And developer A fixed it. It was fine. So go ahead and discard my changes. Or two, you could say, well, my code is better than developer A's code. So I'm going to overwrite their changes. Or three, you could manually merge the changes, which means edit by hand. Sometimes developer A changed some things, and developer B changed some different things. And you just need to work that into the file, and make sure that it didn't break anything. And then you commit it, and you push it again. Now the other Git concept that's a little more advanced that you'll run into is called branching. Now in branching, we have a specific scenario. We're working on version 2.0 of our software. And this is something that's going to take us a long time. And we still need to be able to push and pull and commit changes to version 1 while we work on version 2. And there's going to be a lot of changes. So what you can do is you can tell Git to create kind of a secondary repository. So you take a snapshot of your repository, and it's called a branch. And what happens then is you have the original master repository and the branch repository. And your developers can switch back and forth which repository they're working on. And when they're finished, they can merge that branch all at once back into master. And this is why you need to learn about merge conflicts. Because when you do this, you're usually going to have merge conflicts. But branching is really good for a longer style project where you have changes that you want to be able to stage and work with, but you don't want to push them live yet. So usually this is new features, it's extended bug fixes, it's new versions of the software. That's where you're going to run into branches. And with that, I think we're ready to jump into a demo. So the first thing you need to do if you want to get started is you need to create an account on GitHub. So when you go to the GitHub landing page, you know, they change this all the time for marketing, so it may not look like this. But you basically just want to put in your email address and sign up for GitHub. Now I have my browser in incognito mode so you can see that. But when I go to GitHub because I'm logged in, I get my dashboard view. And your dashboard will show you some news and things about repositories that you're following and stuff like that. Now the button you're going to be looking for is new. Or you can just go to github.com slash new and this allows you to create a new repository to store your files in. And the first thing it asks you for is a name. You should use a descriptive name. Now I've been meaning to create a repository for my YouTube videos because I've been doing these code demos and tutorials and people have asked, you know, can I get the source code? So I'm going to kill two birds with one stone here and I'm going to create the YouTube repository that other people can download my code samples from. So I'm going to call this SF YouTube code. And this will be the Skill Foundry YouTube code samples and demos. And that's all we need to start. You can choose whether you want your repository to be public or private. And if you're a beginner, if you're just learning to code, I recommend you create a private repository. And this is where you do your experimenting and you can push and pull and save your projects there. And then eventually when you want to create a portfolio for employers or other people to view, create a new repository and make it public and copy the stuff in there that you want to showcase. The next option is to initialize it with a readme file. A readme file just is default text that shows up on the GitHub website. So when somebody goes to your repository page on the GitHub site, the readme file will be displayed and you can put marketing information or stuff about you or your repository in there. Like I'm going to put information about Skill Foundry and my courseware in there because I can promote using the readme file. And the next thing is the git ignore. Now this one's a little interesting. I mentioned that we add files when we want to track changes to commits and it will make suggestions in GitHub Desktop about things you might want to commit. There are files that are created in programming projects that you might not necessarily want to push to the cloud. These can be things like compile settings or settings that are specific to your IDE and other things that developers on your team probably don't want to pull down. So what you can do is you can add a git ignore template that will specify certain types of files that are commonly ignored by developers that they don't ever want to push into the repository. Now for example for my C Sharp stuff I'm using Visual Studio. So there is a Visual Studio git ignore. It has a bunch of these for common languages and tasks and I suggest you pick one for whatever tools you are using. This is just a text file. You can open it. You can see how it works. You can make changes to it. All it does is make your life a little bit easier by not letting you commit things that generally aren't committed. And then the last thing is to choose a license. The license is good for open source projects. It specifies how people can use your code and what they can do with it. Whether they can make money off of it. Whether they have to attribute things to you. I usually do the MIT license or the GNU license. If you want to know more about that there are videos and resources out there that tell you the differences. I'm going to use GNU public license for this. And then you hit create repository. And now you're ready to go. Your repository is created in the cloud and it is ready to be cloned. And you can see that the readme showed up on the main page here. We also see that we have a git ignore file, a license file, and a readme file. Which is what we specified during the creation. And now we want to pull it down to our local machine so that we can make changes and work on it. And this is where GitHub desktop comes in. So you're going to want to go download the GitHub desktop software. And the installer is very straightforward. And then you're going to log into it. And what you're going to see is something like this. Let's get started. I removed all the repositories from my machine so that you could see kind of how this looks. And what you're going to want to do is clone a repository from the internet. And when you do that you have a couple choices. You can use github.com, github enterprise, or just a URL. The URL will work with any provider or any host. But we're using github.com because it's convenient and easy. And you can see here that it lists all the repositories that are in my account. And I have some courseware things and things like that in there. But if I refresh this because I just created this file. Here is my ESY SkillFoundry YouTube code. And then what it asks you is where do you want to store it locally. Now I usually create a folder called git on my local machine either on my C drive or my D drive. And that's where I put my code. So you can hit the choose button. You can pick any directory you want. Do not put your code in a cloud backup directory like OneDrive or Google Drive. Do not mix your versioning systems. You will regret doing that, I promise. Make a folder outside of OneDrive and those other tools. Name it git and it will basically create a sub folder in that directory where it will put your code. And then when you hit clone it will just pull it down. And now up here you can see we have a selection list. And my current repository is my YouTube code. And I can do a lot of things to this because there's no local changes right now. I can open the repository in an editor. I can view the files in the Explorer which is what I usually do. Or you can go back to GitHub. So let's go ahead and hit show in Explorer. And it's going to open up my file system. And here are the files that are created. And I'm going to go into the README. And that's going to open it up in my editor. And it wants to update. And I'm going to tell you no. Remind me later. Bugger off. So here we are in my editor editing the README file. And I'm going to call this Skill Foundry YouTube Repository. And there's my directory. And I'm and there's my description. That's all good. I'm going to save the file. And now I've made changes. So let's go back to GitHub Desktop. And you'll see here that it says there's one change file. And it has check boxes here. These check boxes are git add. Behind the scenes it is going to run the git add command. And if I have multiple files that I've made changes on and I don't want all of them to be committed together, you can just uncheck the boxes of the ones that you don't want to commit. But right now it's one file. I would like to add a commit for it. I'm going to say I updated README. And if you want to put an additional description you can. And then I say commit to main. And main is what we call the main repository up in the cloud. It's not a branch. When you get a branch it's going to have a different name. When you're working with your own repository as a solo developer you will usually not have branches. So we're going to say commit to main. Everything's good. It was committed. And then you see this updated and it says push origin. Now origin just means the URL up there in the cloud where your main repository is stored. So I can hit push. And it's pushing it up to the cloud. And everything's good. I come back. I refresh. And there you go. You see the README file did get updated. And now if other developers are sharing this repository they can come in here and they can say fetch. And all fetch does is check to see if there are changes. And if there are changes that will change to pull. And then when you hit pull the new changes will be pulled down. So if you're following my YouTube channel and you want to grab all my code for my C sharp tutorials what you should do is after I launch a video you should come in to GitHub desktop and you should select my repository in the drop down. And then you should say fetch. And it should show you that there have been changes. And then when you say pull those changes will come down and be stored locally and you can view them in your explorer. Now one thing I will recommend because this is version control and it's tracking changes you will not be able to push your changes up to my repository. By default it does not allow that. So when you want to make edits to my code I recommend you copy those project files over to a different directory make all your changes work on that in your own version in your own space. Because otherwise if you make changes to my code in my repository and you pull down new things and I've made changes you're going to get merge conflicts and things are going to be all wonky. So pro tip copy things to your own directory of mine when you want to work on them. Now interestingly enough I'm going to delete this repository. So we'll remove it and I'm also going to send it to the recycle bin. So now it's gone. I got that repository from GitHub. So when I created it from the internet because it's in my account I was able to see it in this list. Now you folks at home if you're going to clone somebody else's repository you can go to the URL where it's hosted and then right here where it says code open with GitHub desktop. You click that you say open it it puts in all the URL information that you need and then you clone and you're good to go. And that's really all you need to know how to do as a beginner to get started with GitHub. You can create a repository. You can commit push and pull your code to that repository. And if you want to look at other people's code like mine you just go to the repository website and you download it with GitHub desktop. That is the easiest path. Now there is a command line tool and I do recommend that someday you learn how to use it. But it is not important when you are just first getting started to code. Just take the easy path. You want to focus on learning not wrestling with a command line interface. And in fact I'm going to make a confession and a lot of experienced developers get pretty snobby about this. I don't use the command line interface in my day-to-day workflow. I don't like it. I like having a visual interface. I like clicking things. I like seeing visual changes and things like that and I don't particularly enjoy the command line interface. So if you never decide to do that it's fine. Don't let anybody make fun of you. IT people can be pretty snobbish about their tools. Don't buy into the hype. It's about what work you get done and how effective you are not necessarily how you go about using your tools. So I hope this helped demystify and lower the intimidation of getting started with Git and GitHub. Happy coding.