Earlier comments in the bug report allude to other ways to checkout the exact desired branch name, so long as you have a bash compatible interpreter available (most Unix variants).

I used this (combined with the earlier checkout to a specific branch name) as a shell script step to checkout a tracking branch

HEAD=$(git rev-parse --abbrev-ref HEAD)
CURRENT_BRANCH=remotes/origin/${HEAD##*origin/}
WORKING_BRANCH=${CURRENT_BRANCH##*origin/}
git checkout $WORKING_BRANCH || git checkout -b $WORKING_BRANCH -t $CURRENT_BRANCH

Code changed in jenkins
User: Mark Waite
Path:
src/test/java/hudson/plugins/git/TestBranchSpec.java
http://jenkins-ci.org/commit/git-plugin/91a1ffc3a6030e8d74fe463edff13d7f1f08fd41
Log:
Add tests exploring JENKINS-6856 - token macro expansion

BranchSpec does not seem to honor token macros. For example,
$GIT_BRANCH matches as expected
${GIT_BRANCH} matches as expected
${GIT_BRANCH,fullName=False} does not match
${GIT_BRANCH,fullName=True} does not match

I expected either all of them to match as expected (token macro expansion
was being applied), or none of them to match (no variable expansion and
no token macro expansion). As far as I can tell, variable expansion is
being applied, but token macro expansion is not being applied.

This confused me too, my scripts rely on finding the name of the current branch which was not possible. It did work however using $GIT_BRANCH as mentioned above, but I did not find that out before finding this issue. Couldn't that be documented for the "Check out to specific local branch" field ?

zitrax you could also use the "Local Branch" extension that was added to git plugin 2.4.4. Refer to the online help for the local branch extension.

In the Local Branch extension, you set the branch name to "**" or the empty string, and that then causes the plugin to checkout to a branch name derived from the branch that was the origin of the checkout. That allows a branch specifier to select multiple branches, then the branch which is checked out is based on the specific branch selected for that run of the job.

I'm writing a pipeline which clones a git repository and supposed to checkout to a specific branch, then merge master to that branch and run a MSBuild.

In reality, git checks out to the sha of the last commit in the branch instead of the branch name itself which is a detached head and the ${GIT_BRANCH} variable is evaluated to 'null'.

// Started by user itai ganot
[Pipeline] node
Running on master in C:\Program Files (x86)\Jenkins\workspace\bbb
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Setup)
[Pipeline] deleteDir
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Checkout SCM & Merge master to feature branch)
[Pipeline] checkout
Cloning the remote Git repository
Cloning repository http://pctfs1:8080/tfs/DefaultCollection/PC_International/_git/Ensure-pcs-intl
 > git.exe init C:\Program Files (x86)\Jenkins\workspace\bbb # timeout=10
Fetching upstream changes from http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/Ensure-pcs-intl
 > git.exe --version # timeout=10
using GIT_SSH to set credentials javab SSH file
 > git.exe fetch --tags --progress http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME +refs/heads/*:refs/remotes/origin/*
 > git.exe config remote.origin.url http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME # timeout=10
 > git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git.exe config remote.origin.url http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME # timeout=10
Fetching upstream changes from http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME
using GIT_SSH to set credentials javab SSH file
 > git.exe fetch --tags --progress http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME +refs/heads/*:refs/remotes/origin/*
Seen branch in repository origin/feature/merge_tfs
Seen branch in repository origin/master
Seen branch in repository origin/origin
Seen 3 remote branches
 > git.exe tag -l # timeout=10
Checking out Revision 97b3493db4f726e11e334e5ba34fa808b63edec5 (origin/feature/merge_tfs)
 > git.exe config core.sparsecheckout # timeout=10
 > git.exe checkout -f 97b3493db4f726e11e334e5ba34fa808b63edec5
First time build. Skipping changelog.
[Pipeline] bat
[bbb] Running batch script

C:\Program Files (x86)\Jenkins\workspace\bbb>cd C:\Program Files (x86)\Jenkins\workspace\bbb 

C:\Program Files (x86)\Jenkins\workspace\bbb>git branch 
* (HEAD detached at 97b3493)

C:\Program Files (x86)\Jenkins\workspace\bbb>echo "git branch: null" 
"git branch: null"

C:\Program Files (x86)\Jenkins\workspace\bbb>echo "git branch: null" 
"git branch: null"
[Pipeline] }
[Pipeline] // stage

How can I make sure that I checkout to the relevant branch_name?

itaiganot please refer to the comment prior to your question.

The "pipeline syntax" link on the left of most pipeline job pages will open a page where you can prototype the code you need to perform a checkout to a specific branch. Use the "checkout" selection from that list (not the "git" selection), then select "Git" and add the "Additional Behaviours" for "Check out to specific local branch". You can then set a specific branch name, or you can use "**" to indicate that it should use the branch name from the repository where the clone was performed.

Thanks, it did solve my first issue.

But now I have another issue which is also related, I'd like to set:

// currentBuild.displayName = "#${BUILD_NUMBER}|${BRANCH_NAME}" 

And it cannot be done in pipeline because of the same reason... what can be done to achieve that?

itaiganot please don't use closed bug reports as a forum for questions. You're asking for time from the very few people who read git plugin bug reports, when there are much larger groups (like the Jenkins users mailing list) that can address your questions.

Isn't it enough to do the following to get a proper branch head at some point after the checkout?  It seems to work for me. 

git checkout -b ${GIT_BRANCH} origin/${GIT_BRANCH}

Yes, the git checkout command you used is a very good choice, especially if you're not using authenticated submodules or authenticated access to large file storage (git LFS).