If I need to version control my thesis, which contains my latex report and code, should I create a Group with two separate projects (code and latex) or should I create one repository called thesis with two directories in the root (code and latex)?
For most cases, it doesn't really matter and you should do whichever one makes most sense to you. There are, however, some exceptions.
One significant reason I know of to split the two is if one will contain a lot more data than the other (e.g., you might have very large image files for figures in your thesis or large output logs from your code), in which case you'll have a faster and nicer time managing the smaller repository much more easily if it's separate from the large.
Another reason to split the two is if you might want to later release the code but not want to encumber it with the thesis source.
Your professor might also have requirements for people they work with in order to promote code reusability, in which case you'd need to follow those.
There are probably other exceptions as well, but for most cases, either combined or separate is OK, and you can always do surgery on the repositories later if you change your mind.
I've generally made two different repos for the following reasons.
By submitting to most publications, you have given them exclusive permission to publish your work. Posting to a public git repo likely violates this. Academic code, on the other hand, is usually published under a very friendly and open license.
Code and thesis/paper commits will not necessarily relate. Especially with papers, you'd like to check-in results, and track it by conference. To anyone but you, these records will be useless. Don't burden everyone else having to download your entire test set, and every result you've had in your 6 years as a PhD student.
Finally, there are a few unscrupulous PhD student who will not pull their weight, then use your hard work to write their own paper. You don't want to give every potential collaborator your life's work.
Another reason in favour of splitting them: my manuscripts' repo is filled with minor commits, rewriting here and there, my supervisor's own corrections, conflict resolution from the aforementioned... A long history that is really no ones business, nor interest.
On the other hand, I am usually the only one that touches my code repositories, so the history is much cleaner. Furthermore, this history may have relevance, and it may be of interest tracking the development of the project.