To reproduce, use this simple pipeline definition:

node {
    stage('checkout') {
        ws() {
            git 'https://github.com/jenkinsci/pipeline-examples.git'
        }
        ws() {
            git branch: 'pipeline', url: 'https://github.com/jenkinsci/pipeline-examples.git'
        }
    }
    
    stage('check branch') {
        sh "git branch -a"
    }
}

Probably another symptom of the well-known failure of the git plugin to correctly implement SCM APIs (see BuildData). No one has figured out how to refactor it without causing regressions for thousands of users.

Thought I'd share a quick workaround for this limitation so others might save a bit of time. Basically you can always fall back to orchestrating the git clone/checkout yourself and avoid the broken machinery which ignores `poll: false` w/ checkout/git-plugin calls. 

// WORKAROUND: Polling always finds changes when you checkout 2 branches of the same repo in the pipeline
// https://issues.jenkins-ci.org/browse/JENKINS-39621
// https://issues.jenkins-ci.org/browse/JENKINS-44762
//
sh "git init"
sh "git remote add -t ${GIT_OTHER_BRANCH} -f origin ${GIT_URL}"
sh "git checkout ${GIT_OTHER_BRANCH}"
//
// checkout(changelog: false, poll: false, scm: [$class: "GitSCM",
//     branches: [[name: GIT_OTHER_BRANCH]],
//     extensions: [
//         [$class: "LocalBranch", localBranch: GIT_OTHER_BRANCH],
//     ],
//     userRemoteConfigs: [[url: GIT_URL]],
// ])

writeFile(file: ".gitignore", text:
    "# output from nohup\n" +
    "nohup.out"
)

sh "git config user.email \"jenkins@example.com\""
sh "git config user.name \"Jenkins CI User\""

I think this has to do with multiple git clones in pipeline don't store the build data properly, resulting in inability to correctly identify that a previous build has already built on that second git clone.

Facing the same issue, do any one get any solution or work around for it.

Thanks in advance

Nandlal

I had this problem in a Pipeline that ran

git credentialsId: 'github', poll: false, url: 'https://github.com/org/repo', branch: branch

on different nodes with different branches. Polling kept causing new builds in an infinite build loop.

Adding changelog: false made the problem go away. For this project I don't care about the changelog, so that was no problem for me.

I suspect this is due to GitSCM.getKey ignoring branches. Thus, WorkflowJob.pollingBaselines has a single entry for both checkouts, corresponding to the repo location, despite the branches being distinct.