5 причин внедрить Git для Product Owner’a26.07.2016 12:48

Вместо предисловия

Однажды, когда я учился на ФизТехе, на перемене между парами по каким-то физикам преподаватель решил немного отдохнуть, нарисовал квадрат на доске и сказал: «Двумерный куб». Затем нарисовал трехмерный куб. Мы лениво болтали, и никто не проявлял особого восторга по поводу кубов.

Но Кирилл Александрович, похоже, не собирался останавливаться. Он спросил: «Четырехмерный рисовать?». И, недолго думая, нарисовал.

Это всего навсего куб, у которого грани не плоские, а кубические, и есть еще одна степень свободы. Если интересно, можете посмотреть.

Полюбоваться на гиперкуб (тессеракт)

Git — это одна из тех технологий, потенциал которой не сразу понимаешь, но когда поймешь, она переворачивает логику с ног на голову. А точнее, полностью заменяет старую логику новой. И, в отличие от тессеракта, Git умеет приносить прибыль.

Предлагаю рассмотреть преимущества от использования Git по сравнению с работой без него, например, только по FTP-протоколу.

Что такое CVS?

Год назад мы писали статью про Git CVS. Статья уже устарела, поэтому объясню, как я это понимаю сейчас.

CVS (control version system, система контроля версий) позволяет хранить не только файлы кода, но и историю их изменений. Также она позволяет хранить альтернативные истории файлов (ветки) и, таким образом, вести разработку одного проекта параллельно для решения разных задач разными людьми одновременно.

Изображение контрибуций (изменений) проекта в 3D-изометрии на github.com с chrome-плагином Contributions Chart

Почему Git — лучшая CVS для вашего проекта?

Git — производительная и удобная CVS. Git хранит все снимки (слепки) файлов. SVN (ближайший конкурент) хранит первую версию файла и последующие изменения. В итоге, чтобы получить какой-либо файл в определенной версии, Git«у в отличие от SVN, не приходится находить все изменения, он берет готовый слепок, и в результате, существенно выигрывает в производительности. Эта структура отпечатывается на архитектуре ветвления и является killer-feature, сделавшая Git CVS № 1 в мире.

1Новая логика хранения данных. Коммиты

Git помогает навести порядок в голове. За что вы платите своему подрядчику? Подумайте.

За часы, потраченные на решение задачи? За конечные результаты, работающие фичи вашего проекта? За строки кода, написанные программистами?

Нет, на самом деле, вы платите за продуктивные изменения кода вашего проекта (коммиты).

Коммит — это логически объединенный набор изменений в различных файлах, направленный на решение конкретной задачи. Коммиты — ваша собственность. Вы можете хранить их, управлять ими и, конечно, использовать на своем проекте, причем не обязательно все сразу, можно применять или отменять любой из них по отдельности. Согласитесь, результаты и часы разработчика, хотя и существенные единицы измерения, но совершенно неудобные для осмысленной каталогизации.

У нас в офисе даже висит плакат с надписью «Сделал задачу — сделай commit». (Кому нужен такой — пишите в комментариях).

На этом простом сопоставлении задачи и коммитов строится самая популярная стратегия разработки на Git под названием GitFlow. Кроме того, хорошие команды разработчиков физически связывают задачи в таск-менеджере с коммитами. Например, в Trello Business карточки можно связать с коммитами Github, а запросы (issues) в Jira хорошо дружат с ветками и коммитами в Bitbucket. Мы используем последнюю связку.

2Прозрачность

Будьте осторожны, дочитав до конца эту главу, вы уже не сможете, как раньше, жить с FTP.

Для начала, просто заведите бесплатный аккаунт на онлайн-сервисе bitbucket.org или github.com. Таким образом, вы создадите для себя чертовски удобное хранилище вашего кода. С одной стороны, это более прозрачное решения для вас, с другой, надежное и удобное для вашего разработчика.

Перечисленные выше сервисы дают возможность просмотреть историю проекта (визуализировать команды git diff, git log и подобные), подключить людей к проекту и сделать еще несколько административных действий (создать ветку для разработчика, одобрить pull-request и тп). Бесплатный аккаунт на Bitbucket позволяет создать приватные репозитории и делиться ими с максимум 5-ю другими пользователями Bitbucket. Бесплатный аккаунт Github позволяет создавать только публичные репозитории. Это еще одна причина, почему мы используем Bitbucket.

Ваш список коммитов на Bitbucket будет выглядеть примерно так.

1) Список коммитов, в котором видно автора, время, комментарий (сообщение коммита). Кликаем интересующий коммит…

2) … и попадаем на страницу коммита, где видим его краткую статистику.

3) Затем мы скроллим страницу коммита для подробного описания, где видно, какие строки были добавлены и удалены.

Можно даже наглядно увидеть, как для коммита изменялись картинки, довольно удобная фича.

3Скорость

Сидит программист, заваривает чай, ковыряется в телефоне. Спрашиваешь, чем он занят, а он отвечает «Оно заливается». По FTP. Весь сайт. С одного сервера на компьютер, затем с компьютера на другой сервер. ПОФАЙЛОВО.

