Github и основы командной разработки

Мохов Олег
Разработчик интерфейсов

Командная работа

git-flow

github-flow

  1. Содержимое ветки «master» всегда работоспособно
  2. Начиная работу – делаем ветку от «master»
  3. Закоммитив часть работы её нужно отправить на удалённый сервер (push)
  4. Когда работа закончена – отправляется Pull Request в «master»
  5. После одобрения Pull Request он вливается в «master»
  6. Продакшн! PROFIT!

GitHub Flow

Стабильный master

Создание ветки из мастера

> git checkout -b my-new-branch
> git checkout -b personal-account-page
> git checkout -b issue-78-personal-account-page

Форки

Форки

Пулл из апстрима

> git remote -v
origin https://github.com/Lucifer-is-my-pet/verstka-tasks-2.git
> git remote add upstream https://github.com/urfu-2015/javascript-tasks-3.git
> git remote -v
origin https://github.com/Lucifer-is-my-pet/verstka-tasks-2.git
upstream https://github.com/urfu-2015/javascript-tasks-3.git
> git pull --rebase upstream master

Pull Request

  1. В названии PR хорошо бы сослаться на решенную задачу
  2. Политка «двух ОК»: пока два человека из команды не отсмотрят PR – его вливать нельзя
  3. Автоматизация назначения Review'ов, пример, https://github.com/facebook/mention-bot

Зачем нужно CodeReview?

Зачем нужно CodeReview?

  1. улучшение качества кода
  2. оптимизация алгоритмов и архитектуры

Зачем нужно CodeReview?

  1. улучшение качества кода
  2. поиск багов
  3. оптимизация алгоритмов и архитектуры
  4. консистентность
  5. распостранение знаний о проекте
  6. прокачивание скиллов

Для чего не нужно CodeReview?

  1. code style
  2. jshint
  3. jscs
  4. css lint
  5. git hooks
  6. и всё что возможно автоматизировать

Что ещё стоит знать?

  1. CodeReview – это коллективная ответственность за код: если ошибка попала в продакшн, значит её пропустили все
  2. CodeStyle правки не обсуждаются в PR, а должны проверяться роботами!
  3. Для новеньких в команде это хорошая возможность как быстро приспособиться, так и смотреть на чужой код (вспомним первые задания ;)
  4. Staging-сервера с работающей копией кода PR – это тоже часть CodeReview
  5. PullRequest – это один из способов CodeReview. Возможно делать его очно при обсуждении, возле доски и т.п

rebase

rebase

> git pull --rebase upstream master
> git rebase -i HEAD~20
pick c4f8ade Добавлена задача к первой лекции: HTML, I часть
pick a9d3cb2 Основное сделано осталось навести красоту
pick 529ff45 Кажись, всё
pick 38dd958 Больше ссылочек, вынесен style
pick c5253a6 незакрытый тег, ай-яй-яй
pick 907ac8d по codestyle
pick 9743e29 по codestyle[2]
pick 00e997b по codestyle[3]
pick 5722e34 по codestyle[4]
pick 312507b Пофиксено[2] OpenGraph, br'ы, hr'ы, почта, стили
pick 02848dd по codestyle[4.1]
pick f2ce4e3 по codestyle[5]
pick 6644af5 по codestyle[5.1]
pick 2d744f0 по codestyle[5.2]
pick 7e73987 Пофиксено
pick 251cea9 Пофиксено[1.1]
pick 199eda1 Пофиксено[2]
pick ea42d38 Пофиксено[2.1]
pick 9297b84 Пофиксено[2.2]
pick 159b337 Пофиксено[2.3]
pick 02d3688 Пофиксено[2.4]
pick f47b774 Пофиксено[2.5]
pick 363c23c Пофиксено[2.6]
> git push -f origin task-3

Задача

Заголовок

  • Поменять favicon
  • Обновление страницы
  • Обновление страницы «Контакты»
  • Поменять favicon на странице «Контакты»
  • Рефакторинг

Понятно?

Что?

Хорошая задача

  • Чётко сформулирована
  • Отвечает на вопрос: «Что должно получиться в итоге?»
  • Имеет измеримые сроки выполнения
  • Реализуема в принципе

Плохая задача

  • Сформулирована туманно
  • Не отвечает на вопрос: «Что должно получиться в итоге?»
  • Не имеет измеримых сроков выполнения
  • Не реализуема в принципе

Плохая задача

  • Сформулирована туманно
  • Не отвечает на вопрос: «Что должно получиться в итоге?»
  • Не имеет измеримых сроков выполнения
  • Не реализуема в принципе
  • Можно декомпозировать

Issues

  • # – для того чтобы сослаться на задачу

Issues

  • # – для того чтобы сослаться на задачу
  • @ – для того чтобы сослаться на юзера
  • Markdown разметка

ДЗ не будет

Спасибо