Git How To: Workflow

Описание работы с гитом и командной разработки вообще.

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

Предлагается два варианта. В ветке master у нас лежит стабильная версия кода/вебсайта, которая обновляется только тогда, когда загружаемый код стабилен. Все разрабатываемые вещи можно хранить с помощью двух подходов: форком репозитория себе и работе в своем репозитории, или создание различных веток (branch) в рамках основного репозитория и потом слияния веток в master.

Слияние кода (неважно откуда, из ветки или собственного репозитория) в master не должно происходить напрямую. Необходимо создавать Pull Request, и несколько человек будут просматривать код, перед тем как принимать его в основную ветку. Это делается для того, чтобы в коде было меньше ошибок, и стилистических в том числе. :)

Желающие могут более подробно почитать здесь.

Пример

Давайте рассмотрим пример с форком репозитория. Я форкнулся от репозитория lanit-summer/orbit, и теперь имею свой репозиторий kroartem/orbit, где могу творить всякие непотребства. Предположим, был сделан коммит:

Далее, в репозитории lanit-summer/orbit я нажму на зеленую кнопку, выберу, из какого репозитория и ветки в какой я хочу сделать пулл-реквест, и создам его.

Теперь я могу писать в комментах к пулл-реквесту, что код говно что есть проблемы, или, наоборот, всё ок, можно сливать в главный репозиторий. В идеале, делать это должен кто угодно, но не тот, кто создал пулл-реквест, а иначе зачем нам это всё тогда. :)