11/12/2023 0 Comments Git reset soft vs hard![]() 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). If you do a git reset -hard after git add and git commit, your new changes before staging will still be in your directory.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. Scenario 3: Changes not staged nor committed git/lost-found/other to check all the dangling blob content Git show > recover.txt to send the content of the blob to a fileĪnother option is to use git fsck -lost-found to move all the dangling blobs to lost-found directory. This will help us retrieve the content of the files that were staged but not yet committed Use git fsck to check dangling blob hash id (blob that has no commits associated to it). If you do a git reset -hard after git add but before git commit Scenario 2: Changes staged but not yet committed To fix the detached HEAD state, create a new branch and merge the branch back to master Switch to the commit you want to recover, now your repo will be in ‘detached HEAD’ state Retrace the commit that you need to recover If you do a git reset -hard after git add and git commit Recover files after git reset -hard in 3 scenarios Scenario 1: Changes committed $ git commit -m "Add test2" Add test2ġ file changed, 10 insertions (+ ) create mode 100644 test2.txtĢ. " to include in what will be committed ) test2.txt
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |