Всем привет, на этой неделе с вами @gurugray и мы поговорим про #git и пророка его #github

Последние 10 лет я работаю в Яндексе, большую часть времени руководителем больших и маленьких групп разработки фронтенда.

Бекендом я почти не занимаюсь — в основном фронтенд, но меня позвали поговорить про #git, а это полезно всем ;)

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

Вопросы можно начинать задавать. Например почему #git? — «Ну во-первых это красиво…»

Первое внятное чтиво, которое раскрыло мне глаза на то что я понимаю неправильно было think-like-a-git.net — очень полезно и доступно!

Ещё про литературу: для первого чтения НЕ рекомендую git-scm.com/book/ru/v1 — книга хорошая, но для тех кто уже «постиг дзен»

Лучше почитать: www-cs-students.stanford.edu/~blynn/gitmagi… или короткие статьи вроде этой git-init.ru/import/git-is-… (мой перевод)

В последнее время очень неплохие статьи и how-to по #git публикует #Atlassian atlassian.com/git

На ночь глядя: я перевёл на git два самых больших фронтендовых проекта в Яндексе, с тех пор их релизный цикл ускорится на порядки, буквально

Также а ночь (ответ на вопрос) — в Яндекс не надо идти работать, когда не готовы отстаивать свои идеи и понимания оптимальности процессов ;)

Доброе утро, передаю эстафету другому автору, а вопросы про git мне можно задавать в основном аккаунте @gurugray, надеюсь было полезно :)

Всем ещё раз привет, сегодня поговорим про workflow (регламент)

Несколько лет назад я написал краткую заметку git-init.ru/2013/post/why-… но она до сих пор актуальна

На последнем проекте который я переводил с svn'а на git релизный цикл был ужасно медленным и мне предстояло это исправить

Перевести сам проект технически було не сложно, основная сложность была в обучении инструменту и соблюдению регламента

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

После становления процессов и автоматизации рутины — мы упростили регламент для разработчика и приблизились к минимальным действиям

Наш worflow стал больше похож на GitHubFlow, что позволяет запускать протестированные релизы раз в день

В целом про процессы и нашу роль в них я рассказывал на одном из субботников events.yandex.ru/lib/talks/3204/

Раз уж мы заговорили про большие репозитории и файлы — расскажу историю.

В какой-то момент в проекте возникла необходимость хранить большие бинарные файлы версионируя их вместе с исходниками

На тот момент на рыке было несколько решений, но на мой взгляд более перспективным и подходящим для нашего flow мне показался git-lfs

И, хотя на тот момент он был довольно сыроват, мы внедрили его для хранения наших эталонных скриншотов и стабов данных

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

Преимущества git-lfs в том, что его поддержкой занимаются ребята из Github'а и сам протокол и клиент являются открытыми

Детальнее можно прочитать на сайте самого проекта git-lfs.github.com и у Аталссиан atlassian.com/git/tutorials/…

я прошу прощения, последние два дня по работе плотно, в пятницу вечером попробую ответить на те вопросы, которые задавали в реплаях

хуки довольно простая вещь — скрипт, который запускается в разные фазы работы — мы в своём проекте используем npm пакет git-hooks

этот пакет позволяет организовать хуки так как это нам нравится и писать их, например на nodejs ;)

ещё тут настраивается единый формат перевода строк, если например в команде есть linux и windows разработчики help.github.com/articles/deali…

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

из-за их сложности в core переехал другой механизм подключения зависимостей — subtree atlassian.com/blog/git/alter… но и у него есть особенности