Как безболезненно внедрить Git?

Question

[Sergey Zhukov]

Всем добрый вечер!
Работаю над проектами в основном я один. Вот приходится всеми правдами и неправдами как то биться :)
Решил git внедрить в проекты. Получается вот такая рабочая структура:

Т.е. разработка в основном идет на моем рабочем ПК, настроена автоматическая синхронизация с Dev. Host (для просмотре результата кода). Как сделал фичу, делается PUSH в репозиторий bitbacket. И потом, после утверждения правок можно зайти на Prod Host и сделать туда PULL.

По крайней мере я понял это должно выглядеть как то так :)

На данном этапе я работаю исключительно с Dev. Host и с него ручками все копируется на Prod Host.

Засада номер раз: вычитал во всяких умных Git work flow, что многие для фич и изменений создаются ветки develop и разработка ведется исключительно в них, периодически делаются слияния. Не понимаю, где эти ветки должны быть: только у меня на ПК или на продакшене тоже. В будет преимущество перед текущей моделью транспортировки данных. И нужна ли ветка Develop на продакшене? Я понимаю. зачем нужны ветки, я не понимаю, почему их пихают везде где попало.

Засада номер два: Мой рабочий проект (папка) лежит в дропбоксе, напрямую. И из дома так же напрямую из папки дропбокс и запускается проект. В PhpStorm. Т.е. я поработал в офисе, пришел домой и мне ваще ниче не надо делать, только IDE запустить и все. А часто IDE сама говорит мол давай перерендерю заново, там файлы поменялись.
Я так понимаю, что от дропбокса придется отказаться и дома тоже делать PULL. Поработал дома, сделал PUSH в bitbacket . И вот так туда сюда push-pull. Забыть сделать тот или другой как здрасьти ;(

Есть замечания по мыслям вот таким мыслям? :)
Спасибо.

Answer 1

[FoxInSox]

1. на Битбакете должны быть dev ветка, master ветка и теги релиз версий. feature/hotfix ветки по необходимости. Т.е. если фича/фикс растягивается на больше чем один день, то вечером перед уходом домой вы пушите ее в репозиторий. На следующий день если вы работаете из дома, то выкачиваете ее из репозитория. Так же если вы не придете на работу, то другой разработчик сможет продолжить вашу работу выкачав ветку из репозитория.Чтение про ветки.
2. В вашей схеме не хватает CI-сервера, и потому появляются разные костыли и вопросы по поводу веток. CI-сервер автоматически при коммите в dev ветку(закоммитчена фича/хотфикс) собирает проект, прогоняет тесты и деплоит ваш проект на dev сервер. При коммите в master ветку(закомитчен хотфикс или релиз ветки из dev) он прогоняет тесты и деплоит ваш проект на продакшн.

Comments

[Дмитрий Вапельник]

не всегда нужен CI-сервер ибо не всегда разработчику нужно собирать проект и прогонять по нему тесты. это довольно идеальная ситуация, которой следует придерживаться, но в большинстве случаев проект просто выгружается на сервер и там работает. в данный момент я занимаюсь разработкой проекта на Symfony2 в такой стратегии развертывания: веду разработку локально на ноуте без dev.host, при создании какой-то фичи я делаю пуш в репозиторий, захожу на prod.host, делаю там пулл и разворачиваю проект (коспозер обновляет свои пакет, bower - свои, Grunt делает свое дело, обновляется БД). по сути CI-сервер делал бы то же самое, но.. Но он мне здесь не нужен ибо сейчас я не все покрываю тестами (знаю, надо бы, но, как всегда, некогда), но сказ не о том. Разворачивание приложения с репозитория можно завернуть в один скрипт, который можно положить на сервере и запускать его по желанию с локальной машины

[Sergey Zhukov]

Дмитрий Вапельник: по поводу обновления композера, бовера и прочих. Бывают например, кастомные версии бутстрапа, и их не надо обновлять. У меня конфликтовал pluplod и бутстрап. Пришлось из бутстрапа выпилить конфликтные кнопки.

[Дмитрий Вапельник]

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

Answer 2

[Alexander Movchan]

Раз, два.
Гит - распределённая система контроля версий. А это значит, что:

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

Comments

[Sergey Zhukov]

Да это понятно что децентрализовано, но мне как на продакшен то изменения высылать? А куча вопросов появилось именно из-за прочтения первой статьи)

[Влад Пасечник]

Сергей Жуков: git pull)

[Sergey Zhukov]

Влад Пасечник: дык если компы то никак не связаны между собой, откуда пулить то?)

[Влад Пасечник]

Сергей Жуков: как это не связаны) dl2.joxi.net/drive/0007/2813/473853/150829/c08a7a1...

[Sergey Zhukov]

Влад Пасечник: ну поэтому я через битбакет и делаю. Просто Вы так написали, как будто без него можно было бы :)

[Alexander Movchan]

Сергей Жуков: можно и без bitbucket'a. Просто к нему легко получить доступ, практически из любой точки мира, так как он доступен через интернет. Если вам этого не нужно, вы можете создать bare-репозиторий на локальной машине:
git init --bare [directory]

Answer 3

[Павел]

мне и самому стало интересна эта тема :)
по дропбоксу , по моему нет смысла от него отказываться , репозиторий по сути просто файлы , не важно где они лежат. Будет просто у вас он и дома и на работе одинаковый всегда. А пулл и пуш делать уже на битбакет

Comments

[Алексей Васильевич]

Прелесть гита (по сравнению с дропбоксом) - наличие "снимка" изменений (changeset-ов). Если вы работаете по принципу "1 файл - 1 коммит", то можно и дропбоксом хранить историю, но на деле это редко бывает. Поэтому очень актуально видеть, какие файлы были изменены при том или ином коммите

Answer 4

[Михаил]

"И нужна ли ветка Develop на продакшене? Я понимаю. зачем нужны ветки"

И все же вы не до конца понимаете, зачем нужны ветки, если у вас ветка "develop".
Обычно это так делается: есть транк - с ним все понятно. Есть задача на фичу. Брэнчуемся, делаем фичу, мерджимся обратно в транк. И так на каждую фичу своя ветка. Баги правим только в ветках (иногда будет требоваться ребейз).

Деплой, однако, идет не из транка. Ведь в транке версия SNAPSHOT. А деплоить на прод нельзя такое. Как надо: брэнчуетесь от транка, убираете SNAPSHOT, прогоняете все тесты (внимание на слова FoxInSox: CI нужен), деплоите с этой ветки.

Возвращаясь к разработке, вы опять брэнчуетесь от транка для каждой фичи или комплекта фич.

Comments

[Sergey Zhukov]

CI, я так понимаю это Continuous Integration. Надо разобраться с этой штукой.

[Михаил]

Сергей Жуков: все верно. Это даст вам понимание как устраивать анализ кода (валидация, статический анализ), как устраивать тесты (все, от модульных до стресс-тестов) и еще много другое.