Other people have done a great job of explaining what Jenkins is, so I'll skip that part
Instead, I'll explain how we use Github and Travis, and what our development process is like.
We have ~15 robot programmers, and one programming mentor. Of the programmers, 5 are experienced, and the rest just joined the team this year. We usually are developing somewhere between 5-10 features at any given time.
We use GitHub to store our code. Every programmer has a fork of our robot code repo. When someone starts to add a feature, they checkout the latest code from our main repo, and create a branch on their fork (In actuality, branches don't "belong" to a specific fork, but that's a kind of technicality). They add whatever files are needed to add the feature, and commit them to their branch. With so many people working on things at the same time, splitting up files is very important! We have 265 files in our repo, not including libraries!
Another thing that we do is write tests for our code (This is one of the main uses of Travis/Jenkins). Our tests check that the code does the correct thing. For example, we'll write a test that simulates a mechanism on our robot, and runs our code with that simulation as an input. It'll then check that the output is what we expect. This can be confusing at first, so ask if you have any questions about this!
Once the person is done with their code and tests, they'll submit a pull request to our main code repo. A pull request is basically a request to merge code into our main repo. We then have other people review the code, ask questions about it, and submit feedback on it. Once all of the comments have been addressed, and enough people have reviewed it, we merge it into our main repo.
That's basically what we use git/github for. We use Travis (basically the equivalent to Jenkins) to run our tests and make sure that the code compiles. The main use of this is for pull requests - we have github set up to not allow merging until the tests all pass on Travis. This lets us make sure that the code in our main repo will always build properly and pass all the tests.
That's a summary of how we work. It's not necessarily a good idea to try to implement this all at once, but hopefully it gives you an idea of what this looks like at a slightly larger scale.
If you want to get started doing something like this, I'd suggest two things to start out with:
1.) Make your git commits as small as possible. This makes it easier to collaborate with other people, and is nicer to use. Additionally, learn git really well. I'd recommend using the command line interface for git. It will help you gain an understanding of what git is actually doing, and once you learn it, it's much nicer than any GUI that I've seen. Start using branches, if you don't already.
2.) Start writing automated tests. The one thing that makes this hard is that WPILib can't be compiled to run on most computers, so you need to separate all of the calls to WPILib from anything that you want to test. This means that you need to think more about how you structure your code, but it's worth it!
If you have any questions about how we work, or about how you could go about implementing some of this on your team, feel free to ask