Don't understand tracking branch

pete's Avatar


14 Feb, 2013 09:33 AM

I know that Appharbour builds all commits to my remote master and this enables Appharbour to be used as a continuous integration server. I understand that and that's great.

However I have my Appharbour site settings configured to use 'deploy/staging' as a tracking branch and I'm expecting any updates to that branch to be built and deployed but this doesn't happen.

Am I misunderstanding something? My work flow is this:

git checkout master
--- do some work
git commit
git push origin master -- Appharbour picks this up and builds and doesn't deploy (this is as expected)
git checkout deploy/staging
git merge master
git push origin deploy/staging -- Nothing happens

If it makes a deference I'm using bitbucket.


  1. Support Staff 1 Posted by rune on 14 Feb, 2013 09:40 AM

    rune's Avatar


    The branch name is actually just "staging" (deploy is the name of your git remote), so if you rename the tracking branch to that it should work as you'd expect.


  2. rune closed this discussion on 14 Feb, 2013 09:40 AM.

  3. pete re-opened this discussion on 15 Feb, 2013 01:17 PM

  4. 2 Posted by pete on 15 Feb, 2013 01:17 PM

    pete's Avatar


    Pretty sure my branch is called 'deploy/staging' tbh. I put the 'deploy/' in to distinguish it from feature branches. My remote is origin.

    Think I've figured out the reason why this doesn't work for me. I first push up master, then merge master to staging. So When I push to my staging branch Appharbour has already has a build based on that commit so doesn't build it again. Which makes sense I suppose.

    I tested this by pushing up my staging branch before my master: It build then deployed correctly.

    So my problem is my workflow I guess. I'm open to suggestions. At the moment I'm expecting Appharbour to deploy whatever is on my tracking branch regardless of weather there's an existing build for that commit or not. But Appharbour doesn't work that way.

  5. Support Staff 3 Posted by rune on 16 Feb, 2013 11:59 PM

    rune's Avatar

    Hi Pete,

    If the build doesn't show up on your dashboard on AppHarbor it's not because we don't build the same commit - we build based on all the notifications we get and the branch is irrelevant to that.

    It's likely however that Bitbucket doesn't notify us in case a branch is updated with the same commit as the latest commit on master. You could ask the Bitbucket guys if this is the case.

    If you have never seen a commit on AppHarbor from the deploy/staging branch you might want to try and rename the branch to something that doesn't contain "/" (for instance deploy-staging) as that could also be a cause of the issue.


  6. rune closed this discussion on 16 Feb, 2013 11:59 PM.

  7. pete re-opened this discussion on 01 Mar, 2013 04:01 PM

  8. 4 Posted by pete on 01 Mar, 2013 04:01 PM

    pete's Avatar

    In case this helps other people:

    I talked to Bitbucket. Seems like they don't send a notification if there's no commit data in the push.

    Because my merge can be accomplished via a simple fast forward then no commit data is created.

    However I can force a commit message by specifying --no-ff.

    So something like this would work:

    git commit
    git push origin master
    git checkout deploy/staging
    git merge master --no-ff
    git push origin deploy/staging


  9. Support Staff 5 Posted by rune on 01 Mar, 2013 09:15 PM

    rune's Avatar

    Thanks a lot for getting back to us with this information. I'm sure it'll be helpful to others as well.

    Actually I can recommend always using the --no-ff option when merging a branch into your "main" deployment branch. This way you'll retain a history of when the branch was merged into master as opposed to fast forwarding, and if your branch names are well-named it'll also make it easier to quickly identify what code is currently running when observing the list of builds on AppHarbor.

    Additionally if you need to roll back your repository history you can do so after after merging with the --no-ff option with a simple git reset --hard HEAD^1. Alternatively you can use the revert on the merge commit if you don't want to overwrite the history.


  10. rune closed this discussion on 01 Mar, 2013 09:15 PM.

Discussions are closed to public comments.
If you need help with AppHarbor please start a new discussion.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac