Source Control (4-7), Git - Get A Specific Version Or Commit

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

In TFS (Team Foundation Server), or the old SourceSafe, we always used Get Latest Version, whatever download file from Server to Local, or before Merge.

Sometimes, we used Get Specific Version, to get previous one version to test or to get some files. We could also against one version through View History and then Get This Version, to get a specific Version:

We want the same concept in Git or DevOps operation. However, in this field, not like in TFS it is called Get Specific Version from a Branch, the corresponding concept is called Check Out, and Specifically, Check Out a Commit.

The Check Out is a quite confusing concept in Data Source Control field, let us discuss the Check Out meaning first in Section B, Thereafter, we discuss the Check Out for Command Line and for Visual Studio Environment, respectively.

This article will discuss this issue.

A - Introduction
B - What is Check Out
- Check Out In SourceSafe or TFS
- Check Out in Git
  - Check Out for a Branch
  - Check Out to a Specific Commit, or Version
C - Check Out from Command Line
- Check Out Branch
  - Check Out
  - Switch
- Check Out Commit
  - HEAD Pointer
D - Check Out from Visual Studio
- Check Out Branch
  - Check Out
  - Switch
- Check Out Commit
  - Visual Studio 2022
  - Visual Studio 2019 and Before

B - What is Check Out --- Definitions

This is a quite confusing concept.

In SourceSafe age, i.e., standalone or in TFS, centralized server,
- Check Out --- local version
- Check in --- server version, can be shared or accessed by others
In Git age:
- Check Out usually talks about Check Out a Branch, a check out Branch means the files are in the working space
Here, we consider
- Check Out a specific version in a Branch or
- Check Out a commit

In SourceSafe or TFS:

We have a graph, in the article: Source Control (1), MS Source Safe --- Stand Alone App

when checking out, the file can be changed in the working local space while checking in means the file are saved into server, and other people can use it.

We can more details about TFS Check in or Check Out info from this article: TFS “GetLatest” and “GetSpecific” version of code.

Git ---

Checking Out Branch:

While in Git, the concept is different. Most time, we will want to checkout a branch (and not a specific revision).

Branches are pointers that point to the latest commit in a certain context. This means that, actually, branch does not point to a certain commit but really always points to the latest commit on the corresponding branch. This also means that, if a new commit is made in that context or Branch, the branch pointer is automatically moved to that newest commit. The user does not have to do this manually.

This makes branches a very safe and convenient tool in Git. As said, most of the time we'll want to "checkout" branches, and not individual commits. While sometimes, we want to

Checking Out Commit:

Actually, this concept is between Git and TFS. In Git, we Check Out Branch, actually the HEAD of the Branch, while in TFS we Check Out version, actually any version within the Branch.

Now, when we use Git, we try to get the benefit of TFS Check Out, say, to a specific version. We will discuss how below.

C - Check Out from Command Line [Ref]

Check Out Branch:

git switch my-branch-name

git checkout my-branch-name

With the git switch command (or, alternatively, the git checkout command), you can simply provide the name of the branch you want to checkout.

This branch will then be your current working branch, also referred to as "HEAD" in Git. Any new commits you make from this point on (until you switch branches again) will be recorded in this branch's context.

Check Out Commit:

There are very few reasons to checkout a commit (and not a branch). Maybe you want to experiment with a specific, old revision and therefore need to have that revision's files in your working copy folder.

To checkout a specific commit, you can use the git checkout command and provide the revision hash as a parameter:

git checkout 757c47d4

You will then have that revision's files in your working copy. However, you are now also in a state called "Detached HEAD".

The HEAD pointer

in Git determines your current working revision (and thereby the files that are placed in your project's working directory). Normally, when checking out a branch, Git automatically moves the HEAD pointer along when you create new commits: you're automatically and always on the newest commit of the chosen branch.

When you instead choose to check out a specific commit hash, Git will NOT do this for you. This means that when you make changes and commit them, these changes do NOT belong to any branch.

The consequence is that these changes can easily get lost once you check out a different revision or branch: not being recorded in the context of a branch, you lack the possibility to access that state easily.

To make a long story short: be very careful when checking out a specific commit instead of a branch (and make sure this is really what you want and need).

D - Check Out from Visual Studio

Check Out Branch:

The same as Command LIne command, we have two commands, one is Check Out, another one is Switch

Check Out:

Open Git Repository window.--- we get this paragraph from my another article Source Control (4-3), Git - Cherry Pick In Visual Studio

Choose Git => Manage Branche:

Or,

We have the Repository Windows open:

Check out the Target Branch:

We can either from Repository Windows: right Click master (the target branch) => Checkout

We got the master checkout (master branch is in bold):

Switch: --- the following is equivalent to Command Line Command: Switch

Or, from the Git Changes Windows, Click the arrow on the right of the Opened (checkout) branch window => choose master, the target

then, we got the master branch opened, or checkout:

Note
Here, the Check Out is not TFS traditional sense of Check Out, that the file is Checked out into local folder:

Although the Branch is checked out, the file are still within the Branch without changes:

The Check out only means the files in the Branch are in the local Working Space where we can work on it, either running the app or change the files.

Check Out Commit:

Visual Studio 2022

This is a new feature for Visual Studio 2022, there is Check Out (---Detached) feature, we can see it in details from this article Introducing new Git features to Visual Studio 2022