под какой учеткойТак это тоже сомнительное удовольствие, т.к. в зависимости от разработчика может требоваться абсолютно разная детализация проверки его коммита.

Если вы дали кому-то доступ на запись к репозиторию, то это означает, что вы ему доверяете и верите, что он чужое имя в своих коммитах использовать не будет.

А "ревьювятся" в смысле держать их всех в разных ветках и сливать самому или в Git есть именно специальный механизм проверки коммита тимлидом перед тем как он попадет в репозиторий?
Держать в разных ветках. Специальный механизм, если вы хотите с ним связываться, называется hooks. Ими можно сделать разрешения на коммит в 'основную' ветку.

В случае github-а проще просто держать по репозиторию на разработчика. И не давать прав на запись в чужой репозиторий. Когда надо, разработчик посылает pull request тимлиду и уже он сливает изменения в основной/свой репозиторий.

githubА из pull request по крайне мере можно будет понять из какого репозитория пришли изменения?
В самом pull request-е в github-e видно, кто его посылает.

Дальше последовательность действий такая:
1) Создаем тестовую ветку в локальной (на рабочей машине) копии основного репозитория.
2) Сливаем в тестовую ветку предлагаемые коммиты.
3) Внимательно узучаем, что изменилось, прогоняем тесты, проверяем правильность оформления коммита и.т.д.
Если чего не так - ругаемся в сторону разработчика. У github-а для этого есть достаточно богатый набор инструментов, включая обсуждение кода с точностью до строки.

Когда все сделано правильно
5) cливаем изменения в основную ветку локального репозитория и делаем для нее push на github.

Если кто-то хулиганит и подписывается не собой, то коммит просто не принимаем на шаге (3).
А если нас совсем паранойя замучала, то прописываем в политику разработки, что коммит должен быть подписан PGP подписью и следим за этим.