Git Crash Course - Feature Branches, Tags, and Checkout Workflow (part 2/3)

welcome to part two of the get crash course last tutorial we talked about the very basics of the git source control tool and in this video we're going to jump into something a little bit more intermediate or maybe even advanced and I'm going to show you a workflow that you can use to develop production-ready software this video is going to be great for anyone who may have already been familiar with git and just wants to brush up on their skills or anyone that's working on a team as a developer and has to collaborate with others on a repository to follow along with this video you're going to need some basic get skills so you're gonna have to know how to add commits push pull all that kind of basic stuff or just go back and watch the first video in this series on the screen are the topics listed although these are going to be a byproduct of the workflow that I'm going to show you which is on the screen right here I'm not going to try to spend the time explaining what this diagram means if you want you can pause the video and take a quick look at it but essentially what's happening here is we are creating feature branches from the develop branch which is considered like the main development branch that we're working on and we are going to do work on that feature commit it and eventually merge it back into the develop branch which will then eventually be merged into the master branch tagged as a release and then you will start the workflow over and over again now it doesn't make sense yet because we don't really know what a branch is or how to check out a branch how to create one but I think the easiest way to do so is to just get started and go through a practical example and actually build out a repository I will start off by creating a repository we'll name it basic get workflow and I will click create once we have this copy the URL or the SSH URL and then come back to the terminal where we will actually get this setup I'll make a directory called git workflow CD into it and type get an it to initialize our repo we will then say git remote add origin and copy in the URL that we just saw on github so this will connect to our repository up and then finally we're going to create a few files and once we've done that we have enough to make our first commit so we will go in there and add the files so you can do this by typing in both of the files or you can just type dot to add them all you can check them with git status you see that we have two in the staging area which we will now commit as our first commit to the repository and finally we are going to push that up to the master branch of our repository on github when we do that and come back to github refresh the screen you'll see that we have one commit with these two files all right so pretty simple the last thing that we need to do is set up a license for this repository so we will touch license and then what we're going to do is open that up with them and copy in the following contents if you were to use this repository you would just add your name under the copy right here that's how an MIT license works so you would come up here and actually type the same thing so copyright 2019 or whenever you're viewing this and then your name so that's how you would use an MIT license correctly so we'll save that get out of there and then add this license we're just doing this so that we have a couple commits to work with at the beginning we will commit this add license like and type and then we'll push that up to the master branch as well I know we haven't actually done all that much work yet but for our sake of learning we are going to consider the work that we've done the first production release for this repository so it's definitely not a production release it's not even useful software but we'll go with that to demonstrate this workflow that we're trying to get at so we have already committed two commits and say that we wanted to tag that second commit as the first production release to do that we're going to have to first see what tags are in a repository already so you just type get tagged and you'll see that there's nothing there which is something that we would expect given that we haven't tagged anything yet to actually tag this first production release what we'll type is get tagged a four annotated tag which allows us to type in version 1.0 as the marker for it and then we'll type in a message added the first tag and what this will do since we didn't specify any particular commit to tag it's going to tag the most recent commit which is the one that we would want now we can also show this tag so by typing get show and it'll show all the things that are in this particular tag and you can see that we have the license and that's what was on the latest commit all right so we have the first tag and now we can type get tagged and see version 1.0 now to push this up to our repository since we don't actually have we didn't actually add new files we can type the git push and then type in the tags flag and then type origin/master and that will push it up to the master branch at our remote repository which if we flip over there and refresh you'll see that we added the license and then you will also see in the tag section we have this version 1.0 so that indicates that this was a successful push of that particular tag all right we've created our first tag and now we're going to create our first branch now as we'd spoken about earlier with the diagram we want to have a master branch that we'll be kind of our production releases only so we're only gonna push code that we consider production up to the master branch and we'll do all of our developing on some other branches namely the develop branch and then a multitude of feature branches we'll get into the feature branches a little bit later to create this develop branch all we need to do is type git branch develop and if we press the Enter it would create the develop branch before I do that I want to show you a command that you can use with get that will help you understand what is going on in your repository so that command is get log and you can type it git log which will print out everything including my email address which I'm not so interested in doing or you could type out a longer version of that command which says git log one-line decorate graph all this will print out one line for each commit it will decorate it you know highlight it with different colors and it'll put it in a graph so as we start to branch out in merge changes into branches you'll see how this works and then this last part says all just meaning that we're going to print out all the branches not just the current branch that we're on so you can press enter and you will see the history of this repository now one tip I would put this into an alias so if you go into you know your profile this is where you would put your alias and I can type G log and get the same result so it's a much quicker way than trying to type out and remember all of these options so that's just a quick tip all right so we type G log and this is going to show us the history of our repo in this output I wanted to point out three things so on the right you'll have the commit message on the Left you'll have the commit hash which is obviously been abbreviated so you'll just see the first and characters and that will represent the whole commit and then third is this little parenthesis right here which basically shows you that the head pointer is pointing at the master branch and has a tag of version 1.0 and it represents the origin master on the remote repository now we're going to learn about this in just a moment but first let's go ahead and create that new branch so if we type the git branch develop and press Enter you can see that nothing has really been output but if we type git branch you'll see that we now have two branches in our repository notice that the star is still on the master branch and that is because we haven't switched over to our new develop branch yet and we can see this represented in the presentation so you'll have the first commit the second commit which has the version 1.0 tag and then the more interesting thing about this is all the stuff going on around these commits so in git it's very important to understand this pointer right here called head and the reason being is because the head pointer tells us where the git repository is currently pointing and as you can see here we are pointing the head pointer at the master branch pointer which subsequently is pointing at the most recent commit in our repository as we had seen a little bit earlier we had created this new developer anch but we haven't actually checked it out yet which basically means that the head pointer is still going to point at the master branch which points at the most recent commit the develop branch also points at that recent commit but we won't be able to work on it until we actually check it out so let's go back to the terminal and the first thing that we'll do before checking out this branch and when I say checking out I just mean switching over to it the first thing we'll do is type git status and the reason that we have to do this is because if there's anything in our working directory that doesn't match the repository or the state area it's going to prevent us from actually switching branches because git is designed to lose the least amount of work possible and it kind of protects against losing any work through this mechanism so we have a working tree that is clean so we can check out the develop branch and when we do that it says we have switched to develop and if we go back to our presentation and switch to the next slide you'll see that this head pointer has actually flipped from the top pointing at the master branch pointer and now it's pointing at develop and that just means that we're pointing the headed develop which is pointed at the latest commit and therefore we have checked out the develop branch and we can work on it if we come back to the terminal and type get brand you will also see this reflected we have these star pointed to the develop branch if we wanted to actually make some changes to this develop branch now that we're actually switched to it or checked out to the develop branch we can start editing our working directory so I will create actually we're not going to create we're going to edit the index.html file so at the moment it looks pretty awful and it's just basically a long string of HTML obviously if we were actually coding this we would make this a little bit more formatted so that's what I'm going to do here I'm going to basically just delete all this and then we'll copy in an amended version this form of HTML is a lot cleaner and you can also see we've got this CSS in here and a few more tags at the bottom so we'll save and quit and then what we can do is add this to the develop branch and it is as easy as just adding index.html we don't have to do anything special then we can commit something so add CSS to HTML and then finally we can say git push origin and then instead of master so this would be pushing to the master branch will reverse that and we'll say develop branch so we're going to be pushing that commit to the develop branch let's run our G log command which is just the git log with all those options that I showed earlier and you'll see that we now have the head pointing at develop and we have this latest commit here which is 37 ce7 49 let's go back to the presentation and see what our repository looks like now you can see that we have three commits and the develop branch is pointing at the most recent commit and the head pointer down here is pointing at the develop branch so therefore the head or where we're working in the repository is at the latest commit but the master branch up here is actually a commit behind so if we wanted to catch that up what we would do is called a fast-forward you'll see this a little later on when we finally kind of merge the develop branch into the master branch let's make a few more changes to this repository and we are going to eventually make our second release for this you know whatever software project that we're making so the first thing we'll do is we'll go into the index.html file and we're just gonna get rid of these style stuff we're going to add the CSS to a separate file so we will refer to that in the HTML as style dot CSS and then I think we can keep the rest of this the same so let's save and quit and then what we'll do is create a style dot CSS file and remember we are still on the develop branch so all of these files even the file that we just created is not going to be present on the master branch quite yet so we'll put in the style dot CSS content and this is going to connect up with our HTML document and we can finally stage and commit our changes so we'll just type git add dot for all and when we type get status you should see in the staging area we have these two files that one of them is a new file in one is modified we will commit this to our develop branch so split HTML and CSS and then finally we will push to the develop branch we can print out the history or the log of the git repository and see we have this new commit hash here and we can look at this over in the presentation to see that we now have a fourth commit and once again the develop branch will be pointing at that commit and the head pointer will be pointing at the develop branch so therefore we are currently at this latest commit the next thing that we're going to do is not add anything more to our develop branch but actually create a new branch called feature 1 so this is going to be our first feature branch and is kind of part of the workflow where say you've got a couple people working on the develop branch at once and therefore you're going to you know if you want to make any changes without messing with other people's code you're going to have to create a new branch based on the develop branch and call it some sort of feature and then you work on that and eventually merge it back into the develop branch to create the feature well first look and see what branches we have make sure that we just have these two and then we will type git branch and then feature one so I just say feet one for brevity we created the feature branch and now we want to check our status we are we have nothing to commit the working tree is clean so therefore we can check out the feature one branch now that we have this feature branch checked out let's go ahead and add some JavaScript to our HTML file the way that we'll do that is by first adding the tag to the end of the body so go down here we don't want to do that let's see and then we will add a script in here with a source of dot script J s and that is all we need to do to add it to the HTML we also need to create script J s and put the following contents in that script for anyone actually interested in what the code is doing you don't really need to be basically what this is going to do is kind of flash the header that's in our HTML file so if you're following along and actually running this HTML that's what this is going to do nevertheless let's save that and quit and then finally we will update our CSS file one more time to have a few more changes so we need to add this little hidden class at the bottom to allow our JavaScript to work correctly and once we've done that we should be good so we will now add everything to our feature branch staging area if we type git status you'll see that we have these three files two that were modified one that was created new and then finally what we can do is add this or commit this to our feature branch we have committed this and we will now push to the feature one branch instead of develop we created a feature branch and we added some what we think is super complex JavaScript you know we're just patting ourselves on the back and then we realize wait a second we forgot to add a git ignore to our file or to our repository so we'll go back to our develop branch so we get check out develop and then we will create some sort of to-do list text and in this to-do list maybe we'll say write awesome code and that's our only to do for the day the reason that I created that is basically just to demonstrate what the get ignore file is going to do for anyone watching this video that is not so aware and when we create this get ignore file in the root of the repository it's going to tell git which files that we don't need to keep track of and basically ignore so we create this get ignore remember we're in the develop branch we switched from the feature branch and in this get ignore we're going to echo in to do list dot text so that's basically going to ignore the to-do list file from a repository and then we are going to add everything and then when we type git status you'll see that we have a new file dot git ignore but it doesn't show the to-do list text and that's because we put that file in the dot git ignore and asked get to kind of just forget about it so we have added this file here and what we want to do is actually commit it and then finally we will push to the develop branch so since the last time we kind of looked back at our repository and and put it in a diagram we've made several changes so we changed the index.html file and we added a JavaScript file and we even added some new CSS that was all done on the feature one branch we then forgot about the GUID ignore file we said hey you know we want to actually add that to the the develop branch it's a day later we're not thinking about the feature branch anymore so we come over to develop and we add the get ignore file we commit that file and so now we have one commit on our feature one branch and one commit on our develop branch if we type that fancy command I'll just repeat it I won't do the G log for this one I'll actually copy in the full command here so that you can see it and now you'll see that this little decorate and graph coming into action because you'll see right here there's kind of like a split going on in our repository instead of looking at this little tree that we have although this is basically what you're going to be doing once you're on your own we'll go over to a diagram that I've put together that kind of shows this repository in a more visual way so you'll see our master branch is still at the first release we haven't made any changes to it in the past couple commits and so we have all these commits and finally we have these two commits that are basically diverging so this de b fa e for commit is actually going to be the parent commit for both of these commits that we just made so the first one is the Java JavaScript feature so this is going to be the update to the index.html the update to the style dot CSS and the creation of the JavaScript or stock or whatever it's called script j/s so we've changed three files in this commit and then that's on feature one branch so you can see that feature one branch pointer is pointing at that commit and then you see down here the develop branch is pointing at the commit where we added the dot git ignore file you can also see that the head pointer is pointing at develop which just means that we're currently sitting on the develop branch let's hop back into the terminal and just kind of see what's going on here so remember we have the 266 commit is going to be the JavaScript feature and the seven 400 is going to be the dot git ignore file so we pop back into the terminal and what we're gonna find out is that currently we are sitting on the develop branch and therefore the files in this branch are not going to match this JavaScript feature that we added so notice we don't have anything that resembles a javascript file and if we cat out the index.html we don't see anything down in the body that links up to a JavaScript file so clearly we don't have those changes there but what we do have if we print out hidden files is this get ignore file and that makes sense because we added that to the develop branch now let's type git status you can see that we're on branch develop nothing to commit working tree clean so we can check out the feature one branch once we check this feature one branch out you'll start to see we actually have the script j/s here so this is the JavaScript file that we made and if we count out the index.html you'll see that we have the script tag added at the bottom of the body so basically what I'm trying to say is we have these two different commits on two different branches and so basically these branches have completely different snapshots of our repository now the goal is going to be we want this feature branch to merge back into the develop branch since the change that we made on the feature 1 branch in the develop branch are not going to conflict so we didn't edit like the same parts of a single file we can merge them pretty cleanly together in the way that we merge something together is by first checking out the branch that we want to merge into and then typing the git merge command followed by the name of the branch that we want to bring in to the branch that we're currently checked out on I know it's a little bit of a mouthful but you'll see what I mean in a second so let's first check out the develop branch and from here what we can do is type git merge and then feature one and what this is going to do is take all of those changes from feature 1 branch and pull them in to our develop branch in other words once we have this merged our develop branch is going to show the script j/s it'll have the updated style dot CSS the updated index.html and the dot git ignore that was originally edited on the develop branch so we'll press ENTER and it's going to pop us into a message and we can edit this message however we want I don't really care to change it so I'm going to save and quit from vim and you'll see that we said the merge was made by the recursive strategy and we have these three files from the feature branch and you will notice that there's no dot git ignore here because that was already on the branch that we're merging into so let's clear the screen in type ls' to see that we now have script J s and to confirm we are on the develop branch right here so the last step after we've merged files from the feature 1 branch into develop is to delete the feature 1 branch because we don't actually need it any longer the way that we do that is by typing git branch and then give it the dash D flag and type feature 1 and what this will do is actually completely delete the feature branch it says deleted branch and it was on this commit to see what's going on in our repo well once again type the git log command and when we see the output here we're gonna notice that this branch has actually kind of merged back in to the develop branch so these are the two commits right here that we had merged together into the develop branch and you can see that this is the JavaScript stuff and this is the dot git ignore which eventually merges together into the develop branch at commit ce6 oa9 be let's hop into the power point again and just visualize this a little bit easier so once again master branch is still way way back there eventually we're going to merge develop into master and they'll be the same but for now that's kind of sitting way back in time and it's only got a couple files you'll see here are our two commits where we have the JavaScript feature in the git ignore file and then this commit right here which is the latest commit that we're currently on hence the head pointer that's pointing at the develop pointer which is pointing at this commit that brings these two changes or commits into one commit on the develop branch now the last thing that we want to do is take all the information here what we call a snapshot or a commit and we want to take all this information and merge it into the master branch now it's going to be a little bit different than this merge here because in this merge we actually had two commits that were coming from the same parent commit now in this case the master branch is sitting way back in time and it actually has no divergence so basically what we're going to be doing is taking the pointer for the master branch that's currently pointing at this commit right here and we're just going to march it all the way up the taury and point it at the this last commit right here so we're not actually doing like truly emerge it's basically moving the pointer to the latest commit let's go into the terminal and do that really quickly the first thing that we need to do is once again type git status make sure that we have a clean working tree and then after that has been checked we will move over to the master branch so we are now on our master branch which is where we will do all of our production releases and the way that we merge as I just explained the develop into master is by tape typing git merge develop and that's going to bring develop into the master branch that we're currently on you'll see that we fast forward it and the reason that we that it says fast forward is we're basically taking that pointer the master branch pointer and walking it up the commit line to the latest commit so now if we type the G log you can see that the head is pointing at master and develop because they're actually at the same exact spot the last thing that we need to do since we officially released our production code is tag the commit that is the most recent one on the master branch so remember we are still on the master branch and we can write this tag is so version 1.1 and we have officially tagged the latest commit on the master branch we can now jump back into the presentation and see the final state of our repository so as you can see the only thing that changed is we took this master branch and we originally had it pointed at this commit right here version 1.0 but we basically moved that pointer up the repo and pointed it at the latest commit in the repo and then finally we pointed the head pointer at the master branch so basically we're currently working on the master branch and the reason that we saw this in parentheses here head is pointing at master and then , develop is because the develop branch is going to be pointing at that latest commit as well so develop branch pointing at that commit as well as the master branch and that is pretty much it that is the basic git workflow so to recap basically all we did was we created a master branch in a develop ranch we did some work on that develop branch we maybe created a couple feature branches merged those into the develop branch and eventually when we were ready to release our production code we merged the develop branch into the master branch so this is basically the workflow that even pretty complex projects from big companies will use I will say that there are a couple extra branches that many companies are going to use to manage their source code that could be things like hot fixes there might actually be a branch dedicated solely to preparing a new release to go out into production but in essence we are looking at a professional get workflow and you can just go through this over and over again releasing you know version 1.0 1.1 1.2 and use this for pretty much any project that you would ever need

Channel: Full Stack Zach

Views: 28,609

Keywords: git workflow, git branching, git tags, git tagging, git branch, deleting git branches, merging in git, git workflow for small teams, git workflow diagram, git workflow tutorial, git workflow teams, git workflow feature branch, git workflow best practices, git, github, git flow

Id: BF2OHMM86Ik

Length: 35min 16sec (2116 seconds)

Published: Tue Mar 19 2019