Bitset allows you to manipulate individual bits in a word.
Let's say that you have 32 options which could be set to true or false in your program. You could either store them in 32 bools, consuming 32 bytes, or store them in a bitset which could consume 4 bytes instead. Your space consumed is reduced by 88%.
Another place this can be used is if we are packing opcodes for specific usage or for network transmission.
Note that I don't really like this class. The fact that it can be resizeable means that it implements dynamic memory allocation which is actually rather slow. When I have to work in real-time at a very low-level and pack individual bits, I can't afford to use the new keyword in any objects which could be used hundreds of times in an iteration. I've made my own classes which ease bit-setting with 32-bit words and these have actually brought down some of my module's execution time from 1ms to 10us (100x faster).
The numbers on the right-hand side define how many bits are used for each field. When I write to data, the numbers are automatically shifted for me. I'm not sure about masking though. You may need to protect against overflow (I'm not sure what MyWord w; w.source = 0x4; would do).
bit fields have been around since C89, it's unlikely that a today's compiler would have a bug dealing with unsigned overflow on a bit field (signed overflow, is, as always, UB). And if it does, a bug report would help others.
I'm talking about setting a 2-bit bit-field to 0x4. Your compiler gave a warning and truncated the 0x4 to fit 2 bits. I would not rely on that truncation as I just went through the C++03 standard and this behaviour appears to be undefined. The fact that you got a warning confirms that it's something we should look at before releasing.
I wouldn't call truncation versus overflow a "bug" as it's undefined.
I'm not going to get into unions because that's getting too off topic.