Source Control (4-6), Git

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:
- MS Source Safe
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:
- Git

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.

A - Introduction

1, The concept REVERT in git is similar to or, even we can say, the same as ROLLBACK in MS TFS (Team Foundation Server).

If we had experience with Rollback previously in TFS, we wanted to learn about revert, probably we would google the keyword, Rollback, the functionality we wanted to make. However, the results must not for revert in git, but for rollback for TFS, such as Rollback changesets - Azure Repos | Microsoft Learn, although it titled by Azure repos, but actually it is for TFS:

Do not confuse Git and TFS, but, their features or functionalities are quite similar or same. I assume most of discussions below for Git Revert, are the same for TFS Rollback, we will have an address below.

2, Revert seems a simple concept, but if you had a chance to look around, you might find out a lot of articles to discuss this topic, but hardly have a very clear view on it, just like a puzzle. So, this article will make an example, and try to draw an intuitive picture on it.

This article will discuss this issue.

A - Introduction
B - Test Environment
C - Simple Revert --- Single Level, Single File
D - Revert with Multiple Level Changes
E - Revert with multiple items involved
F - Revert with multiple items and multiple levels

B - Test Environment

We use Current Visual Studio 2022, Version 17.2.3. We will play git through Visual Studio.

1, Add 6 files into it as A.cs, B.cs, E.cs, F.cs, G.cs, H.cs

After adding each file, we make a commit to git with the name the same as file name: A, B, E, F, G, H. When completing the process, Click Git Repository in Team Explorer:

We have a Git Repository Windows open to show the commits: A, B, E, F, G, H:

Double Click on Commit A, we open a commit 0d4f98a4 windows with three panels: the right panel shows the files changed, the left two panels show the highlighted file in the right panel before the change, left panel, and after the change, middle panel:

Because the file A.cs is added, the project file WebRequest.csproj is changed, too. So, when we made a commit, the project file is also checked into Git Repository. In Visual Studio, we click the Project file in the right panel of the commit Windows, we can see the change from the left panel (before) and middle panel (after):

Double Click on H, and we get the Commit 9683806a, the same as A, when the file is highlighted in the bottom right panel, the A.cs changes are shown in the bottom left and middle panels:

When the project file is highlighted in the bottom right panel, the project file changes are shown in the bottom left and middle panels:

2, Make Changes for each files:

For convenience of analysis, we make a change for each file, at this point, only one file is changed, such as for A.cs, we have:

For H.cs, we have:

C - Simple Revert -- with Single Level, Single File

We consider the commit: F Change:

Right Click on F Change => Revert

We get new commit: Revert "F Change":

We can see that File F changed back to what it was in commit F, while the F file itself is still in check-in status:

We Revert the commit: Revert "F Change" once more, we will get Revert "Revert "F Change" commit:

while the F file itself is still in checked-in status:

If we revert A, we will get the similar result:

D - Revert with Multiple Level Changes

Now we make a second change for B.cs, and make it commit as "B Second Change":

We consider the commit of "B Change":

Revert "B Change":

Now, the B.cs is in the second change status, while we want to revert the change page back to the original one, but keep the second change, the system is not as smart as that, it is confused, so the revert change will not immediately happen, but with a conflict page check out waiting for you to handle it:

Click the conflict file, we got a choice for the merge:

We have three choices:

The default one on the bottom panel: Change back to "B Change", Get Rid of the "B Second Change"
The top Left Panel: Change back further to "B", Get Rid of both "B Second Change", and "B Change"
The top right Panel: Keep the current version with both "B Change" and "B Second Change"

i.e., at a given point to Play Revert, we can either get back to the point (default to get rid of the changes later) or get the point before the Change. As we expected, we want to remove the change in the specific point (B Change) to back to the previous one but keep the later changes, they are not included, or we have to play something by ourselves.

So, we can make any "Rollback" as the choices:

Back to the Revert Point or
Back to Before the Revert Point

If we feel not comfortable with the result, we can easily ABORT it:

Now we make another test to add one more change for B: "B Third Change":

We play the REVERT at the same point at "B Change":

The result is the same as before: only one more level changes:

The default one on the bottom panel: Change back to "B Change", Get Rid of the "B Second Change" and "B Third Change"
The top Left Panel: Change back further to "B", Get Rid of All later changes
The top right Panel: Keep the current version with both "B Change" and "B Second Change"

i.e., this is the rule we play the REVERT with multiple level Changes.

E - Revert with multiple items involved

We make changes for both File E.cs and G.cs, and make one commit for the changes as "E and G Change in one Commit"

The result is like this, the commit "E and G Change in one Commit" includes two files, one is E:

another file is G:

Revert this commit:

Both files in this commit will be reverted or rolled back to the original status without any files checked out. This is for E file:

This is for G file:

Revert commit with multiple files are exactly the same as that have a single file --- Revert back directly without the need for a checkout.

F - Revert with multiple items and multiple levels

This situation will be a combination of D and E.

In practice, in some complex situation, when one commit included more than several files, while we only want to revert one of them, using Revert will not work. See the example below:

We make a new commit with two files changed: E, and F, the commit name is "//Change E, F together and Test if we can revert only one back":

Right Click E.cs File in Solution Explorer => Git => View History

From the History in E, Righ Click the new commit, and Revert:

We expect to get only E file reverted, but actually, E and F both are reverted:

So, when we make commit, we should make it step by step, and with as less as possible files involved, in case later on, we might need to revert some file(s) back.

Reference