Git It? How to use Git and Github

[Music] when it comes to development most tools that you come across have a limited shelf life but despite this constant churn there's one thing that remains consistent and that's good it's easy to take it for granted but when you take a step back you'll find that git has completely revolutionized the software world it's essentially a history book of your code and services like github make open source software accessible to the world in today's video I'll show you the basics of get along with some advanced pro tips and I'll even invite you to collaborate with me on a pull request on github in exchange for a free sticker I think that's a pretty good deal so if you're new here like and subscribe and I'll give you further instructions throughout this video so what is get exactly it's a version control system but really what that boils down to is a system for managing your files building software is a series of small milestones where each milestone is just writing code and a bunch of different files your app will constantly move from a state of chaos to stability and gate gives you a way to keep track of all of these changes and it does so in a way that allows you to create multiple branches or paths that you can go down and then merge them in later facilitating collaboration between large groups of developers so today I'm going to show you how this all works by building a piece of open source node software that we can all collaborate on the software itself is a command-line utility that will allow you to encrypt your mailing address and then add it to the github repo so I can mail you a sticker in my current working directory I just have an index J s file and a package.json I'll go ahead and click on the source control icon and you'll notice it says no source control provider is registered the first thing we'll need to do is initialize get to start tracking our files and there are two ways we can do this we can either do it directly in vs code or we can do it from the command line you should definitely try to memorize all the commands I show you in this video but it's often faster to run them with vs codes integrated tooling and I'll show you both methods throughout this video so first we'll go ahead and run get an it from the command line and you'll see that initializes an empty git repository in our current working directory you'll notice it adds our two files to the changes list in the source control panel so this tells us which files have changed since the previous snapshot of the source code because we're in a brand-new project both these files have a u icon which means untracked or that their newly created on this working directory now a quick pro tip when you initialize it get repo it creates a hidden get directory if you want to completely uninitialized it or remove it from your project you can just remove that directory but be careful with that one now a second pro tip is to install the get lense plugin for vs code it embeds all kinds of useful information directly in your code and gives you this extra panel where you can easily navigate your git history the next important thing when setting up a github repo is to create a git ignore file you don't want everything in source control for example you definitely want to keep out any sensitive private API keys and you'll also want to filter out the source code for your dependencies like your node modules and any unnecessary log files git will automatically look at this get ignore file and filter out anything that matches the file path or pattern you can create this file manually but the pro way to do it is to use AVS code plug-in to automatically generate all the defaults for your environment so that saves us a bunch of time and now we can move on to the next concept of how do I take a snapshot or a commit of my current working directory a commit is like a page in a history book that has its own unique ID and can't ever be changed without get knowing about it the first thing we want to do is stage the files that we want included in this commit use stage files by running git add and you can add individual files or the entire working directory by just using a period and BS code makes it really easy to stage or unstaged files by just clicking the plus or minus button and you can unstaged files from the command line by running git reset but be careful with this one because there's a hard flag and if you use it it will not only unstaged the files but delete them forever so if we run that one right now on our new project it will delete everything and we'll have to start over from scratch and with that I'll give you one of my most important pro tips which is to make many small commits this practice will not only help prevent catastrophic losses of code but it will also just make your code changes a lot easier to follow now we're ready for our first command the first thing we want to do is run git add to stage our files then we run git commit with the EM flag to add a descriptive message about what we changed in our code a pro tip here is to use an emoji to get more github stars on your project because github stars are the best way to tell how good a software project really is and you can also make your comments multi-line to provide a summary on the first line and then a more descriptive set of changes on the second line you'll notice that that takes the files out of the stage changes and gives us a clean working directory and it will tell us exactly which files were created modified or deleted as part of this commit now if we go into our git lens plug-in you can see we have a history of code changes that we can navigate through and see exactly which lines of code changed up until this point we've been working on what's called the master branch which is like the main trunk on the tree that contains the actual source code that you're releasing and delivering to your customers so what happens when you have a stable code base and you need to fix a bug or you want to experiment with a new feature what you'll typically do in git is create a new branch based on your most recent commit and go and fix the bug on the separate branch and then merge it back into the master branch once it's ready this means we can have multiple developers working on the same code base on their own branches without stepping on each other's toes you can see all the current branches in your codebase by running git branch which for us would just be the master you can switch between branches and get by running the check out command in our case the branch hasn't been created yet so we'll go ahead and create it by using the be flag and we'll give it a name of feature so now any code that we write in here will be isolated to this branch now we can fast forward into the future and you'll see I've written a bunch of code in this branch so currently this code is just sitting in the working directory so I need to commit it to this feature branch this time I'll run my commit directly in vs code and then we can switch back to the master branch and you'll see that all of our new files disappear and we're back to the original state on the master at this point I'd like to point out that you don't necessarily have to commit your files before switching to the master branch there's a another mechanism to save your work in progress if you're working on something that's half-finished or experimental you can use a command called git stash this will save all of your current changes without committing them and then revert back to a clean working directory then later at some point in the future when you want to get back to work you can either pop or apply the changes in that stash to your current working directory so kind of just like it sounds you're stashing away your current changes to be used at some later point so stashing is just a handy thing to know and an alternative to committing your code if you're not quite ready to do so in our case we're all done building our feature so what we want to do now is merge that feature into the master branch so now we'll go ahead and check out the master branch and then if we run get merged with the name of our feature branch it will merge the latest commits from the feature into the master and you'll notice the commit ID is the same for both the feature and master branch so that was a pretty simple use case but merging is the place you're most likely to run into problems because you might be working on a feature branch and then the master branch has changes that eventually lead to merge conflicts on the Left we have a line of code that we implemented in our feature branch and then on the right we have a new change that happened in the master branch while we are working that affected the same line of code so merging these files is not possible out-of-the-box because git doesn't know which change to use the S code will give you some options to resolve these conflicts for example you might accept the current change accept the incoming change or Bowl when you run into a conflict you'll want to first review it and then a lot of times it's best to just abort the merge all together and fix the files manually I already mentioned that it's a good practice to implement a lot of small commits because it's easier to fix a conflict on one file as opposed to a hundred files then in the previous example we merged a feature branch into the master branch but a lot of times when you're working on a feature you'll want to merge the master branch back into your feature to get the latest code because if something on the master branch changes it means someone could have been writing code in the same place that you're writing code or there might be some breaking changes that changed the way your feature is going to work so if you're working on a feature for an extended period of time you'll want to merge in the master branch any time it changes or maybe once a day if it's a really active repo now there's one last pro tip that I want to give you that's related to merging a lot of times on a feature branch you'll create a lot of different commits and these commits are kind of irrelevant to what's going on in the master branch you can see here that our feature branch is three commits ahead of our master branch and it has a bunch of comments about adding useless emojis to the code instead of merging all of these commits into the master branch you can use the squash flag to squash them down into a single commit when you do your merge this will keep the change history nice and concise on the master branch but still preserve all of the original commits on the feature branch itself when you merge with the squash flag it won't actually change the head commit on the master branch so you'll need to add an additional commit on your own that says something like merged in feature branch and that gives us a nice compact change history on the master so now that we know how to do all this get stuff locally let's see how we can do it remotely with github pushing a repo to github is actually really easy first we just need to create a repository on github and then it will give us the commands to run to push our code to this location the first command is get remote which connects your local code to this remote repository and the second command is get push which will actually push the files to the remote repository so if we run the commands and then refresh the page we should see our code is now on github that was super easy but the next thing I want to show you is how to take someone's existing code fork it create some changes and then create a pull request to merge your code into another person's project and that's exactly what you'll need to do to get the free sticker so this is the typical pattern that you'll see when contributing to any open-source project step one is to fork the existing project forking will copy the code from the source and make it a repo under your own github account after you fork it you'll then want to clone your fork to your local machine so you can start making changes to it the git clone command just allows you to copy the code from a remote repository to your local computer once you have that cloned you can open it up in vs code and in this case serial first want to run npm install to install the dependencies then you can run git checkout flag be with my sticker as the branch name which again will create and move you into this new branch and then i've added a special command to this repo called npm run address and that's going to prompt you for the information that i need for your mailing address when you're done with that it will print out an encrypted base64 string from there you'll go into the stickers directory and create a new file that's your github username dot txt then you'll copy and paste this encoded string into that file so just a side note on security your address is going into a public repo but it's encrypted with the RSA algorithm this means that you are able to encrypt data with the public key but I'm the only one with the private key that can decrypt it I have the private key on a thumb drive which I'll destroy after this giveaway and hacking the private key by brute force is essentially impossible unless someone physically steals the private key your address should be safe in this public format but I do feel obligated to give you that disclaimer first now go ahead and save the text file then run get ad and get commit with whatever message you want to put in there now we have all of the necessary changes committed on our local machine we'll need to push this branch to our remote fork for that we can just say git push origin with the branch name and that will push the branch to github then on github you'll see the option to create a new pull request a pull request is just like a merge but it has the additional step of needing to pulling the remote changes in other words a pull request is like saying pulling my remote changes and then merge them into the master branch so that's how you contribute to an open-source project I'm gonna go ahead and wrap things up there hopefully that leaves you with some of the basic tools needed to contribute to open source software there's a whole lot more that can be covered on this topic so let me know what you want to see next in the comments and if you want to get really good at this kind of stuff consider becoming a pro member at angular firebase com thanks for watching and I'll talk to you soon

Channel: Fireship

Views: 279,828

Rating: 4.9294963 out of 5

Keywords: angular, firebase, webdev, app development, typescript, javascript, lesson, tutorial, giveaway, sticker, git, github, git tutorial, github tutorial, how to pull request, oss, oss contribute, how git works, source control, version control, semver

Id: HkdAHXoRtos

Length: 12min 19sec (739 seconds)

Published: Fri Oct 26 2018