GitHub Basics Made Easy: A Fast Beginner's Tutorial!

so today I want to talk about git and GitHub  but specifically through the lens of beginners  

because the pathway to learning git in GitHub for  somebody who isn't comfortable with command line  

interfaces or the file system and it's 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 roll backs 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 me 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 one drive so if you install these  

tools you can have folders on your computer and as  you make changes to files in the 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 get yourself on your local server  or a n 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  

get 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 git lab 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 appjs  

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 onetime  

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 I fix bug  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 rep 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 uh 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 any more 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 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 one while we work  on version two and there's going to be a lot of  

changes so what you can do is you can tell git  to create kind of 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 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 neww 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 get 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 g  ignore template that will specify certain types  

of files that are commonly ignored by developers  that that they don't ever want to push into the  

repository now for example for my C stuff I'm  using visual studio so there is a visual studio  

get 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 the  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 gener 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 rep repository is created in  

the cloud and it is ready to be cloned and you can  see that the read me showed up on the main page  

here we also see that we have a get ignore file  a license file and a read me file which is what  

we specify 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 UR L 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 skill Foundry YouTube code and then what  it asks you is where do you want to store it  

locally now I usually create a folder called get  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 one drive or Google Drive do not  

mix your versioning systems you will regret doing  that I promise make a folder outside of one drive  

and those other tools name it git and it will  basically create a subfolder 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 an 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 read me 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 buger 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 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 checkboxes here these  checkboxes are get ad behind the scenes means it  

is going to run the get ad 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 read me 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 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 ing 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 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 dropdown  

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 I'm 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 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 on 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 get and GitHub happy

coding