Instructors lecture and lead practical exercises. You should also help learners during practical sessions, but remember to rest your voice as well. You don't need to know the curriculum for all the topics in your bootcamp, but it certainly helps (particularly if someone can't make it at the last minute).
Instructing at a bootcamp isn't trivial. The most important thing is to remember that no lesson plan survives contact with the audience. Whether it's the network going down or the sudden realization that many of your learners don't know how to use SSH, you will frequently need to improvise.
Even without hiccups like those, try your best to adjust your pace and examples based on learners' questions, puzzled looks, and sighs of impatience.
In almost all cases, learners want to use their own laptops during bootcamps so that they leave with a working environment set up. Even if you ask attendees to prepare beforehand, and give them detailed instructions, some will not have time, or will have run into problems that they're not yet able to fix. You should therefore schedule at least 20 minutes for checking the learners' machines at the beginning of the first day. Some bootcamps start early on the first day to allow time to troubleshoot setup problems.
You're not there to reproduce one of our online videos in person: you're there to interact with people so that they get a better learning experience. You shouldn't ever go more than two or three minutes without asking a question (and listening to the answer), and if it has been 15 minutes since any of your learners asked one, odds are you've either lost them or are boring them.
Your audience will never care more about what you're teaching than you appear to, so if they get the feeling you're not interested in it, they won't be either. This does not mean you have to shout, crack three jokes a minute, or harangue them about how this stuff is really, really important, but you do owe it to your audience to show up mentally as well as physically.
The more time folks spend with their hands on the keyboards doing exercises, the more time they're actually paying attention. The students have their computers in front of them: if you talk for more than five minutes without asking them to use their computers, they'll do so anyway—on Facebook.
Typing too fast, using shortcuts or commands learners haven't seen yet—basically, any time you say, "Don't worry about this just now," or they say, "Wait, how did you do that?" or, "Can you please slow down, I can't keep up," you're no longer actually helping them.
The feedback you get from learners on sticky notes or through surveys is pointless if you don't pay attention to it (or worse, if you explain it away). There's no point collecting feedback during and after each bootcamp if you don't change what and how you teach to reflect it.
Most of our learners are graduate students in science and engineering, so they know what evidence looks like, and why working practices should be evidence-based. That doesn't mean you have to have the whole of empirical software engineering at your fingertips, but please do read Facts and Fallacies of Software Engineering and sprinkle a few of the findings it quotes into your lessons.
The things we teach reinforce each other, so tie them together at every opportunity. Point out that connecting things with pipes in the shell is like chaining functions together, or that they can use a shell script to re-run a bunch of different tests before committing to version control, and so on. If possible, take 15 minutes or so each day to show them how you use these tools in your day-to-day work.