«Правильная» организация проекта на github

Нет, делаешь просто один master, а стабильные релизы, собственно в релизах.

Хватит ли двух веток -master и -devel?

Это нужно если будет команда, если ты один и у тебя тольк одна текущая версия продукта то мастер и ветки под фичи - и то если они монструозные и требуют долгой разработки

мастера хватит

Я просто предпологал, что вся работа ведется в dev, а master заморожен, т.е. всегда можем оттуда выкатить не боясь косяков

несколько человек

Лучше, на мой взгляд, использовать теги - вся разработка в мастере, «релизы» фиксируем. Ветки же (снова ИМХО) лучше «смотрятся» когда разработка начинает вестись в совсем другую сторону - меняется какой-то важный модуль с кучей «зависимостей», логика приложения etc.

А причём здесь гитхаб? Для небольшого проекта хватит и master.

Релизы как обычно помечаешь тегами. Если планируешь поддерживать старые ветки, то с появлением новой ветки создаёшь ветку для старой.

Например текущая ветка 1.x, Следующая 2.x, значит создаешь ветку 1.x. В мастере ведёшь разработку второй ветки и по необходимости бэкпортируешь фиксы в первую. Тут всё очевидно.

Ну а если проект вдруг разрастётся, то возможно стоит посмотреть в сторону вот этого расширения.

для этого должны быть теги и билдсервер, одним мастером это не решается на и http://habrahabr.ru/post/106912/

о, спасибо, годная статейка

Веди работу в личном репозитории и сливай (pull-request'ами) готовое и проверенное в master ветвь репозитория организации.

Если работников больше одного, то есть довольно популярный и хорошо описанный git-flow http://nvie.com/posts/a-successful-git-branching-model/

Вряд ли. Кодревью, всё-таки, нужно делать, а для этого лучшего способа, чем пуллреквесты, не придумано.