LINUX.ORG.RU

Организация GIT-репозитория

 ,


0

2

Есть корпоративный репозиторий (Gitlab). Необходимо дать публичный доступ, но с оговоркой: видна должна быть только ветка master, т.е. вся внутренняя кухня (текущая разработка) видна быть не должно до попадания в мастер. Знаю, что в силами самого Git-а доступ (по сути видимость) веток не разграничить. Пока видится одно решение, на мой взгляд костыльное: создать форк основного репозитория, мастер форка синкается с мастером основного репозитоия, наружу дать доступ только до форка.

Может есть более изящный способ такое осуществить?

Есть корпоративный репозиторий (Gitlab).

Не вкурсе, на Gitlab Organization нету?

Deleted ()

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

Делай так, это имхо оптимальный кейс.

Dudraug ★★★★★ ()

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

Так ведь в форке будут все ветки видны. Если уж так костылить, то лучше завести отдельный репозиторий, и регулярно автоматизированно в него коммитить текущее состояние master-ветки основного репозитория.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Так ведь в форке будут все ветки видны. Если уж так костылить, то лучше завести отдельный репозиторий, и регулярно автоматизированно в него коммитить текущее состояние master-ветки основного репозитория.

Если ручками сделать «форк», то видно не будет. Можно сделать новый репозиторий, сделать его клон, локально(пустой) добавить в него новый ремоут на дев-реп, сделать git reset --hard master на origin2/master и запушить мастер с -f в публичный реп. А потом просто пулить и пушить.

Не знаю, можно ли гитлабом сделать такое же средствами гитлаба(добавить в ремоут на серваке еще один ремоут). На сколько я помню при клоне, remote update, fetch ремоуты ремоута не закачиваются.

Dudraug ★★★★★ ()

Может есть более изящный способ такое осуществить?

Дык просто сделай отдельный remote для «публичного репозитория» и пуш туда только мастер.

no-such-file ★★★★★ ()

Решение с отдельным remote, в который копируется только ветка master, IMHO, вполне рабочее. Однако, если этот репозиторий будет не real only, то там будут pull request, issues, code review с комментариями, issues... И все это становится размазанным между двумя репозиториями.

anonymous ()
Ответ на: комментарий от anonymous

Можно ещё при этом удалить/не использовать master из рабочего репозитория. Т.е. по сути сделать публичный репозиторий основным для релизов и мержить в него всё пулл реквестами.

sergej ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.