You can rebuild and reorganize columnstore indexes the same as rowstore. The reasons you do this are different though. It's not about fragmentation, because of how columnstore indexes are defined, fragmentation just isn't the same kind of problem. Instead, it's about the delta store and compression. Inside a columnstore index, changes do not go directly to the index. Instead, they first go to what is called the delta store or delete bitmap. These are actually traditional rowstore b-tree indexes inside the columnstore. A delete from a columnstore is a logical delete, marked in the bitmap. An insert is just added to the delta. An update is a delete and an insert in the delta store. Over time, after about a million rows, you'll see a delta converted to a row group in the column store. However, in the mean time, lots and lots of extra reads are needed to deal with the deletes & data changes, slowing down the columnstore. So, a rebuild will perform actual deletes against the columnstore proper, clearing out the bitmap, and insert the rest of the data into properly pivoted and compressed columnstore storage. Reorganize will do most of the same work. You can read this article from Microsoft on the topic (yeah, there's still some controversy over this article, but I think the columnstore info in there is pretty good).
Probably, in most situations, for columnstore, and columnstore only, you're probably best served by using reorganize rather than rebuild. However, with all things, testing is your best buddy. Follow the links in the article to examples of how to reorganize a columnstore index.