Про GitHub.

1) Любой проект, даже самый маленький начинаю в новом репозитории. Потому что:
- мало ли что из него вырастет,
- код в Гитхабе это бэкап, не засерается место в Дропбоксе или других облаках,
- мгновенный поиск по коду в репозитории, актуально когда проект уже достаточно большой,
- легче спросить совета у коллег или показать проблему, когда исходники можно посмотреть онлайн,
- проект удобно хоронить, если он заглох, или закинуть в портфолио, если он клевый.

2) Создал себе на Гитхабе две дополнительные организации внутри своего аккаунта.
- «paulradzkov-forks» — для форков чужих проектов.
- «paulradzkov-heaven» — кладбище для старых проектов, куда перемещаются все неактуальные проекты.
Эти две дополнительные организации позволяют очистить основной аккаунт от мусора. В нем теперь только несколько актуальных проектов, в которых легко ориентироваться.

3) Перемещаю все старые проекты из Дропбокса на Гитхаб в «paulradzkov-heaven». Проектов много, это долго, но освободилось уже несколько гигов (т.к. там кроме кода psd-исходники, архивы с инсталляторами и прочее). Место в облаках заканчивается, а на Гитхабе — резиновое.
Это кладбище уже пригодилось, когда у меня попросили поискать исходники проекта, над которым я работал 3 или 4 года назад, а я через минуту ответил им ссылкой на нужный репозиторий. Не пришлось никуда лезть, распаковывать, искать, запаковывать, отправлять почтой или закачивать в облако.
Повторюсь, что на Гитхабе классный поиск по исходникам: если нужно посмотреть, как что-то сделал в старом проекте, но не помнишь в каком — можно довольно быстро найти искомое без возни с архивами.

Итого.
Код должен лежать на Гитхабе.
В том числе старые проекты.
Используйте организации, чтобы рассортировать проекты, если их много.
Порядок там, где у каждой вещи есть своё место. Придумайте себе правила порядка заранее и соблюдайте их, чтобы не тратить время на ликвидацию беспорядка.

Первый путь.
На Гитхабе поискать по ключевым словам (BEM, SMACSS, OOPCSS) — найдутся бойлерплейты и стартеркиты, которые по определению должны быть хорошего качества.

Можно искать глубже, по упоминанию в исходном коде этих ключевых слов — найдутся тысячи проектов, но тут сложнее определить, что качественнее.

Второй путь.
Искать в Гугле людей, которые пишут про BEM, SMACSS, OOPCSS и прочих крутых фронтендеров. Искать их профили на гитхабе, изучать их проекты. Если они пишут про методологии, то они явно их используют в работе.

1. Размеры шрифта и полей для всех текстовых элементов (вся типографика: заголовки, абзацы и т.д.) задавать в em. Чтобы их можно было легко масштабировать и при этом сохранялись пропорции отступов (смотри пункт 4).

1.1. Для заголовков в качестве прогрессивного улучшения можно дополнительно задать размер шрифта в vw. Посмотрите пример — codepen.io/paulradzkov/pen/jqYqgY
vw и vh уже достаточно широко поддерживаются (caniuse.com/#search=vw), если вы не верстаете для Китая.

2. Размеры элементов форм (инпуты, кнопки), их поля и иногда бордеры задавать в em. Чтобы они были одного масштаба с окружающим их текстом. А также смотри пункт 4.

3. Ширину колонок модульной сетки, сайдбаров и прочих layout-элементов в общем случае задавать в %.

3.1. Если ширина чего-либо зависит от своего контента, а не от ширины вьюпорта, то лучше использовать rem* или верстать через flex, не задавая ширину явно.

3.2. Отступы layout-элементов, гуттер между колонками — в rem*. Иногда по дизайну нужно задавать в %.

4. Размер шрифта крупных модулей лучше задавать в rem*. Например, мы пишем:

.promo {
    font-size: 1.2rem;
}

.sidebar {
    font-size: 0.8rem;
}

Благодаря тому, что у нас пункты 1) и 2) в em-ах, шрифты и формы в промо блоке и в сайдбаре изменятся разом в 1.2 и 0.8 раз. При этом, если засунуть .promo внутрь .sidebar, размер шрифта промо-блока всё равно останется в 1.2 раза больше дефолтного текста. Т.е. не зависит от контекста.

5. Для @media-выражений рекомендуют использовать em, потому что раньше в браузерах был баг (вроде все уже пофиксили), когда пользователь масштабировал страницу (ctrl + ± или ctrl + scroll), появлялась нежелательная горизонтальная прокрутка. Я всегда писал в px и никогда с такими багами не сталкивался.

6. Если вы хотите масштабировать сайт целиком, то через @media-выражения можно менять размер шрифта элементу html — в px. Тогда все, что было задано в rem и em отреагирует на это изменение.

* — если вы не меняете и не планируете менять размер шрифта html-элемента, то везде вместо rem можно смело писать px. Ничего не изменится.

Все остальные единицы измерения используются в частных случаях. Для печати могут понадобиться mm или pt; для высоты фиксированных элементов — vh; ex и ch для типографских выкрутасов.