![]() ![]() Now add and commit the changes with the commit message test.txt v1a - based on v01 with modifications. Make any other modifications that are required and save the file (we will call this V1a for simplicity). Next either open up the latest file, the V03 file, that is in the working area, delete everything and paste in the V01 copied contents from the clipboard, or just overwrite the file with the copied version.Įither way, the test.txt file in the working area now contains the V01 version that we copied from the step 6 hard reset. You need to be careful with these floating commit points, they are deleted when the database is cleaned up ( pruned in Git terminology-it’s gardening, like branches). It’s perfectly possible to switch to the missing commit point. The missing commit point is still there †1, it no longer fits into the chain of commits-it’s just floating around in the Git repository. A bit like Stalin, we’ve rewritten history. The problem is what if we make changes at this earlier commit point?ĭo it, modify test.txt this time we’ll call it V05- like the shampoo (I used V04 before remember)-commit the changes, this is commit. We can still move back to the commit point because we did in the previous section. This makes sense, the history only includes things up to the current head point. This overwrites the staged and working areas with the files from the commit point. Now hard reset back to commit point just like we did in the previous section-we get exactly the same result: This is a bit like going back in time and accidentally killing your own father before you were born-it leaves things hanging.Ĭurrently we are at step 5 and our commit history is: I will start with a hard reset like a hard Brexit, it’s the option that makes most sense. The worst a reset can do is overwrite changes in working or staged files. That said:Ī reset will never change or delete committed data.Ĭommitted data is always safe, a commit point will never be deleted and you can always go back to it. The reset process can be destructive it can overwrite data (it’s one of the few things that Git does that can lose your data). I’ve shown the modified and staged file version in red. Now add and commit the file to the staged area. Do not commit these changes this is work in progress and I will use it to show how the different types of reset work. The staged area always holds the files, but if they are the same as the committed files, Git considers it to be empty-it isn’t, but there is nothing in there that requires action.įinally, let’s modify the working copy of test.txt (making it V04) and add it to the staging area (step 6). In practice, the staged area does still hold the files (I showed it as empty to make the explanation easier to understand). Some of you may be wondering why I show files in the staged area after a commit, when in Figure 2.7 to Figure 2.10 I showed it as empty.Now add and commit the file to the local repository to give 3 commits in total. Now we do it all again for a third commit and a file at V03 (step 5). Now add and commit the file to the local repository. Now let’s modify the test.txt file (making it V02) and repeat the add and commit process to give our second commit (step 4). Now commit the file to the local repository. This is now in the working area and is version V01 of the file.Īdd the file to put it in the staging area. In a new repository create the file test.txt and add some text to it. Next add the file to the staging area (step 2) and then commit it to the local repository (step 3): This file is present in the working area only, we haven’t added or committed the file yet (step 1). Let’s assume we have a new project and we’ve just created a new file called test.txt. I will go through modifying the file and creating commits in a step-by-step way to demonstrate exactly what happens with a reset. To explain this let’s consider a simple project with just one file ( test.txt). The easiest type of reset to understand is the hard reset it resets a project back to an earlier commit and replaces all the files in the working directory with the files that were present at the time of the specified commit. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |