Don't Phunk with My Stable Branch: Jenkins Pre-tested Commits to Stop Breaking Stable Branches


Jenkins is used to reduce downtime for development teams by building and testing code often (often on each commit). However for large projects where the build cycle time is large, this delay may already be too late. 

For example, a developer may check in broken code, Jenkins will build and, after a while, go red. Developers in the interim may have checked out the broken source code and are now impacted by the downtime. Time to sing along, “No, no, no - don’t break my stable branch,” cued to the Black Eyed Peas song, “Don’t Phunk with My Heart.” ;-)

The pre-tested commits feature alleviates this issue by making use of Git’s lightweight branches. Note: this only works with Git. What this means is that developers and managers are no longer unpleasantly surprised by broken builds. :-)

To accomplish this, you need multiple Git branches. The sample scenario here is as follows:

  • A developer works on particular local branch for his feature named PhunkyFeature.
  • An administrator has setup a remote branch called integration. All developers are supposed to check code into this branch. Nobody commits to the master. 
  • Once code is committed into the integration branch, Jenkins kicks in and builds. The code is merged into the  master only if the build is successful. Other developers check out the code from the master and use it. Thus, if bad code makes it in, only the integration branch is affected and the master keeps humming along. 

Setting up Git Repositories

A. Administrator sets up integration branch on the remote repository:

>git clone ssh://
>cd tutorial; 
>git branch integration # create a local integration branch
>git push origin integration # push the branch to remote
>git branch -r # lists all the branches; should show something like
  origin/HEAD -> origin/master




B. Developer sets up a PhunkyFeature branch in the local repository:
>git clone ssh://
>git branch PhunkyFeature

Configuring Jenkins

  1. Go to your Jenkins job configuration under the Source Code Management Git section of the page.
  2. Click Advanced and select Merge before build. Enter origin for the Name of the repository and enter master for Branch to merge to
  3. Under the  Post Build section, enable the Git Publisher checkbox and enable Push Only If Build Succeeds and Merge Results. Under Branches, enter master for Branch to push and origin for Target Remote Name
Source Code Management Git section

Development Flow

The developer hacks away at his code in the local branch. 
> git checkout PhunkyFeature
> #hack away
> git add files; git commit -m “hacked away and unknowingly introduced a bug, was too lazy to test it”
Developer merges the local branch into the integration repository. 
>git checkout integration origin/integration # switch to integration branch
>git merge PhunkyFeature # merge changes
>git push origin integration # commit the integration branch

Jenkins Flow

As soon as the developer checks in the code (depending on your poll/push settings), Jenkins detects that the integration branch has a change. It checks out the integration branch and merges it into the master branch. It then builds the code and, if the build is successful, pushes the master to the origin. 

Changes are reflected to the master only on success, thus minimizing the impact of bad checkins for the wider development team. 

Relevant Documentation

Harpreet Singh
Senior Director, Product Management
Blog Categories: 


For our multi-platform projects, we'd need to check that the commit is correct on several jobs, not just one. Do you have a suggestion for that?

nice tutorial, but I question is how do you detect branch conflicts? Say branch A, B are pushed to github at the same time and individually they all can trigger successful jenkins build, so after the first build, what happens to the second one ? Is there a way to detect branch potential conflict right after it pushes to github ?

Add new comment