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

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 разметка

ДЗ не будет

Спасибо