The Cookbook: Branch Flow

It's important when using multiple branches in your repository to define which branches to build to, and which branches not to build to. Let's get started.

Branch Flow

Travis CI uses the .travis.yml file from your project structure, once you've configured your flow via the .travis.yml file, you can trigger a build by pushing changes through the CLI using:

git init
git add . 
git commit -m "Travis build branch" 
git remote add origin remote repository URL
git remote -v 
git push -u origin master

You can tell Travis to build multiple branches using blacklists or whitelists. More specifically you can define which branches to build using a whitelist, or on the flip side you can use blacklist. You can blacklist branches that you do not want to be built via the following:

# blacklist (branches you don't want to be built) 
branches:
  except:
    - legacy
    - edge

# whitelist
branches:
  only:
    - master
    - stable

If you specify both whitelist and blacklist, only takes precedence over except. By default, let's say you have a gh-pages branch, that branch is not built unless you add it to the whitelist explicitly. When deploying to your version control, or if you're using Apache SVN (Subversion), in some cases, it may reset your working directory, it does this via:

git stash --all

As a cursory cautionary move, you can add skip_cleanup to your .travis.yml file. So after, your yml file might look like this:

deploy:
  skip_cleanup: true

If there's anything you want to add before you deploy, you can obviously add before_deploy. This is also true for an inverse method, for after deployment via after_deploy.