Relatively fast, definitely opinionated tutorial.

As you probably know, in Travis CI, CI stands for Continuous Integration.
And Travis stands for Travis, the shitty music band (I obviously don't have a clue).

Continuous Integration is the umbrella for various techniques and practices that every self-respecting software project should employ.
The main goal is to eliminate the long and tedious integration process, the work that you normally have to do between version's final development stage and its deployment in production. So you routinely perform (or rather, CI performs for you) the same sequence of steps, thus making the whole process polished and reliable.

In a few lines, CI is:

• Build automation - every commit/push to an scm repo automatically triggers a new build (anything in the master branch is deployable)
• Test automation - tests are evaluated as integral part of the build process (that's old news, right?)
• SCM integration - primarily to facilitate build automation, but also to be able to report on issues, versions, milestones, ...
• Project management integration - Basecamp, Campfire, Acunote and other PM tools (people, tasks, schedules, ...)
• Project Dashboard - everything is out in the open (generally without any read access restrictions, making it available to all interested parties)

A little angry note about CI adoption

From my standpoint, CI's most important feature is reporting. The fact that you can see whether builds are passing, test are failing, who did what, when and how (web-based scm) make CI an invaluable tool in every project's toolchain.
Although CIs are often (rightfully) attributed to open source projects, there's no reason why you shouldn't be able to use it, with equal success, in a closed, corporate environment.
Besides all the political bullshit, that is.
The one thing I learned in my early days is that, in traditional corporate environments, you can often encounter software project managers that earned their positions with years of manipulation, usurpation and other admirable practices. So, understandably, introduction of a CI is not in their best interest. They don't want transparency. Their whole job sometimes boils down to owning all the information and then strategically feeding specific (slightly adjusted) parts to different channels.
The whole chicken and egg problem is that they are the ones that decide on whether to use CI or not. So, if you ever hear stuff like "That would only slow us down", "This project is too small", "We are doing just fine without it" or "We don't have necessary experience", remember this and just smile (if you're cool-headed enough. I'm unfortunately not :)

Integrate your GitHub project with Travis-ci

OK, now that all the frustration is out, let's do some actual CI-SCM integration.

• First go to https://travis-ci.org/ and sign in with your GitHub account.
• In the upper right corner click on your name (or choose Accounts) to open your Travis-ci profile.
  You'll be presented with the list of your GitHub projects (only the ones where you have administrative authority)
  

• Toggle the switch on one of your projects and then click on little wrench icon to open the project's Service Hooks page on GitHub. To get to the same place from your GitHub project, go to Settings > Service Hooks.

• On the Service Hooks page scroll down to Travis and you'll notice that the hook is already activated. Click on "Travis".

• Click on Test Hook.
  You'll soon (depending on the availability of a Travis worker and the size of your project) get an e-mail telling you that your project build has failed (unless you're on Ruby and you're lucky as hell). I don't know what kind of projects you run there, but this is not OK, my friend.
  
• Now, completely ignoring my previous comment, open the root of your GitHub project and create a new file named .travis.yml.
  That's the file that will contain your Travis configuration for the repo. YML extension stands for YAML (YAML Ain't Markup Language), which is basically a specification for data exchange format, similar to JSON.
  
• According to the programming language of your project, fill in the Travis settings in your newly created .travis.yml file. Use Travis getting started documentation to find default settings for your language.

I always get it the first time :)