Collaboration using github and testing the code

Question

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.

Answer 1

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.

Answer 2

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).