Intermediate GitHub Tutorial

foreign I'll be sharing with you intermediate git and GitHub features and demonstrating how to use this software in a professional environment specifically I'll be discussing the proper way to create a pull request and contribute to a repository how to fix conflicts the difference between a rebase and a merge how to pull and modify existing branches cherry picking different commits and then how to reset history and commit and more advanced git and GitHub features that are not typically shown now this video is designed for people that have some familiarity with Git but if you're a beginner or just need a refresher then feel free to check out the video that I'm going to put on the screen which will give you the fundamentals you need to then go through this video lastly I'm happy to mention that this video is sponsored by Microsoft who helped me develop this video and on May 9th we'll be hosting a 45 minute long webinar as a part of the developer digital Meetup tour this webinar will go much more in depth on this topic and teach you about Advanced developer workflows while also including a live q a session at the end to register for the webinar go to AKA dot Ms slash Tech with Tim or click the link in the description with that said let's dive into the video [Music] alright so let's go ahead and get started so in front of me I have a sample GitHub repository and what I'm going to do in this section of the video is demonstrate to you how to correctly create a pull request and contribute to a repository now this is going to be more applicable if you're working in a team environment with multiple developers or for a company if you're just working on your own kind of solo git repository or GitHub repository this isn't going to be super applicable and you don't need to follow these steps but whenever you're working with more than one developer you're going to want to do what I'm outlining here just to keep everything clean and kind of best practice so first thing to understand here when we're looking at this repository if I can open it back up is that we have a branch called main or in some instances it's going to be called Master now you can see this is the default Branch now your main branch in most instances is going to be the branch that you want to have clean reviewed and finalized functioning code on what that means is that you don't want to be directly contributing work that's not finished to the main or Master Branch you want to be doing essentially all of your Dev work on in a kind of additional Branch so a feature branch and then once you've finished a completed feature or bug fix or whatever it may be then you're going to merge that onto the main or Master Branch so in most repositories your main or Master branch is going to be locked which means unless you're a I guess you would call this an admin of the repository you're not able to actually directly contribute to this Branch instead what you need to do is work on an additional branch that is forked off of the main or Master branch and then merge it onto the master bedroom our main branch once it's been reviewed and your code is completed tested and functioning so just keep that in mind your main branch you want to always be kind of production ready to some extent and always fully functioning so that additional people can always revert back to the main branch and know this is kind of the current uh version of the repository the current up-to-date State whereas all these other branches are Works in progress that are eventually going to be contributed onto the main or Master Branch alright so with all that said let's actually get into an example of making a contribution then to this repository keeping in mind that we want to do our work on an additional branch and that eventually merge it into this main branch okay so I've opened this repository here in Visual Studio code and I want to start creating a feature I want to start adding some code now obviously I'll just do something simple for this video but what is the process to do this well the first thing I always do is I check what branch I'm currently on by typing git branch in this case I'm on the main branch that's what I want to be on and what what I like to do before I start working or creating a new Branch or feature is I like to make sure that my local repository is up to date with the remote repository this is just going to save me a ton of headaches in the future so what I do is I type A git pull when I do that that's going to pull all of the changes from the remote repository to my local repository and keep my local version of the main or massive Branch up to date so what I'm trying to do locally is always keep this main branch up to date with the remote repository you know every day I like to make a poll something along those lines so that whenever I decide to Fork off of Main I'm not forking too far kind of in the past and I have a very up-to-date version of the code base there's different ways to do this but this is what I'd like to do now you may have to actually fully type out git pull origin and then whatever the branch name is in this case it's going to be main it's going to do the same thing here in my case the get pull command is just automatically set up to pull from this main branch when I'm on that Branch okay so now I'm fully up to date with the remote Repository uh and what I'm going to do is create a new Branch so I'm going to type git checkout hyphen B standing for a new branch and I'm going to give this a name now when you name a branch it's typically a good idea to give it some kind of unique prefix that is specific to you so you don't accidentally name Branch the same thing that someone else has named that's eventually going to push it to the repository so what I'll do typically is something like get checkout hyphen B and then Tim and in this case I'll say feature now obviously whatever the feature name is like if this was a leaderboard or a scoring system or whatever I would name it that in this case we'll just do something generic which is feature now again the reason I use Tim is because if someone else is working on a branch called feature we could have kind of conflicts and be pushing to the same remote repository branch which could kind of cause some headaches so it's a good idea just to prefix your branches with your name or some unique ID that no one else is going to be using alright so I'm on my new branch and now that I'm on my new Branch I can go crazy I can create my new features so let's say my new feature is just a text file okay so we'll just say feature Dot txt and I'll say this is a great feature okay perfect I'm going to save that now obviously we can go through our standard gate commands we can also just use the interface here in vs code and I can add these changes to the staging area so git add dot then I can make my commit I'm going to do the commit message using hyphen M and I want to name this something meaningful it's going to be easy to review later on so I would say added a feature dot txt file and actually it's standard practice to write this in present tense not in past tense now it doesn't really matter I don't see many people actually follow this practice but you are supposed to write this in present tense uh not past tense so add a feature.txt file as if you're doing it kind of right now okay so I've done that I've now created my commit and now I'm at the point where I actually want to push this to GitHub I want to get my code reviewed and then I want to contribute this to the main branch so other developers can start using this so if I want to do this now what I need to do is I need to push this Branch so I'm going to type git push Tim Dash feature when I do that sorry I need to First specify the location I'm going to push to so get push origin Tim feature because origin is the remote repository I want to go to so we're going to push to this remote repository and now you can see it's created a new branch on the remote repository called Tim feature so by me simply doing this push because I had access rights to this GitHub repository I've now created this new branch and if I click on this button and I view all branches you can see that there's a Tim feature Branch right here and I have the option to manually click create new pull request I can also view this Branch by clicking on it and then view that this new file is here I also have the ability to just press this button which is automatically being generated by GitHub although sometimes it doesn't actually give that to you based on kind of when you contribute if you change something all kinds of reasons why you may not see this button so I wanted to show you manually you can go here and then click that okay so I'm going to go compare and pull request now we get to the pull request kind of template page now typically when you get to this page there's going to be some kind of template that you'll need to fill out depending on the organization that you're working for and it may tell you to upload some photos or to tick some boxes or to describe the feature whatever you got the idea you want to give a descriptive pull request name and the point is that through this pull request you may actually go back um kind of in the future and say okay what did I change here what were the changes and you just want to have a decent name so it's easy to find what this pull request is so in my case we've done a very simple thing which is just add a file that's about as much subscription as I need to add than if I wanted to I could add additional comments again in this case I don't need to do that but it is good practice to add as much detail as you possibly can so I'm going to click on create pull request and now what I've done is I've created my pull request now this pull request will typically need to be approved depending on the settings of the GitHub repository before it's able to be emerged into the main branch so in my case I can just directly merge it in here because I'm an admin of the GitHub repository however if someone who was not was working on this repository then someone like myself would have to review their pull request and then approve it before they'd be able to actually merge it in so if I go here to reviewers if there was other people on this repository I'd be able to select them and say request review so that's typically what you're going to do and then you're gonna have to wait for them to come here and review the pull request now in my case I can show you an example of doing that because you may also do that for other people's pull requests so here it says review changes I can obviously go and look through all the changes and tick the files that I've seen and if you had more files and directories it would show you that setup on the left hand side anyways it's quite simple here so I'll click on review changes maybe I leave a comment here and I ask them why they did something a certain way I also can select a line here click on this plus button and then directly add a comment on this line so I can add a single comment right here and now if you go to the conversation tab you'll see that there's a comment kind of discussing a specific line and then you could reply to that comment and kind of keep all your conversation on one pull request so that you have history of it and you can look at it later you can also resolve the conversation which means you've kind of fixed whatever they commented on now you'll see when I go here that it's tell telling me that I can't approve or request changes because I'm the author again that kind of makes sense but what I would do if this was someone else's pull request I would review it I would leave some comments and then I would approve it and then they would be able to merge so I just want you to understand that this is the process right you create this pull request and now I can merge this pull request into the repository I'm going to delete this branch which is typically good practice you want to keep your branches clean that you're not using I'm going to go back to code and now notice that I've created a merge commit here that has merged all of this content into the main branch so now I have my one branch I have feature.txt on here and everything is up to date and we can go and look at the three commits we have our initial commit this and then we have the merge commit which is actually merging all of my code from my Branch into this main repository okay we're almost done here now we go back here okay we're working on some other feature or maybe it's the next day we want to do some new code so now what I want to do is I want to get check out the main branch remember you always want to keep your main branch your local copy of the main branch up to date with the remote repository so I'm going to go to my main branch and then I'm going to type git pull and I'm going to pull down the remote changes now even though I've already made these changes locally I've only made them on my other Branch so on my Tim feature Branch not on the main branch so I go to main I pull that gives me the changes from the remote repository including that merge commit and now I can create new branches and work off this main branch to avoid any conflicts now you'll see that if I go get checkout so let's go here get check out Tim Dash feature and I try to push this up so get push origin and then Tim feature like this it's gonna create this new Branch okay so it creates a new Branch now I'm gonna go back to the GitHub repository and we are going to go here we're gonna go to Tim feature and it says this one commit behind main now the reason it's saying it's one commit behind main even though it has the same content is because the main branch has a merge uh merge commit sorry that merge these two things in whereas my current local copy doesn't have that merge commit so I don't want to keep working on this Branch because I could potentially be getting conflicts instead what I want to be doing is creating a new branch and then working off that hopefully that makes a little bit of sense of what I'm describing here I'm just going to go back to the main branch though so get checkout Main okay and now I would create a new Branch so git checkout hyphen B and then Tim feature two and this is where I would do any additional changes this branch is up to date with the main branch meaning that whenever I make a push I'm not going to have any conflicts at least I shouldn't have any conflicts based on how we're doing this right now and it should just be kind of smooth sailing to add new code to the code base [Music] alright so continuing here the next thing I'm going to go through is resolving conflicts and I'm going to kind of explain to you why a conflict occurs because this is a point where people get very frustrated and oftentimes kind of don't know how to deal with this in some kind of production environment or you know kind of workplace team environment so what I'm going to do here is essentially create a conflict now before I do that I'm just going to look at the current status of my repository so it says I'm on Tim feature two so what I'm going to do is check out the main branch again I'm going to pull to update everything's up to date okay and now I'm going to delete these two branches that I don't need just so that I don't get confused and accidentally use them throughout this section so I'm going to type git Branch hyphen capital D and then I'm going to go Tim feature that's going to delete that branch and I'll do the same thing with Tim feature two alright so now let's create a conflict so let's clear let's go get check out hyphen B Tim Dash and we'll just go C1 for conflict one and all I'm gonna do here is go to this file and I'm just going to delete this line okay so I've deleted that line here now I'm gonna go get add dot git commit hyphen m delete line in and then feature dot txt okay and then I'm going to push this up to GitHub now you'll see in a second kind of how I create the conflict for now though all I'm doing is just making a change the repository which is not going to cause a conflict okay so I've gone here uh and you can see then now I have Tim C1 and I can create a pull request so I'm going to do that create pull requests and I'm going to create that now for now I'll just leave this on the repository and we can merge it in later all right now what I'm going to do is go get checkout and then main now notice here that we still have the text inside of the file okay so now I'm going to create a new Branch now imagine that I was doing this as a different user so you know Tim me just created a branch that I uploaded for a pull request that Branch deleted a line now imagine some other developer is checking out a branch from their local main copy they don't have that deleted line because that was worked on on a separate branch and now what they're going to do is maybe modify this liner they're going to modify this file in some way this is kind of how a conflict will occur so I go get check out hyphen B I'm going to go Tim C2 for conflict two okay and here all I'm going to do is say this is a great feature Tim is the best uh just two true statements on one line okay so now that I've done this I'm going to do the same thing I'm going to push this up for a pull request I'm gonna go get push origin and then Tim C2 so essentially what I've done here is I've created two separate branches each branch has made a change on the same file and in this case on the same line so what that means is that there's conflicting changes on both of these branches so I'm going to go back here to pull requests let's go to code let's go to our branches Tim C2 and let's create a pull request uh okay for some reason uh apologies for the cut here I realized I forgot to make my commit so I'm gonna go get add dot get commit hyphen m I'm just gonna go with a simple one like make changes and now I'm gonna push this again back up to the repository so that now I will see it here okay so Sim Tim C2 has changes so let's go here and make changes Okay so we've created two pull requests and you'll notice that on both of these pull requests right now everything's completely fine I can merge them in because all I've done is made a change to one of the lines in this case I've deleted the line okay and then on my other pull request here I have simply added to the line so what I'm going to do is just pick any of the pull requests it doesn't matter which one I pick here and I'm going to make a change okay so I'm going to confirm this uh now this is the file that is adding to the line okay so let's confirm this merge all right and check that okay now this is in I'm going to delete this branch and what you're going to see is when I go back here now all of a sudden it's going to show me that I have a conflict now the reason it's telling me I have a conflict is that the change that I've made here is trying to change the same line that was just changed in the previous pull request but on a different version of the file now I know this seems kind of strange but essentially both of these branches were kind of merged or sorry forked off of the main branch at the same time so two minutes ago I created these two new branches they both modified the same version of a file and now I've checked it's called checking in but I've merged one of these file changes into the main repository but this Branch was making a change to a previous version of that file so it was making a change to a version different than what is now inside side of the repository hopefully that makes a little bit of sense but the actual definition here of one emerge conflict occurs is when people make different changes to the same line or the same file or when one person edits a file and another person deletes the same file so that's exactly what's happening here we're editing the same line in the same file and git doesn't know what version of the file to take so we have to resolve these conflicts now we can do this in Visual Studio code or we can do this here on GitHub alright so now that I'm inside of this file I'll quickly explain what this syntax means so in between these two symbols here where it says Main and it shows all of the equal signs this is what's currently on the GitHub repository okay this is what's currently here and then this um kind of weird because I've deleted a line but this is what's on this Branch so essentially what it needs me to do here is delete all of these symbols that have been added in now I can put anything I want in this file but it needs these symbols to be removed before it's going to tell me that I've marked or before it's going to allow me sorry to mark this file as resolved so that's one way you can do this directly from the editor on GitHub or you can do this from vs code so I'll show you from vs code as well if I go back to visual studio code here now what I can do is I can try to update my C2 Branch with the main branch so the way I'll typically do this is I'll go get checkout main I'll pull main which is going to give me the fixes so or the updates now it's going to modify this file and now I'm going to go get chick checkout and then in this case it's C1 and now what I'll do is I will merge the main branch with this branch and when I do that you're going to see that I get a merge conflict Happening Here locally I can then fix that and then re-push to GitHub and then everything will be okay so what I'm going to do is go get and then this is going to be merge and I'm going to merge main now I could merge origin slash main or I can just merge mate now if I do main that's my local copy which in this case is fine because I know that's up to date with my origin or my remote repository alternatively if I knew it wasn't up to date then I would just do origin slash main in this case they're both going to give me the same result origin slash main by the way of course is the remote repository and then the version of the main branch on there okay so I'm going to hit enter here and notice it says automatic merge failed fix the conflicts and then commit the result now here we get some better kind of choices so we can accept the current change or the incoming change or both changes or alternatively we can just manually update this file now for clarity here the incoming change is what's coming from the remote repository or from the other branch and then the current change is what you currently have on your current Branch so what I can do is accept the current change if I actually want to delete this line then I'm going to save and then what I need to do is I need to commit the results so I'm going to fix the conflicts and commit the result my file is already added into the staging area so just type git commit hyphen M and I say fix dot txt file conflicts okay this is kind of my merge commit now I'm gonna do that uh and sorry actually I forgot I have to add this to the staging area I thought it was already there and then I commit okay so now that I've made my commit here what I can do is re-push this so I'm going to type get push origin Tim C1 and now that I re-push this to the remote repository with the conflicts fixed so we're gonna go here all right uh I should be able to just merge this directly in and you'll notice that now I have two commits so I deleted the line and then I have what's referred to as a merge commit which is what I made to merge the changes from the main branch onto my feature Branch so now when I merge my feature Branch back onto the main branch the history is correct and everything is up to date I know this can be a little bit confusing but what I just did to fix the conflict was I essentially merge my Branch with the main branch so that I integrated all of the changes from the main branch onto mine I then from that point forward created the change I wanted to put on the main branch which is what we've done by deleting the line and now I am able to merge this pull request in okay I again I apologize this stuff is not simple hence why this video is intermediate kind of GitHub topics but that is how you go about fixing a merge conflict now obviously the conflicts you can you get can be much nastier than what I just showed you here uh there is some more advanced tools that you can use to fix these however typically what you want to do to avoid getting too many conflicts is always be branching off of a clean version of the main repository if you're doing that or sorry off the main branch if you're doing that you're going to limit the amount of conflicts that you have and you know once in a while yes you will get them but what you need to do then is merge with the main branch and then you'll have to manually go through and fix all of those conflicts once you fix them then you can re-push and then you'll be able to merge back into the Repository [Music] all right so I've just moved to the drawing tablet here because I'm going to quickly explain to you the difference between a merge and a rebase which are two popular commands to integrate changes from different branches that many developers don't actually understand so it's helpful to view these visually they're actually not overly complicated but you just want to understand kind of the core difference between what emerge is doing uh compared to a rebase so let's just draw a simple example here of a git history so all of these circles are going to be commits and this white Branch here is going to be our main or our Master Branch now let's say at some point in time we decided we're going to start creating a feature and maybe we did that here okay so at this point we decided to Fork off and we created a new branch in this Branch maybe we called something like C1 now obviously that's a horrible name but we decided to call it C1 there we go we have our C1 feature wrench now let's say that we are here and we decided this point in time okay you know we finished our feature now we want to actually kind of combine this or merge this into the code base there's a few different ways to go about doing this we also may just want to update our current Branch to integrate all of the changes from Main so let's put put it in that scenario we want to update our current Branch with all the changes from Main so that way when we continue working we have an up-to-date code base everything's kind of you know updated nice and clean and ideally we're gonna kind of remove the riskiness or remove sorry the likelihood of having a conflict okay so we want to take changes from here that have happened since we've been working on this branch and integrate them here obviously what's happened is since we've branched off new code has been added to the main branch we want that code now in this Branch how do we get that well the First Command we can run is our merge now when we decide to run a merge what's going to happen is a new commit is going to be created this is called our merge commit and I'm going to put an asterisks here which means it's new now what this merge commit is going to do is it is going to essentially combine all of the changes since we branched off with the changes from this Branch so it's a brand new commit and it just combines well all of these different changes now a conflict could occur here if that's a case we need to fix that and then the kind of conflict fix will be involved in this merge commit alright so we create this merge commit it essentially combines everything together and now say I'm on my Branch C1 if I were to continue to work I would kind of add off of this merge commit and there we go now I have all the changes from my main branch and I'm continuing to work now the advantage here of creating this merge commit is that I keep the entire history of my git repo what I mean by that is I know still all of these different commits I know when I originally branched off and I know at what point in time I decided to do this merch now the disadvantage is that this merge commit is very messy oftentimes it kind of messes up the history you can see here now we have a non-linear history because we have different branches kind of being integrated together and it can make the history of the GitHub repository well just very messy right it's difficult for me if I'm reviewing this later on to understand if I should be looking down here if I should be looking up here if I'm looking after the merge commit it just kind of complicates things a little bit when you're going back and review it okay so that's a disadvantage but again the advantage is you're retaining all of this history and you know everything that's occurred you're not losing any information you've just added this additional merge commit which can make things a little bit messy now one thing to note here is that since I've integrated main with my C1 branch that doesn't mean that on my main branch I now have my C1 one changes only if I've actually made a pull request and kind of merged this into the main branch am I going to have that if I were to locally check out the main branch now as I continue to work I'm going to continue to Branch off of my main branch and then later maybe I integrate the changes of C1 but what I've done is I've taken the changes from Main and put those on my C1 Branch not the other way around it's not going to happen on both branches it just happens on the branch you're currently on when you run the git rebase commit okay now let's talk about merge so I think actually will be easier if I just delete all of this so let's erase all the ink okay so now what happens when we do a rebase well what a rebase is doing is taking essentially this entire Branch here so all of the code that we've done and it's just moving it to be at the tip of our main branch so let's say I'm on to C1 right I want to integrate my main changes then all I do is I rebase it and when I rebase it it moves my brand inch over here now obviously it's a little bit more complicated than that but that's essentially what's happening rather than creating a new commit here which is a merge of these two branches together I am simply taking all of this code or all of these commits sorry from this branch and I'm moving them so that now they're going to be attached at the head of my main branch or whatever Branch I am merging or sorry rebasing with my what do you call it feature Branch now what actually happens here is this right so this new branch is going to contain entirely new commits all the asterisks are just new commits what happens is my original branch which I can kind of do like this so my original commits are going to be copied and added to the head so I'm not taking the same commit I'm actually kind of copying them and turning them into a brand new commit and then attaching them to the head of whatever Branch I'm rebasing with now the reason why this is nice is that we no longer have a merge commit and our history is fully linear so now it's very easy for me if I'm reviewing this later on to understand that okay I just go from here here down to here I don't have this kind of fork in the road where I have this merge commit that's combining the two different branches I have a full linear history the disadvantage of doing this is that I lost all of the history that I previously had when I decided to Branch off so again we originally had branched here and if we had done a merge we would have known that we branched here we would have known all the commits that were on this Branch versus here now when I do the rebase it becomes unclear I lose that history and instead I kind of trade that for this straight linear history so you might be asking yourself now okay I understand you know rebase is essentially attaching to the head and what actually occurs here is we apply every single one of the commits that are on our Branch to this Branch right so we're really just tacking them on that's all that's happening and these become new commits but you might be asking yourself well when do I use which right when do I use rebase first when do I use merch well the Golden Rule here is that you never want to use a rebase on a public Branch now what I mean by a public branch is a branch that someone else could potentially be working on the reason you don't want to do that is because if someone else has a copy of the branch that looks like this and then you rebase and you push that Branch when they pull this they're going to get all kinds of conflicts and they're going to have a completely different version of the branch locally than what you've pushed so you've now moved every single one of your commits over to the head of the main branch where theirs are still forked off and have not been rebased and when they decide to do a pull uh there's just kind of you know like a mini disaster that's going to occur so essentially it's referred to as the golden rule of rebase is you never use this on a public branch which is a branch that anyone else could be um kind of using now this is a little confusing because if I have a local branch it's fine for me if I'm working on kind of a local feature Branch to rebase that Branch against my main Bridge it's fine for me to put my C1 Branch like it is right now because I'm the only one working on this C1 Branch I can fix all of the conflicts and then I'm going to push that up to get I'm going to have my nice clean history I can then merge that in to my main branch and then anyone else can simply pull the main branch which will have its nice clean linear history and then allow uh allow them sorry to just continue working so the simple summary here on when to use rebase is when you're working on a private Branch so that means pretty much only you are working on the branch and you're trying to update essentially the state of your branch to match the state of a remote Branch or some other Branch you can use rebase however if you're working on any kind of public Branch then instead you're going to want to use merge that you don't lose any history and you're not going to mess anyone else up that is using that same Branch so just remember those two rules if it is a public Branch then you use merge if it is your own private Branch then you are fine to use the rebase command foreign switched back to the computer and for this next section in the video what I'm going to show you is how to check out and modify an existing Branch from GitHub that is not the main branch so you can see here that I've created a new branch called Tech with Tim patch one I've made a pull request using this branch and let's say that now I'm a new developer I'm looking at this code and I want to modify this Branch so maybe I want to push directly to this pull request or I just want to get access to the branch whatever I want it from this remote repository how do I get this well let's go to my local GitHub repo here and first I'm going to type git Branch notice I don't have this Branch even if I type git pull and this will actually give me all of the branches by the way from the remote repository if I didn't already have them even when I type this and I type git Branch again it's not going to show me this Branch now there is a way to view these kind of remote branches however if you know the name of the branch and you just want to it's directly go to the state of that Branch then what you can do is to follow it you can type git checkout and then you can just put the name of the branch in this case it's going to be Tech with Tim patch one now notice that I haven't put hyphen B I didn't put origin I didn't put anything special I'm not creating a new Branch I'm checking out a branch that exists on the remote repository so since I know the name I'm just going to put it here and when I hit enter it's going to say switch to a new Branch so it automatically creates one for me and this branch is tracking the remote repo now what that means is that I'm gonna have the same state as the remote repository Branch at the time that I ran this code and now any changes that I make are happening locally and I can and then push them to the remote repository so let's say I go here and create a new file okay new file.txt a new text all right perfect I can now type git add Dot get command hyphen m create file and then I can push this now to the remote repository so I'm going to type git push origin Tech with Tim Dash patch dash one okay I do that I'm now able to push my code I go here and refresh and notice that I've added this new commit to this Branch okay so that's something you can do fully valid I just want to show you that's how you do it you check out the branch name it's then going to essentially track that Branch from the remote repository if the branch exists on the remote repository and then you have that state and then you can do whatever you want now similarly someone else may change something on this Branch right so you go to Tech with Tim patch one maybe they go to feature uh go here and they edit this and they say another line okay so let's do this commit changes I'm just going to commit uh directly commit that to the branch okay now I'm here and you'll see that I don't have these changes so if I want to get those changes then I can type get pull now what might happen is I could maybe potentially have a conflict here right so like I edit this line and then I type get add dot get commit hyphen M okay I don't know fix whatever I'm just doing random commit messages and then I try to push this again get push origin I should already have this command okay so you can see here when I ran this command that now I'm getting an error message and it's saying the updates were rejected because the remote uh contains work that you do not have locally this is usually caused by another repository pushing to the same ref you may want to First integrate the remote changes with the git pull before pushing again so I'm just going to clear here and what I can do is type git pull and this will be connected to that Branch when I type git pull it will automatically pull those changes and then what I'll need to do is fix the conflict because I have edited the same line so I'm just going to accept the current change here and then I would go get add Dot get commit hyphen M fix conflict okay and now I can go get push origin Tech with Tim Dash hatch dash one and now I'm able to push the changes because I have integrated them with the remote Repository foreign so continuing here I'm now going to show you how you can use the cherry pick command and how you can reset your git branches and state now these are more advanced commands you want to actually know what you're doing when you're using them uh they're not overly complicated but they can mess things up quite badly if you don't know what you're doing so just kind of be careful with these commands if you are using them in your own GitHub repository anyways First Command I want to show you is the cherry pick command which is extremely useful when you have a few commands where just one commit that you want to apply onto a different branch so let's say I'm doing a ton of work on a feature Branch all of a sudden I come up with a pretty critical bug fix and I fix that in one commit now my feature isn't finished but my feature Branch contains the bug fix so rather than me trying to finish the feature bench really quickly or trying to kind of uh submit a half finished feature what I would do instead is I would simply cherry pick this commit off onto a new branch and then I would push that new Branch to GitHub and merge that with my main branch so that I got the bug fix in immediately but I could still continue to work on my feature Branch without pushing that kind of prematurely so this just allows you to take any work you do in a commit and apply it anywhere else use it however you see fit but it's a useful command so I want to show you how it works now when I uh kind of frequently use this command is when I accidentally make a commit on the wrong branch and then I want to move it to another one so let's say that I create this new feature Branch okay and I'm going to do all kinds of work on this feature Branch blah blah but in the meantime I check out the main branch and I pull it just to make sure I'm up to date okay great I'm up to date next day comes along all of a sudden I come to my git repository and I'm like all right I'm gonna start doing my work and I forget that I'm on this main branch so I do my work I add my critical file here and I add my commit so I go get dot get commit hyphen m add python file and all of a sudden I see Main and I go oh no I've made a mistake what do I do now well not to worry we can use the cherry pick command so first of all I don't want this on the main branch so I want to get rid of it from the main branch but I want the work still and I need to move that to another Branch so I'm going to type git log and I'm going to look at the commit hash so this is the hash of the commit that I just made there might be multiple commits by the way that you want to move over in that case you're just going to repeat this process but I grabbed the hash of the commit that I want to move so I'm going to copy that I'm going to quit here I'm going to check out the branch I want to move it to so git checkout in this case feature and then I'm going to type get Cherry Peck I'm going to paste the hash I'm going to cherry pick this commit over to this new bridge so easy as that I've now moved this commit over and if I go back to main now okay you see that I still have the code here so I haven't removed it from Main but I took the commit and I applied it onto the feature branch so now kind of step one of my problem is done I've saved this code and moved it over to a new Branch where it's supposed to be but now I need to get rid of it from this main branch so there's a few ways that I can get rid of it first of all I can just revert back by one commit second of all I can actually reset to the state of my remote repository so I'm going to show you a few different ways to do it the first one I'm going to show you is what I will typically use because I always want my main branch to be up to date with the remote repository main branch so if that's the case if that's all you care about you just want to be completely up to date you don't have any work on the main branch that you care about losing then what you're going to do is type this get reset hyphen hyphen hard this is a dangerous command I'm going to explain this but be careful when you use this and then origin slash make now what this means is I'm going to reset my current Branch to essentially just match origin main now what this dash dash hard means is that I'm going to reset the working tree as well as the get index that essentially means that any files that I've worked on but I haven't committed yet those are going to be deleted so if I've added them into the staging area like they're currently being tracked by git they're going to get deleted now I can kind of prove that to you if I create file txd or text.txt okay I go here and I just add it alright so I've added it to the staging area but I haven't deleted it now if I run git reset dash dash hard origin main you're going to see that that file gets deleted so that's what happens when you do hard all right now if you do soft which is the next one so let me show you this if I create a new file text Dot txt the same thing is going to happen but it's going to keep any that are in the staging area so if I go here and I add this into Stage changes now if I go get reset dash dash soft then what it's going to do is it's going to keep this text file it's not going to delete it because I did a soft reset which means yes the entire like git history this Branch got reseted uh I'll grab reset it sorry got reset but I keep any files that were in my staging area there's a few other options you can use here when it comes to resetting typically I just use hard and that will essentially do a clean kind of reset for you get rid of any changes and just make sure that your branch is up to date with the remote repository again a slightly dangerous command but something that I would keep in mind [Music] so with that said I'm going to start wrapping up this video as a reminder on May 9th I'm teaming up with Microsoft to host a 45 minute long webinar as a part of the developer digital Meetup tour this webinar will go much more in depth on git and GitHub talk about best practices Advanced developer workflows and also discuss vs code GitHub actions and many more topics if you want to register for that you can go to AKA dot Ms slash Tech with Tim and if you are watching this video after May 9th you can still click that link from the description to access the recording with that said I hope you enjoyed the video and I look forward to seeing you in another one foreign [Music]