Set Up Jenkins Multibranch Pipelines for Feature Branches (2026)

Jenkins’ multibranch pipelines are designed to automatically discover and build branches in your SCM that contain Jenkinsfile, letting you manage pipelines alongside your code.

Let’s say you have a Git repository with a main branch and several feature branches like feature/new-login, feature/user-profile, and fix/bug-123. You want Jenkins to automatically create a pipeline job for each of these branches as soon as a Jenkinsfile appears in them.

Here’s how a multibranch pipeline works in practice. Imagine you’re developing a new feature. You create a branch feature/awesome-sauce from main, add your code, and include a Jenkinsfile at the root of that branch.

// Jenkinsfile for feature/awesome-sauce branch
pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building awesome-sauce...'
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing awesome-sauce...'
                sh 'mvn test'
            }
        }
        stage('Deploy to Staging') {
            when {
                branch 'feature/awesome-sauce'
            }
            steps {
                echo 'Deploying awesome-sauce to staging...'
                // Add your staging deployment script here
            }
        }
    }
}

When Jenkins’ multibranch pipeline scans your repository, it will detect this Jenkinsfile on feature/awesome-sauce. It then automatically creates a new job named your-repo-name/feature/awesome-sauce and executes the pipeline defined in the Jenkinsfile.

The core problem this solves is the manual creation and management of individual Jenkins jobs for every single branch or pull request. With multibranch pipelines, Jenkins becomes a dynamic system that adapts to your branching strategy.

Here’s a typical setup in Jenkins:

1. Create a new item: In Jenkins, click "New Item".
2. Choose "Multibranch Pipeline": Give your pipeline a name (e.g., MyProject-Multibranch).
3. Configure Source: Under "Branch Sources", click "Add source" and select "Git".
4. Enter Repository URL: Provide the URL of your Git repository (e.g., ssh://git@github.com/your-org/your-repo.git).
5. Credentials: Add or select your Git credentials.
6. Behaviors: This is where the magic happens.
   • Discover branches: This is enabled by default. It tells Jenkins to look for branches.
   • Discover pull requests: You can configure this to build pull requests too.
   • Filter by name: You can use regular expressions to include or exclude branches. For example, to only build branches starting with feature/ or fix/, you could use ^(feature|fix)/.*. To exclude release/ branches, you might use ^(?!release/).*.
   • Mode: Choose "Multi-branch" for branches and "PR" for pull requests.
7. Scan Multibranch Pipeline Triggers: Configure how often Jenkins should scan your repository for new branches or changes. A common setting is "Periodically if not otherwise run" with a value like 1 minute.

Once configured, Jenkins will perform an initial scan. It looks into your repository, finds branches containing a Jenkinsfile, and creates corresponding pipeline jobs. When you push a new branch with a Jenkinsfile, Jenkins will detect it on its next scan and automatically create a job for it. Similarly, if you remove a Jenkinsfile from a branch, the corresponding Jenkins job will be deleted on the next scan.

The mental model to have is that a multibranch pipeline job in Jenkins is a manager or orchestrator. It doesn’t contain the build steps itself. Instead, it continuously monitors your SCM for branches that declare their own pipeline logic via a Jenkinsfile. For each such branch, the manager job then instantiates a specific, independent pipeline job that runs the logic from that branch’s Jenkinsfile. This means your pipeline definition lives with your code, in the Jenkinsfile on each branch.

The "Scan" process, configured under "Scan Multibranch Pipeline Triggers", is the heartbeat. Jenkins doesn’t magically know about new branches. It has to actively check your repository. The frequency you set here dictates how quickly new branches or changes to existing ones (like adding a Jenkinsfile) are picked up. A very short interval, like 1 minute, means near real-time detection but can increase load on Jenkins and your SCM. A longer interval, like 15 minutes, is less resource-intensive but introduces latency.

The exact mechanism for discovering Jenkinsfiles is configurable. By default, it looks for Jenkinsfile at the root of the repository. However, under "Advanced" settings for the branch source, you can specify different Jenkinsfile paths or even multiple paths. This is powerful if you have complex monorepos where pipelines might be defined in subdirectories.

When you push a new branch with a Jenkinsfile, Jenkins will create a new pipeline job for that branch. If you then delete the Jenkinsfile from that branch and push, the next scan will remove the corresponding Jenkins job. This dynamic lifecycle management is the core value proposition of multibranch pipelines, keeping your Jenkins configuration lean and aligned with your development workflow.

The next concept you’ll likely encounter is how to manage secrets and credentials securely within these dynamically created pipelines, especially when deploying to different environments.