How to Undo Mistakes With Git Using the Command Line

hello free code cam friends my name is tobias and today i will guide you through a very important topic how to undo mistakes with git because i think this is really one of the core skills to master as a software developer how to undo mistakes how to deal with them and how to undo them because the beginner and the professional alike we all make mistakes but the professional knows how to deal with them and how to undo them so let's see how we can do that and how we can learn to better deal with mistakes but first a huge shout out to the people at free code camp for doing an awesome job of teaching people how to code for free and thanks for letting me help you with that mission a couple of words about me and about why i chose this very specific topic so one of the reasons is i am part of the team behind tower tower is a git desktop gui for mac and for windows and we've been around since 2011 and helped over 100 000 software developers all over the world in companies big and small let's say work more easily with the git version control system work more productively with git and today's workshop will mostly be on the command line get on the command line so you don't have to have tower installed don't worry and the reason why i chose this topic undoing mistakes is that sometimes i feel like that little man here in the middle of the lion cage there's so many things to do wrong there's so many things that can break in a complex software project today and things will break let's let's be honest they will break and this is what git is actually for git is our safety net git is therefore helping us undo things and recover from mistakes and the the thing that i noticed in talking to to other developers is that many of them don't know that git has these amazing capabilities to help you undo mistakes so i think that it's really really crucial to learn what git can do and how you can do that and that's what we will talk about today in this workshop i have 17 cases of how to mess up and to correct with me today and they'll get a little bit more complex towards the end so depending on your own level of gift knowledge you might want to concentrate on the first half little easier cases and and then the second half is more complicated so depending on your own level of of skills all right i would say let's dive in and start with the first very simple case so let's talk about how to discard local changes in a file so you made some changes in in a local file and haven't committed those changes yet and you notice well not the best work i want to undo those changes and get back the last committed version of that file let's see how we can do that so we have a couple of changes here so let's take a closer look at what we did with imprint html with git diff and the file name i can take a closer look at the changes that happened there and let's do that for imprint html okay so i changed the the title tag here and let's say this isn't what i really wanted and i want to undo that and get back to what i last committed and the command to use here is git restore and then the name of the file in print html in in the past you might have used git checkout to do that that's also possible of course but the git restore command a little bit newer you could say is a little bit clearer that the purpose is very limited of git restore so there's less ambiguity around that so git restore and the name of the file and let's see what that what that did get status voila imprint html is not amongst the changed files anymore so we undid that all right git restore and the file name along the the course of this little workshop you will see those yellow warning boxes on my slides and first case first warning box i'm very sorry but that's life in these first couple of cases we're talking about uncommitted local changes changes you have not committed to the git repository yet and the thing to keep in mind here is if you undo those if you discard those they're gone right you can't get those back so be a little bit careful with those and don't rush things all right number two similar but a little bit different here we didn't only make changes we also deleted a whole file and let's say we desperately want that file back and see how we can do that all right this is case number two sorry and again get status to see what we have okay so let's see that let's say that arrow html the deletion of that file wasn't our best move so to get that back the good news is it's the exact same command as before git restore and the name of the file and if i do that get status so it's not listed as a changed file anymore wonderful and let's really make sure voila here it is back again as a physical file in my working copy on my disk so we brought that back from the dead all right again git restore and the file name of the file you have deleted and went back number three let's get a little bit more granular and maybe more interesting sometimes not all of the changes that we made in a file are bad right sometimes we have good days or mixed days and not everything is bad and we don't want to throw away we don't want to discard everything just parts of our changes and we want to keep other parts of the changes and this is possible with git so let's look at let's look at how to do that in practice number three and let's take a look at what we did with index.html and you'll see we have two chunks of changes here so in the first chunk i manipulated a list i added some list items to to an unordered list and in the second chunk here i manipulated a link so let's say the first one is genius work and the second one is bad we want to keep the first one and get rid of the second part of the changes right so bonus points if you can guess the command yes it's git restore again but this time the secret sauce is dash p to go down to the patch level and talk about individual patches or chunks hunks of changes and i think we wanted to do that with index html and let's do that so git now steps through every chunk or hunk of changes together with us and asks us a simple question down at the bottom do you want to discard this hunk from the work tree don't ask me what all of the letters and options mean i do not know i want to sleep at night but it's a simple question do we want to discard it yes or no that's the most simple possibilities and i think we said we want to keep the first one so i don't want to discard this no but the second one i want to get rid of so yes discard this all right let's see what we have so this is tower this is the graphical user interface for git that we make and we work on index html wonderful so that the second part of the changes the second chunk is gone we discarded that but we kept the first chunk alive you can also go one level more granular you can also do the thing that i just did on the command line here in a graphical user interface you can just discard individual chunks but you can go one level deeper you can say okay these two lines here i want to discard these two lines in the chunk but the rest of the chunk should remain intact so you can really be very granular when discarding changes voila or even when you want to stage things for the next commit when you want to add changes for the next commit that's staging and i can say this line here number 17 is part of the next commit but the other line is not so this helps you produce very very granular commits and when you begin working or thinking about that you might say well this is over the top i think it is not i think it really is very helpful because there's a one big general golden rule in version control and that is to commit semantically to commit only topics in one commit that belong to the same overall topic right not to mix different topics in the same commit this is very important and when you want to work in that way working with changes in such a granular way discarding chunks or even lines and staging lines and chunks becomes very very useful and and helpful all right git restore again but this time with the dash p flag so enough sweet talk let's put out the big guns and we want to do undo everything we did since we last committed right this is for the the bad days or for the bad weeks maybe when you when you notice you've programmed yourself into a dead end and you really want to start over you want to get back to the last committed state and start over undo everything and let's see how we can do that in git all right this is case number four and let's see what we have so again a couple of changes in our local working copy here and let's say we really want to undo all of them and get a clean working copy this is again git restore but this time with the dot operator to say well everything in this location should be undone right if i do that and type git status once more voila nothing to commit working tree clean that's what we wanted to have um again please be careful with this command you are still working on uncommitted local changes and if you undo them they're really gone so be a little bit careful with those okay good number five so far from number one to number four we worked on those local changes uncommitted local changes and for the remainder of the workshop we're going to work with committed data right we are going to manipulate committed history so this is a totally different area of the workshop and a total different area of use cases and let's start with something very simple again fixing the very last commit because it's very very common to mistype your commit message or to simply forget to add a certain change this is something that can be done very easily fixing the last commit in git all right number five and let's see what we have okay so this is the very last commit here and you can see well a couple of typos in the commit message we should really fix that and let's do that quickly so on the command line you can use git commit dash dash amend that's the the crucial part and with dash m i can provide a new commit message and hopefully this time a better one typos are indeed embarrassing don't mistype embarrassing that's embarrassing no looks good okay and let's see what happened and voila you might have seen it flicker this very last commit has now been corrected with the commit message that we provided with a new commit message so we fixed that the other type of problem let's say that you can have with the very last commit is that you forgot to add a change that should actually be part of that commit and changing that is actually pretty easy you can simply add that to the staging area that forgotten change and then simply say amend again it's the same thing on the command line and then click amend here and you'll see voila index html is now part of that change set two right um little yellow warning box again so amend is one of those commands that rewrites history as i said many of the the things that we're going to talk about we'll do that we'll rewrite history and this is a prime example and you should keep one rule in mind that will keep you happy and maintain your friendships amongst your colleagues and guarantee a long developer life do not change commit history of things that you have already pushed that you have already shared on a remote branch this is very important because if you do so then the same history the re-written history will be pushed again and that's gonna cause trouble for your colleagues who may have based their work on those old commits so never change history for commits that have already been pushed i'll show you what i mean by rewrite history to make that a little bit clearer i think that's that's helpful to understand so at the moment this very last commit has a commit hash of one two three five f d nine a something like that if i do another amend i can do that as long as i want to are indeed very embarrassing amend let's take another look and voila you saw that the the commit hash changed so git is not able to somehow magically open that commit in the background and then exchange something and then close it again what happens in the background is that a completely new commit object is created and swapped swaps out the the old one right so the the old one is replaced with a new one and this is what rewriting history means there there are really new commits that are exchanged in the background okay number six reverting a commit in the middle so let's start with the good news here c2 here is the bad guy but everything that came before that or after that is absolutely fine we don't want to throw away everything we just want to undo c2 that commit here in the middle and revert has uh quite an a non-destructive way let's say like that a non-destructive way of of doing that revert does not go ahead and rip out c2 and throw it away instead it creates a new commit c4 here in this little example here it creates a new commit that contains the opposite changes and that's how it undoes the problem you had in that original commit so if you look at that silly example here in the old commit i changed about this project into about and git is clever enough to understand okay if i uh introduce opposite changes i will undo the effects of that old commit pretty clever and very um very safe let's say like that okay so let's do this on the command line and first of all let's have a look at what we could undo or revert in that case let's say we want to revert this one here right so if i take a look at the change set here i can see that i changed about into about this project so i'm going to expect the opposite changes when i do a revert on that commit right okay so to revert this one i have to remember the commit hash up here i'll copy that to the clipboard and then on the command line i can just type git revert and the hash of the commit that i want to undo that's actually it and i'm getting an editor window here why is that because as i said we are creating a new commit that reverts the old changes and creating a new commit means there's a new commit message that i could provide and this is the commit message that i could add i'll go with what git support suggests here in this case that's wonderful because it's very very clear we revert this commit here with this commit hash that's that's wonderful i'll take that save and close and take another look at tower and see voila we have a new commit that undoes this one here by introducing the opposite changes very practical all right number seven get revert and the commit hash number seven is a little bit different because here everything that came after c2 is actually bad so we really want to turn back time and go back to c2 and forget everything that came afterwards delete in air quotes delete everything that came afterwards and this is a case for the reset command so let's see how we can do that and again let's see what we want to do and let's say we want to return to this point in time here to this commit here and forget everything that came afterwards so we want to undo delete remove however you want to put it these commits that came later again i need to remember the the commit hash to which i want to return this one here and on the command line i can write git reset dash dash hard i'll explain the the um the option in a second and then the hash of the commit that we want to return to hola let's see okay you just saw it flicker maybe the newer commits disappeared and we're now back at this commit at a previous state in time um you saw me use dash dash hard on the command line so if there's desktop hard there might be other options that's true there's hard there's keep there's mix there is soft i think i i can never remember all of the the options you live a happy life with hard and mixed so you've seen hard hard means no local changes should survive you really want to have a clean working copy mixed is a little bit different let's let's see mixed so the scenario here is the same i prepared the same scenario twice so we will go to this revision here but this time using mixed and the difference is mixed keeps the local changes or the changes contained in the commits that we're going to undo as local changes so these two commits here will be undone but they have a change set of course they have changes that are contained in in those commits and with using mixed we'll do that here reset in tower we call it keep changes on the command line it would be mixed that's the same thing if we do that voila we return to that revision but we also keep the changes that are contained in those removed revisions as local changes and you can hop into your editor make some changes discard things add things you're a little bit more flexible with mixed i would say okay number seven git reset dash hard and dash mixed number eight so far we've mostly worked on the complete project or incomplete revisions and this time i want to work on just a single file sometimes you have the situation that you know a certain file was good at some point but it's not in in the current version and you want to return time or turn back time for just a single file not for the whole project not for the whole history just for a specific file and you can do that with kit and let's see how we can do that and this is number eight and let's take a look at the scenario okay so in tower we have a quite a practical um feature called the file history so i can just right click any file and say show me the files history this shows you only the changes for that particular file so you can very easily see how a specific file evolved over time and so we're doing that for index html let's say we only want to return to this revision for index.html right this is the state of index html that we want to have in our project again so i'm going to copy the hash here again and on the command line you could guess it's restore yeah git git restore the source parameter the source is the revision hash that i just copied and we want to do that with index.html voila and if i do that let's see what happened in the working copy i now have changes that bring back that version of index.html this is these are the changes that bring back that old version of the file again all right git restore source and you tell get from what source revision you want to restore which file all right for the next two cases i think we're going to use a very specific git tool called the ref log the reflog you can think of uh somehow like like git's diary i would say a journal where we get protocols every movement of the head pointer so what's a movement of the head pointer you might ask so this is when you commit when you check out when you reset when you cherry pick when you rebase actually all of the more important actions are protocoled in this journal and this of course makes it perfect for undoing mistakes and let's see what we can do with the refloc for example this here think back two cases i think number seven we did a reset right we rolled back to a specific older revision and did that with the reset command and then sometimes numbers three and four follow you sometimes notice oh damn i shouldn't have done that that was the wrong move and then the panic emoji con often follows and let's see if we can use reflog to undo that and to get back those seemingly lost commits right that's the thing we want to do okay number nine okay so let's say again we want to return to this revision here and by doing that these newer commits here will disappear will get deleted in air quotes so again a reset we don't need to keep changes and boom everything newer is now gone and i'll give you a second or two to notice oh damn we shouldn't have done that and we we dearly miss our commits already and let's see if we can use the reflux to get them back so get refloc to open up the the journal that i just talked about and it's it's ordered chronologically so the most recent actions are at the top and if you look at the topmost item you see okay there's a reset and we just did that 20 seconds ago or 10 seconds ago so the journal works and if we want to undo that the good news is we can just use the state before and restore that one so i'll just copy this here to the clipboard and then i could totally use git reset once more that's possible but i prefer to create a new branch let's call that happy ending and let's start that branch at that revision before we did that mistake and let's see what happened okay happy ending voila here are the commits that we thought we had just lost wonderful we saved the day i think um the refloc if any tower users are amongst you the reflux is also part of the newer versions of tower if you don't see it in your version probably you don't you haven't activated it yet you can activate that in the preferences here show reflog in the sidebar because it's some kind of a an advanced feature not everybody needs it but if you want to have it you can activate it and you can have the different branches sorted and a great tool so you can see what happened in your git repository all right that was recovering deleted commits with the ref log and you can also do other things with the ref log for example this here recovering a deleted branch for example so let's say you have worked on a feature branch for some time and your team lead or your boss or customer says you don't need that feature anymore so to tidy up you delete that and again numbers three and four sometimes follow the feature is not out of the picture just yet and it returns and you notice it was a bad idea deleting that and the panic emoji follows let's see how we can undo that with git and this is case number 10 all right so at the moment we have a beautiful feature login branch that also contains a commit that is present nowhere else so we are going to delete this branch in a second and we're really going to delete data right this commit is present nowhere else so we're losing data right now we'll go on the first thing i have to do is step away from this branch because currently this is the head branch and i can't delete the current branch so i'll double click master to check it out and then right click feature login and say delete i have to force deletion because it contains data that is present nowhere else and voila okay so boom panic we noticed that this actually wasn't a good idea and we need that branch back and let's see how we can do that with the refloc again git reflog and you notice the most recent item here is the checkout that we just did before deleting that branch and that's of course our lucky day because we can just return to the state before again and restore this one to undo what we just did and in this case of course get branch for creating a new branch makes a lot of sense and i think it was called feature login if i'm right and again it should start at the state before the state we just thought we had lost okay feature login seems to be back and including that seemingly lost commit so we just undid that and saved that valuable part of our work one thing i want to show you in tower um since i don't know a couple of versions ago we introduced a very very helpful feature um connected to undoing things when you want to undo something in your text editor you can just hit command z right it's as easy as that and we implemented that for git so if i just delete that once more delete feature login force delete and then hit command z voila the branch is back and this works for deleting branches for deleting commits for staging unstaging discarding changes from making resets for almost anything so you don't have to actually know the different commands that you need to undo things you just need to type command z and that's it very very powerful very practical all right git reflux again and let's move on to number 11 moving a commit to a new branch so the problem here is that we have committed to the wrong branch and many teams have a convention that says you shouldn't commit to a long-running branch like master or develop those branches should only receive commits by integration right by merging or rebasing not directly committing to them but still we do because well we mess up we're on that branch and we type git commit and then it has happened actually in this case we should have created a separate feature branch a new feature branch and committed there and let's see if we can clean up the scenario so that it looks like that like it should look okay and let's see what we have okay so the very last commit on master is start new login feature and of course that smells that should have been the new feature branch that i just talked about and the good news is master already has the state that our new feature brand should have so we can just use that as a basis to create a new branch feature login and voila so now we have that feature branch feature login that contains that commit everything is okay on on that branch but the second part of that solution is of course to clean up master because master is currently in a dirty state it shouldn't contain that commit this last one here so let's move back to master check it out double click and then simply make a reset don't need to keep changes and voila master is now clean that commit that shouldn't have been there here is not here anymore and feature login has the correct state so nobody will ever find out you keep a wonderful reputation amongst your colleagues on the command line you create that feature branch get branch feature login and then you clean up master by using git reset head tilde one means one behind the head so you don't have to copy the the commit hashes all the time and we're doing that with the heart option all right number 12 looks similar but it's a little bit different the problem is the same we committed on the wrong branch but this time the feature branch is already present right we don't have to create that feature branch it's already there we just just in our quotes have to move over that commit to its correct branch and then clean up let's see how we can do that all right this is number 12. and let's take a look at the scenario okay so on master the latest commit reads newsletter sign up page okay while we are having a feature newsletter branch so my suggestion is this commit should have been here and not on master right so to do that let's move over to feature newsletter and then cherry pick that's a new tool we haven't used yet use cherry pick to move over that commit right cherry pick and voila feature newsletter now contains that commit like it should have been in the first place and master still has that so again like in the case before we have to clean up we just reset to that state before well we have to check that out we reset to the state before voila master is clean the the commit that should have never been there is not there anymore and feature newsletter contains the commit that we moved over using cherry pick on the command line a little bit more to do get checkout to move to that feature branch then get cherry pick to move that commit over go back to master and then again cleanup master using git reset hard all right for the last i think five cases we're going to use interactive rebase by some called the swiss army knife of git tools which i find quite fitting because a swiss army knife has lots of different tools but it's still a knife so you could theoretically cut yourself a little bit if you keep that golden rule in mind to not change commit history that has already been pushed then you're fine so many of the the the tools that we have talked about and that we will talk about are there for a very specific use case that will help you clean up your local commit history before you merge that back into a team branch right so you've worked on a feature branch for some time and you could do some cleanup let's say and you can use all of the tools that i just showed you and that i'm going to show you to do that cleanup and then move it back integrate it merge it into a master or develop or a shared branch and push it so interactive rebase what can you do with that you can edit old commit messages delete commits uh combine multiple commits to into one split commits a lot of different things and let's start with very simple case let's edit an old commit message to to show you how interactive rebase works so you might say well we've done that tobias in case number five if i'm right we've edited an old commit message then back then it was the very last commit and that's pretty easy you can use git commit amend for that case but if we're talking about something further back in the commit history amend is not available anymore you have to use interactive rebase to do that and since this this is quite an easy case it's perfect to illustrate how interactive rebase works in general so very generally speaking you have three big steps with every interactive rebase session the first is you have to ask yourself how far back in time in history do i want to go what should be the new base commit what part of commit history do i want to manipulate and then you actually start the interactive rebase session that's step number two and then you will see an editor window where you can determine which actions you want to perform and i'll have some comments on that uh when we see that in practice and let's i'd say we check that out in practice and then discuss things a little bit more okay number 13 and let's see what commit we could change so let's say we want to change the commit message of this old commit here again remember if it had been this one no problem git commit amend wonderful but anything older than that we need interactive rebase for so first step in interactive rebase how far back in history in time do i want to go i could either copy the the commit hash or do a little bit of counting the answer is at least to the parent commit of the one that i want to change right at least to the parent commit so either i copy this commit hash or say head minus one minus two minus 3 and let's start git rebase interactive head tilde 3 we said n minus 3 and let's start voila this is the editor window that i mentioned two notes about this editor window first the order of commits seems reversed right so if you take a look at the the bottom most improved headline for imprint that's actually the top most here in the real history don't be confused by that that's okay from git's perspective we're doing an interactive rebase and git has to reapply the old commits step by step so the reversed order is okay the second note here is we do not go ahead and make our changes we do not change the commit history the commit message right here but we only mark up what we want to do with that commit and in in this case we want to reword reword is documented here use the commit but edit the commit message we want to edit the commit message so save and close after marking that line with reword save close and now finally i can really edit the commit message now is the time to make my changes optimize the general markup structure in index page close save and close and if we take a look at tower we will see wow here it is now it says optimize the general markup structure in index page so we just manipulated history although just git history but a very special case here all right get rebased to edit an old commit message you can also use git rebase to delete an old commit so sometimes not often probably but sometimes you really have a commit that shouldn't have been there at all and interactive rebase allows you to really delete that from the history let's see how we can do that in practice that's number 14. and let's see what we can delete um well let's say we want to delete this one right so again it's still an interactive rebase session so first step how far back in history do i do i need to go at least the parent commit so either copy this one here or head minus one minus two git rebase dash interactive head tilt d2 and voila the editor is back and we said we wanted to delete this one here and i can mark this with drop drop is the action keyword for deleting a commit you could also that's the exception from the rule you could really just delete that line it's an editor right you can manipulate the text here you can delete that line and save and close that will also remove the commit that's also okay but i think it's it's better to stick to the official way of doing things and to properly mark up the line with what you want to do to it so drop save and close and if we take a look at the history voila you just saw it flicker the commit was removed was deleted from the history that's possible with interactive rebase number 15 you can also squash multiple odes commit into old commits into one so in general the the rule in in version control is to commit granularly and rather smaller than bigger but sometimes you might have overdone that let's say and you want to combine multiple commits into one and that's also possible with interactive rebase and git all right number 15 and let's see what we can combine and i would say let's combine these fellas here right these two should be one melted into one and again it's interactive rebase so we have to do the little counting game so at least the parent commit so this is ahead minus one two three and let's start that git rebase dash interactive head till d3 and voila so we said we want to combine these two commits right and the the tool we're going to use here is squash squash is there to meld combine multiple commits into one and the one thing you have to know about squash to use it is the line i am marking up will be combined with the line before the line above so by marking up line number two i will combine it with line number one and that's what we want so let's save and close and again i do get an editor window why is that that by melting those two commits into one a new commit is going to be created and a new commit means i can provide a new commit message so combine two into one i'll leave the the old commit messages here just just in there for us as an overview i could of cour of course change that too and voila here we go we have combined the change sets of course and provided a new commit message here so we combine two old commits into one new one pretty awesome again a note about how to do that in tower it's pretty easy to do things like these in tower you can just drag and drop and this will be a squash right you will combine that very easy so number 16 second to last and actually my my favorite case because it's very very very practical so the scenario is number one we made a mistake it doesn't matter what it is we could have forgotten to add something we should have deleted something we mistyped something it doesn't matter a mistake right and the the normal reaction number two is to add our corrections in a new commit right that's that's just normal that's that's okay the problem with this approach is we have that original commit c2 and we have a correcting commit a band-aid commit c4 right and if you do that a couple of times original band-aid original band-aid your commit history becomes unreadable because nobody understands okay why is that commit here shouldn't have that been here and you have lots of commits and and no semantics actually that band-aid commit doesn't have any semantic meaning it's just there to fix an earlier mistake right and the beauty of the tool we're going to use here which is called fix up the beauty is that we're going to use that band-aid commit apply it to the original one and the band-aid gets thrown away right that mt commit that non-semantical commit that newer one that fix up commit is disposed and the original commit appears to be perfect from the start very beautiful all right enough talk let's do this um and let's see what we have okay so let's say that this commit here is not complete right we made a mistake here and let's also see say that what i prepared here changes in error html would fix that mistake right at the moment error html is not part of the change set here but adding it to the change set would make it complete so first step is to simply add that change to the staging area and to commit it but not a normal commit we are going to use fix up as a as an option and we go we want to fix up this old commit here right that new commit that we are producing should fix this old one and we're going to copy that to the clipboard the commit hash of that one fix up whoa with an x right so if you read that it says this new commit here fixes this old commit here okay let's do that and you probably expected fireworks or something spectacular but i'm very sorry we just produced a new commit with that command but something is cooking here right fix up exclamation mark is prefixed so something is happening here okay the second part of that solution is to use interactive rebase of course we're still in that department of the workshop so we're going to use interactive rebase to fix this one first step in interactive rebase how far back do i need to go at least the parent so hit minus one two three four that's the one we want to correct so at least here all right git rebase interactive head tilt d4 and the second part of that secret sauce here is to use dash dash auto squash right first part is fix up when you commit second part is auto squash when you start the interactive rebase that's a two-part solution and the good news is in this editor window i don't have to do anything git already did all of the hard work for us and i'll explain that to you but just keep in mind nothing to do for us i'll explain what happened and why so the first thing that git does did for us is to mark up that band aid commit here as fix up right this is the fix up commit that's the first thing i didn't do that it's automatically here and the second thing that git did is it automatically sorted this line to the right position right because actually change headlines for about an imprint the fix up commit should be the bottom most right reverse order so it should be down here but git already understood okay we want to use this to fix up that other old commit so i'll position it here because it works just like squash squash you remember the rule squash combines with the line above fix up also combines with the line above so nothing to do for us just save and close and if you take a look at that this is the one we fixed up and now it contains error html it is correct and the ugly band-aid commit has been thrown away wonderful beautiful commit history nothing is dirty nothing seems to have been broken everything's fine again if you want to do that in tower very very simple just drag and drop and keep the option key pressed and voila this is a fix up very very easy okay um git commit fix up and get rebus interactive auto squash a two-part solution and here we are at the last case of this workshop and this is actually just to to show off a little bit about what interactive rebase can do because the answer is anything actually anything so split or edit really opens up an old commit for editing it again very very beautiful so um we can edit that old commit add new changes delete something add files and then make multiple new commits out of that change set very very flexible and let's see how we can do that this one is quite a lot of work to do on the command line so i'll show you how to do this in tower and you know that it's possible if you ever want to do that we need something that has a couple of changes so let's take this one so in tower i can just right click and say edit and this brings me right into the middle of an interactive rebase session where the whole contents of that old commits are here in my local working copy so i could just as i said hop into an editor make some changes or say well this here really doesn't make sense i'll throw that away and this and this is actually one topic so commit number one we wanna uh as i said the the general rule is to commit only things that belong to the same topic so this is one topic and this is actually a second topic so let's make that commit to and then i can hit continue continue closes the interactive rebase session and voila i just split edited an old commit and created two new ones out of that very very flexible and allows you to clean up your history in a very elegant way all right i think i've said it a bazillion times but let's say it one more time many of the tools today that i showed you do rewrite history and the rule to live by is don't use these tools for read writing commit history that has already been pushed to a shared repository right use those things to clean up your local history before you merge that back into a team branch and this is true for amending commits rebase interactive rebates definitely sometimes reset so be a little bit careful and use those only in the right situations all right what we have done is we've created little videos of those 17 cases and a very handy cheat sheet with some problem situations and the solution for that if you want to get that that's free to go so go at bitly and get first aid kit if you want to download that that's it from me thank you very much for your attention and i would say have fun breaking things and of course repairing goodbye you

Channel: freeCodeCamp.org

Views: 45,544

Keywords:

Id: lX9hsdsAeTk

Length: 55min 20sec (3320 seconds)

Published: Tue Nov 24 2020