Конечно, я утрирую, и в такой ситуации программист все равно получает по шее, так как всегда есть параллельные задачи, но все-таки это было неудобно и неправильно. Git полностью решил для нас эту проблему. Git такой быстрый, что даже слишком. Перенос файлов, занимавший пару часов по FTP (при офисном интернете в 5–10 мб/с), занимает пару минут или даже секунд с Git при любом интернете, хоть с модема работай.

На то есть несколько причин:

a) Передаются только изменения

FTP при каждом обновлении проекта копирует ВСЕ файлы, не разбирая, есть ли в них изменения. Git передает только измененные данные, а это, как правило, на несколько порядков меньший объем данных.

б) Напрямую между серверами

Git«у не нужен ваш компьютер и ваш интернет для того чтобы, например, перенести файлы с тестового сервера на боевой. Все файлы перемещаются между серверами, у которых пропускная скорость канала значительно превышает скорость интернета в вашем офисе/доме. Не знаю почему, но FTP так не умеет. Это экономит время даже при первом переносе данных между репозиториями (особенно, веб-серверами).

в) Архивация по умолчанию

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

4Анти-факап, или Защита от человеческого фактора

Git магическим образом защищает от факапов (серьезных ошибок). Если что-то попало в коммит или, тем более, на git-сервер (тот же Bitbucket), разработчику придется очень сильно постараться, чтобы это стереть. На самом деле, Git защищает даже не попавшие в коммиты данные, например, запрещая делать слияния при «грязном» состоянии репозитория (когда есть непроиндексированные изменения в рабочей области). Другими словами, это отличная защита от дурака, которая поможет вам случайно не потерять результаты работы.

К тому же, когда что-то сделано неправильно, причем, сделано неправильно на «боевом» сервере, то, благодаря своей производительности, git позволит очень быстро откатиться на стабильную версию и без спешки разобраться с проблемой, перенеся ее на тестовый сервер.

Конечно, есть нюансы, так как любая CVS все-таки допускает возникновение конфликтов при слиянии разных версий проекта (веток), но есть ряд инструментов позволяющих как избежать появления конфликтов (git merge —Xtheirs, -Xours), так и позволяющих разрешить конфликт (например, vimmerge).

5Совместная разработка

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

Если совсем просто, то с Git пропадает всякий бред типа в скайпе писать «не трогай style.css, сейчас я его правлю». Один и тот же файл могут редактировать разные разработчики одновременно, сперва делая его копию себе в локальный репозиторий (проще говоря, на компьютер), затем сливая свои изменения вместе.

Как выглядит простейший процесс разработки на Git

Напомню, мы рассматриваем ситуацию только со стороны заказчика. Так будет выглядеть текучка при правильно настроенном Git. Попросить настроить Git вы можете своего разработчика или нас.

1) Вы ставите задачу разработчику.

2) Разработчик выполняет ее локально или вживую прямо на своем тестовом сервере. Вы проверяете результат на тестовом сервере, принимаете работу.

3) Разработчик создает коммит, соответствующий задаче и перемещает его на ваш репозиторий в Bitbucket.

4) Вы заходите на свой сервер и подтягиваете результат с помощью простейших команд:

cd /path/to/your/website/

git pull

Важное замечание: все будет именно так просто, пока вы не начнете вносить изменения на свой живой сервер. Либо вы его перестаете трогать сами, либо учитесь делать коммиты после каждого изменения. В нормальном состоянии, все изменения на каждом сервере должны быть закоммичены, чтобы не было упомянутого выше «грязного состояния».

Если что-то не получится или вы сомневаетесь, что сможете правильно все настроить, не стесняйтесь. Пишите в комментах, обещаю ответить.

Итог

Как видите, для того, чтобы получать пользу от использования Git вовсе не обязательно быть разработчиком, знать все команды в консоли и настраивать сервер. Просто создайте бесплатный аккаунт на Bitbucket.org, пригласите туда ваших разработчиков и следите за тем, как их работа ложится лист за листом в книгу вашего проекта. Книгу, которую вы сможете открыть на любой странице и перемещаться в сюжете, зная, что ваша собственность — коммиты, под надежной защитой Git.

Источники:

Мнение: Алексей Шишкин, генеральный директор Redsoft

Честно говоря, я не сторонник глубокого погружения в технологии менеджеров проектов/продуктов, но очевидно, что понимание принципов работы основных инструментов для разработки необходимо. При разработке финансовых и e-commerce проектов git — один из таких инструментов, и по важности его может превзойти только система резервного копирования. И, как и в случае с бекапами, ценность понимаешь тогда, когда что-то уже потеряно. Самый «веселый» случай — когда при одновременной работе сеошников, разработчиков и специалистов на стороне клиента в интернет-магазине кем-то сносится функционал заказа (и, предположим, автотесты на проекте не работают). И все дружно кивают друг на друга. Git в такой ситуации не только даст ответ, что именно было поломано, но и кем, когда и при каких обстоятельствах, в составе какого из обновлений. По нашему опыту многие менеджеры из крупных компаний уже слышали о git, но только организации с иностранными штаб-квартирами настаивают на применении систем контроля версий, российские же отдают решение о контроле кода самими разработчикам. А сами менеджеры выдают запросы в виде «Где мне скачать гит, чтобы работать с проектом?», «Дайте мне доступ в гит, я сам набью тексты на сайт» и т.п., что говорит о необходимости статей, подобных этой.

Полный текст статьи читайте на CMS Magazine