Note: This is a series of articles related to Source Control. If you have read my other articles in this series, you may skip the top general part and jump to INTRODUCTION for the specific topic of this article.
This is a series of articles related to Source Control or Version Control issues, from a stand-alone app, such as MS SourceSafe, to a Server app, such as MS TFS (Team Foundation Server), to web services such as GitHub, AWS, and MS Azure DevOps. We have tried to categorize this series of articles as Source Control or Version Control, but this site does not have these categories. So, we put the articles in the DevOps category, as explained in the Wiki:
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.[1] DevOps is complementary to Agile software development; several DevOps aspects came from the Agile methodology.
The structure of this article series will cover:
- Stand Alone App:
- Server App
- MS TFS (Team Foundation Server)
- Online (Cloud) Centralized Service:
- MS Azure: DevOps
- Boards
- Repos
- Pipelines
- Test Plans
- Artifacts
- GitHub
- AWS GitHub Enterprise
- Distributed App:
Because these are huge topics, I will not go step by step. Instead, each section will be relatively independent and will become a reading unit.
- Source Control (1), MS Source Safe --- Stand Alone App
- Source Control (2), MS TFS --- Centralized Server App
- Source Control (3), MS Azure DevOps (GitHub, Jira) --- Centralized Service
- Source Control (4), Git --- Distributed App
- Source Control (4-1), Git --- Configuration
- Source Control (4-2), Git --- Configured to Connect to DevOps and GitHub
- Source Control (4-3), Git --- Cherry Pick in Visual Studio
- Source Control (4-4), Git --- Recover Git Tree: Reflog/Reset --- this article
- Source Control (4-5), Git --- Recover Deleted Branch
- Source Control (4-6), Git --- Revert
- Source Control (4.7), Git --- Get Specific Version or Commit
- Source Control (4.8), Git --- Get Specific Version or Commit in practice
- Source Control (4-9), Git --- Merge: Fetch, Pull, Push and Sync
- Source Control (5), GitHub access (setup connection)
- Source Control (6), DevOps access (setup connection)
- Source Control (7), GitLab access (setup connection and Clone to Local)
- Source Control (8), Git, Azure Repos, and Visual Studio (Interaction)
- Source Control (9), Push into Git Hub and DevOps
- Source Control (10), Git Hub, DevOps Publish
A - Introduction
Once I accidentally have deleted more than dozens or hundreds commits from one of my project, those are around 10 days of work. I needed to recover them for sure. After about one day search, I got the solution. Because everybody could get this mistake, and it is very dangerous, we should have a regular way to fix it. This article will discuss this issue.
- A - Introduction
- B - Problem
- C - Solution
- C.1 - Git Reflog
- C.2 - Git Reset
B - Problem
I made a mistake accidentally deleting more than dozens or hundreds of commits for one of my project. What I did? I tried to roll back one commit, but not sure the way to do it, I used the reset command in Visual Studio, I got rid of the tree from the reset point that includes around more than 10 days of work.
This is the simulated procedure as what I did:
Made a reset -- keep Changes (... mixed):
I got the all tree above the point disappeared --- that was not what I expected. To make it back, I miss all changes and checked in.
The result is totally losing the tree above. This is what I lost:
C - Solution
The solution actually is very simple, but very important, because everybody could get the situation I got, this is the way to make it recover.
Recover from losing uncommitted changes by "git reset --hard" - Stack Overflow
Recover from losing uncommitted changes by "git reset --hard" - Stack Overflow
Note,
There is another article very helpful, Git Reset Clearly Explained: How to Undo Your Changes | CloudBees, explaining the detailed process and reasoning. But for me, the simple and direct solution is what I need.
C.1 - Git Reflog
This git command will get all git tree information --- Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository. [Git - git-reflog Documentation (git-scm.com)] Such as
This is a very important command, that can give you all info in this depository, such as Branch, each HEAD point with a number, each and every action you made for this depository.
C.2 - Git Reset
The git reset command in prompt includes two:
- git reset <commit-id-retrieved-using-reflog>
- git reset --- hard <commit-id-retrieved-using-reflog>
They are corresponding to the Visual Studio commands:
git reset <commit-id-retrieved-using-reflog>
git reset --- hard <commit-id-retrieved-using-reflog>
Hard Reset
We discuss the
- git reset --- hard <commit-id-retrieved-using-reflog>
first, this is simple one and mostly used one. Another one is just adding some variation to this.
We made a test set for this:
where the current HEAD is at 5ed4f92b in Green frame, we want to switch to target HEAD as be1d4dd38 in Blue frame:
Run the command:
We can see the all HEAD position for each commit, and the actions we made:
Run the command to switch the HEAD position from 5ed4f92b in Green, to be1d4dd38 in Blue:
Run the command:
the action made in Red frame:
Check the result in Visual Studio, we see the current HEAD in Blue, is at be1d4dd38
due to this being a hard reset, we realize that no uncommitted files in the right panel:
We can see the difference when we do the soft reset.
Now, we switch back to the HEAD point at 5ed4f92b in Green,
Run git reflog, we will have the action played in Red :
and in the Visual Studio, the git tree will be back and HEAD will point at 5ed4f92b in Green,
Soft Reset
We discuss the command:
- git reset <commit-id-retrieved-using-reflog>
this is the same as hard reset, except that after switching from one HEAD point to another, all changes between will be shown as uncommitted, like this for switching from 5ed4f92b in Green, to be1d4dd38 in Blue:
in which, we can manage the changed content between the current HEAD and the target HEAD. This may be useful for the situation where you made something not correct for the last commit, and wanted to make the change.
Reference