The procedure in my team is that we all commit our code to the same development branch. We have a test server that runs updated code from this branch so that we can test our code on the servers. This test server is exposed on the internet so that we can test callbacks from third-party services like sendgrid. (where you specify a url for sendgrid to update you on the status of emails sent out)

The problem is that if we want to merge the development branch to the master branch in order to publish new features to our production servers, some features that may not have been ready will be applied to the production servers.

So we're considering having each developer work on a feature/topic branch where each of them work on their own features and when it's ready, merge it into the development branch for testing, and then into the master branch.

However, because our test server only pulls changes from the development branch, the developers are unable to test their features. While this is not a huge issue as they can test it on their local machine, the only problem I foresee is if we want to test callbacks from third-party services using our test server during the course of developing a feature.

How can we handle this problem?

Note: We're not advanced git users. We use the Github app for MacOSX and Windows to commit our work.

Setup: It is a PHP project. We do not have any form of CI setup and do not have the knowledge to do so. Eventually we want to use Jenkins but right now we're just focusing on getting our minimum viable product out.

2 Answers 2


One solution is to let the test server also build the branches when commits are made. Jenkins for example can be told to monitor some or all branches in a repo, and whenever it detects a commit to a branch, it will build that branch. See e.g. Git, Feature Branches, and Jenkins – or how I learned to stop worrying about broken builds

You could have some naming convention for "scratch" branches that are not supposed to be tested, and only let Jenkins build the "real" feature branches.

Another common solution is to have some kind of integration branch between your feature branches and master (or have branches "master" and "release"). Then everyone merges to master once a feature is ready, everything is tested on master, but merges to "release" only happen once a feature is sufficiently tested to be deployed. See e.g. A successful Git branching model for one popular approach.

  • For your second solution, do you mean that for every feature branch, it can be constantly merged into master for testing, and once it is deemed ready, the feature branch will then be merged into release?
    – wyred
    Dec 3, 2012 at 5:15
  • 1
    @wyred: Well, there are many possible workflows. I'd usually test the features on the feature branch (while regularly mergin in new features from master, to make reintegration easier). Once the feature is done, it is merged to master. There, final testing happens, and then master (including all the new features) is merged to "release".
    – sleske
    Dec 3, 2012 at 10:53

You could do something like what git project does with the "pu" branch.

In git (the project) development is done on topic branches. While in development, these branches are often rebased on latest master or, if they depend on other recent development, next. And each time they are rebased, they are all merged together to a branch called pu. The branch is always deleted and created by again merging all the topics. Than when the feature is tested, it is merged to "next", which is never rebound and that is finally integrated to "master". So you can have one test server showing this "pu" (development) and possibly another showing the "next" (preproduction).

  • Sorry, I did not clarify that we're not advance git users. We only use the Github app for MacOSX and windows to do our work. Can your proposed method be done with the app alone?
    – wyred
    Nov 30, 2012 at 9:10
  • @wyred: I don't know that app, but it certainly can't be set up using just it, because it requires a bit of scripting, but than it can be used with it, because you just push and the scripts take care of the rest.
    – Jan Hudec
    Nov 30, 2012 at 9:16
  • @wyred: The two answers are really complementary. The link in the other answer describes how to do that merging using Jenkins.
    – Jan Hudec
    Nov 30, 2012 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.