Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Пишем проект, есть Android, iOS и Backend (PHP) проекты, заказчик попросил слить все в один репозиторий на GitHub, на разные 3 ветки. Адекватный ли он?.Что сказать, человеку предложившему такое? Какие минусы такого подхода?
3 ветки делать неправильно совсем, от этого нужно отговаривать. Вот мои аргументы:
1) Если я фронтендщик, но мне понадобится поднять локально бэкэнд (для тестирования например) — я не смогу этого сделать, если моё фронт-приложение находится в другой ветке. Это разве что клонировать репозиторий в 2 разные папки, но это неудобно, так как вдвое больше места на моей машине и каждый раз когда приходят изменения, надо в 2х репах выполнить git pull
2) Ветки предназначены для хранения разных версий проекта, а не разных проектов, делать по-другому — это просто некорректно использовать инструмент Git
Можно либо иметь репозиторий отдельно на каждый проект (андроид, айос, бэк), либо хранить все в одном, но не в разных ветках, а просто в разных каталогах.
Первый подход (3 репозитория):
+ Можно физически разделить разных разработчиков, дав только нужные им уровни доступа. Например андроид-разработчику разрешить делать что угодно с андроид-репозиторием, только читать бэкэнд-репозиторий (через защищенные ветки, пулл-реквесты, если гитхаб не позволяет иначе) и не давать доступа к айос-репозиторию.
+ Ускоряет работу для каждого разработчика и позволяет экономить место на диске, забирая только нужное
+ По фэн-шую :)
— Возможна рассинхронизация, когда фронт (или в вашем случае приложения) будет несовместим с бэком, но это не проблема, а рабочий момент. Для этого есть теги, нужна просто коммуникация между разработчиками и правило, что если версия приложения 0.2.1, то оно должно быть полностью совместимо с бэкэндом версии 0.2.1. А учитывая что разработчиками являются скорей всего 3 разных человека — эту проблему общий репозиторий все равно не решит.
Второй подход (1 репозиторий):
+ Рассинхронизации быть не должно, весь проект так сказать монолитен (на самом деле нет, так как смотри выше про 3х разных человеков)
— Разделить разрабов сложнее. Договориться можно, но следить за соблюдением договоренностей сложнее
— Зачем мне код айос-приложения, если я андроид-разработчик
— Не по фэн-шую
В общем-то для ситуации, когда разработчика 3, и каждый занимается своим, самым удобным способом работы являются 3 репозитория. Если разработчик один, или несколько, но все понимают во всем и могут править всё — можно 1 репозиторий, просто каждая часть в соей папке. Вариант, предложенный заказчиком, неудобен ни в каком случае.
Это разве что клонировать репозиторий в 2 разные папки, но это неудобно, так как вдвое больше места на моей машине
Если клоны по одной ветке, нет увеличения места.
надо в 2х репах выполнить git pull
Только там, где надо втянуть новые изменения.
Ветки предназначены для хранения разных версий проекта, а не разных проектов
Реально такого ограничения нет. Есть масса примеров, где в ветках заведомо несовместимое содержание. Но, да, многих будет смущать.
Посоветуй переходить сразу на JDSL: thedailywtf.com/...
Три репозитория, или три ветки — большой разницы вроде особо нет. Веселее будет, если он попросит все слить в одну ветку:) Но вроде и с таким люди справляются:
www.digitalocean.com/...
github.com/...
Мабуть же замовник має свої аргументи «чому саме так треба зробити». Якщо він боїться розсинхронізації різних залежних проектів, то запропонуйте йому краще використовувати котрийсь із пакетних менеджерів.
Наприклад, вам спокійно можна використовувати npm, хоча він і є рідним для Node.js, але поставить будь-які проекти хоч із npmjs.com, хоч із git-сховища, хоч із каталогу на локальній машині (чи із диску в локальній мережі).
1) Один разраб одним пушем может убить все 3 проекта, совсем убить без возможности восстановления. Чтобы убить проекты в разных репах, надо чтобы кол-во коммитов == кол-ву проектов.
2) Если у вас там много больших файлов — переключение (да еще и не на SSD) будет веселый, долгий и шумный процесс.
3) Нет возможности разграничить доступ (например, позвать индуса фиксить опечатки (лол) в проекте 1, и не дать возможность взять код (или стырить, лол) других 2х проектов).
4) Если человекаА работает только на проекте 1, то зачем ему код двух других проектов локально? Занимает место (и лично меня бесило бы).
4) Не по фен-шую.
Один разраб одним пушем может убить все 3 проекта, совсем убить без возможности восстановления.Как у вас там, на SVNе, дела, все нормально?
Не знаю, я им не пользуюсь.
Расскажите тогда как одним пушем убить проект в DVCS без возможности восстановления.
git push -fА потом
git pruneили
git gc(не помню).
это решается стандартно, называется «protected branch», и от количества мастер-веток принципиально не меняется.
1. Как выполнить git gc на гитхабе?
2. Как одним форс-пушем запушить в локальные репозитории всех разработчиков проекта?
V toj statje kakaja to eres’ napisana. Libo ona ochen staraja i Git za eto vremia silno izmenilsia. Vsia fishka Gita, sto tam ochen slozhno delat destruktivnie dejstvija sluchajno. Esli delaesh cherez sliu (-f) to konechno sam durak. Ot duraka s root privilegijami uvi ni odna sistema ne zachitit.
1. Protected branch, тоже мне невидаль. И один пуш или три — это не принципиально. Плюс даже если забыть защитить ветки, локальные копии все равно будут у многих на крайняк. Так что высосано из пальца незнания.
2. А вы не переключайтесь. Три ветки не значит одна рабочая директория на workstation.
3. Это не всегда так уж и важно.
4. Мелочные придирки, реально становится неудобно только для монстровых проектов, но это судя по всему совсем не.
4) Не по фен-шую.вот с этим согласен.
Какие минусы такого подхода?
Clone/fetch по умолчанию будут тянуть изменения всех веток. Но это может быть плюсом.
Потенциально путаница в git branch.
Git’у без разницы, дерево там или лес. Технических проблем не будет.
Участвовал в написании двух небольших проектов, у которых проекты для Android и микросервисы на Java хранятся в одной ветке в разных папках с названиями «android», «api» etc. Никаких неудобств никто не испытывал.
Сначала выяснить что он на самом деле хочет и почему, а потом предложить более стандартный и удобный всем вариант.
мне кажеться, что тут дело в платных репозиториях на github, он не хочет выделять 3 штуки, а хочет 1, и чтобы мы залили 3 проекта туда
Пусть юзает битбакет, раз такой... ммм... экономный — там убрали лимит на количество приватных реп...
Или Gitlab, он вообще бесплатный.
Гитхаб снял ограничение на количество приватных репозиториев если берешь подписку, т.е раньше это было бы логично
Gennady Dogaev
Valentin Nechayev
Сергей Харагоргиев
Andriy Maletsky
Костя Третяк
Slava Abakumov
Alexander Yakushev
Slava Abakumov
anonymous
Mykola Gurov
Vasilij Savin
Jorzchyk Pushysty
Valentin Yuryev
Mykola Gurov
Konstantin Strukov
Nick Yurov
Костя Третяк
Artem Khomenko
Eugene Varava
26 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів