There is a newer version of this guide on our Knowledge Base.

GitHubDear Kanbanizers,

We are proud to announce that our GitHub integration is out of beta. Below are some details about the integration itself.


1. Track commits as comments in a corresponding Kanban card. (only commit and push events are tracked)
2. Track GitHub project issues as cards in a Kanbanize board

The integration is in one direction only – from GitHub to Kanbanize
For example, when an issue is closed, the corresponding Kanbanize card is moved to Done but moving a card to Done will not get the issue closed.


1. In Kanbanize, go to administration-> integrations and enable GitHub integration

2. Go to your GitHub project page -> Settings


3. Click on Integrations & services


4. Add the Kanbanize service


5. Set the domain name and the API key of any of your Kanbanize users.
We recommend using a dedicated Administrator user or a standard user (e.g. GitHub_user) with permissions to access, comment and modify cards on the desired boards.


And you are good to go! From now on, every commit message will be processed with the Kanbanize service and your changes will be reflected on the corresponding Kanban card. When a local branch is pushed to a repository all local commits will also be processed one by one.

By default, all branches and all commits of the project are inspected for Kanbanize card IDs.
You could restrict this behavior by setting:
Restrict to branch – A Comma-separated list of branches which will be automatically inspected. Leave blank to include all branches.
Restrict to last commit – If enabled, only the last commit of each push will be inspected for task IDs.
Track Project Issues In Kanbanize – If enabled, GitHub project issues will be tracked in a Kanbanize board.
Project Issues Board – The ID of the board that must keep the project issue cards.


Kanbanize supports the following commands in the GitHub commit message:

#taskid / #id – this is a required parameter for the integration to work. You can provide it in one of these three formats:

  • #id 1234 (can be anywhere in the commit message and takes priority if present
  • #taskid 1234 (can be anywhere in the commit message and takes priority if present)
  • 1234 (must always be the first thing in your commit message)

Example 1:
Change in the logging module. #id 1234

Example 2:
Change in the logging module. #taskid 1234

Example 3:
1234 Change in the logging module.

GitHub allows Closing issues via commit messages.

If issue tracking is enabled and your commit message is related to a GitHub issue, you don’t have to provide a task id parameter.

#title, #description, #priority, #assignee (with alias @<username>), #color, #size, #tags, #deadline, #extlink, #type

All these parameters can be changed via the commit message and the format of the values is described here.

Example 1:
Change in the logging module. #taskid 1234 #priority high #color ffaaff #deadline 2014-12-12 @Peter

Example 2:
1234 Change in the logging module. @Peter

You can also move a task via the commit message. The supported parameters are: 

#column – The name of the column you want to move the task into.
#lane – The name of the lane you want to move the task into.
#boardid – If you want to move a task to another board, specify the board id.
#position – The position at which you want to move the task to.
#exceedingreason – If you are to exceed the WIP limit, provide a reason with this parameter.

Example 1:
1234 #column Done

Example 2:
1234 #column Done #lane bugs #boardid 12 #position 1

Example 3: If the column is a sub-column you must specify it as “columnname1.columnname2.columnname3”:
1234 #column “Done.Ready for Deployment” #lane bugs #boardid 12 #position 1

We also support a bunch of move shortcuts that make your lives easier :)

#move “Ready for testing/Platform Team” – Move the task to the “Ready for testing” column and the “Platform Team” swimlane
#move Development/ – Move the task to the Development column
#move “/Platform Team” – Move the task to the Platform Team swimlane

#requested – Move a task to the first column in the Requested section
#inprogress – Move a task to the first column in the In Progress section
#done – Move a task to the first column in the Done section

#<section> first – Move a task to the first column in the section
#<section> 2 – Move a task to the second column in the section
#<section> last – Move a task to the last column in the section
<section> can be any of the following: requested, progress, done

To log time via the commit message use the following parameter: 

#loggedtime – The number of hours you want to log to the task.

Example 1:

1234 #loggedtime 2

You could also block or unblock a task via the commit message. The supported commands are:

#block – the reason with which you block the task
#editblock – specify this parameter if the task is currently blocked and you want to change the block reason
#unblock – unblock the task

Example 1:
1234 #block “Not enough resources.”

Example 2:
1234 #unblock

Happy coding with Kanbanize – Kanban Software that Scales your Business.

Join our Lean Community!

We publish a new article every week. Get the latest content straight into your inbox!

8 thoughts on “GitHub to Kanbanize Integration

  1. Pingback: Version 4.2 – What’s New? | Kanbanize Blog

  2. Carlos

    I was trying to integrate a board in a git repository and I haven’t could do it.
    In the repository setting “kanbanize domain” I wrote “” and in “API key” the key which appears in my Kanbanize count.
    Then, when I am doing commits with theses layers in the comentaries, the kanbanize board doesn’t change.
    I proved to change the “kanbanize domain” in Git to “” but the problem persists.
    What would I do to solve it?

  3. Tomasz

    @Dimitar Are you going to give a possibility to customise processing behaviour? It would be great if we can define commit message patterns and actions for them.

    For example: “Close #{{:ticketNo}}” => Move ticket {{:ticketNo}} to column “QA verification” matches “This great commit will close #123 and CLOSE #321” and moves tickets #123 and #321 to the given column.

    1. Monica Georgieff

      Hi Tomasz,
      I’m not sure if I understand you correctly but I can suggest using runtime policies (in Kanbanize, not Github) to automate some of the things you described in your scenario (for example, “Close #{{:ticketNo}}” => Move ticket {{:ticketNo}} to column “QA verification”) but you will need to, at some point, define the ticketNo or Taskid manually. If, by great commit, you mean activating many things at once we actually encourage committing one thing at a time. I hope I’ve answered at least part of your query! If not – please contact My fellow Kanbanizers will be happy to take a look if I’ve missed something.

      1. Tomasz

        @Monica after a while I have realised your solution is really good for most of the people, it gives a clear pattern and should be considered as an API via commit message 🙂

        In our case we wanted to customise it for our commit message policy, so we have found it easier to create our own Github web hooks and use your standard API to perform certain actions.

    1. Alex Novkov

      Hi Sherif,

      The integration was updated about a year ago. We haven’t planned any enhancements in the near future, but we are always open to hearing new ideas. Do you have anything in mind?



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.