Есть репозиторий с большим проектом. Нужно дать фрилансеру доступ к части этого проекта, которая находится в подкаталоге. Что-то я ищу и не вижу ни одного внятного способа это сделать.
Это вообще возможно?

Здравствуйте, CoderMonkey, Вы писали:

CM> Есть репозиторий с большим проектом. Нужно дать фрилансеру доступ к части этого проекта, которая находится в подкаталоге. Что-то я ищу и не вижу ни одного внятного способа это сделать.
CM> Это вообще возможно?

Нет, невозможно. Решение в разбиении проекта на независимые самостоятельные части из которых можно собирать полный пазл (например, через git submodules).

Здравствуйте, Anton Batenev, Вы писали:

AB>Нет, невозможно. Решение в разбиении проекта на независимые самостоятельные части из которых можно собирать полный пазл (например, через git submodules).

И так переразбивать каждый раз, когда мне надо дать кому-то доступ?

Здравствуйте, CoderMonkey, Вы писали:

CM>Есть репозиторий с большим проектом. Нужно дать фрилансеру доступ к части этого проекта, которая находится в подкаталоге. Что-то я ищу и не вижу ни одного внятного способа это сделать.
CM>Это вообще возможно?

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

Здравствуйте, CaptainFlint, Вы писали:

CF>Под доступом имеется в виду чтение или запись? Если чтение, то без разбиения, видимо, никак. Если требуется только запись запретить, то, думаю, можно решить хуками, которые будут проверять, кто куда пытается писать, и давать отлуп при необходимости.

Запись лучше пулреквестами регулировать. Не давать же возможность напрямую коммитить в мастер (или куда они там коммитят).

Здравствуйте, CaptainFlint, Вы писали:

CF>Под доступом имеется в виду чтение или запись? Если чтение, то без разбиения, видимо, никак.

Чтение. Печальненько.

Здравствуйте, CoderMonkey, Вы писали:

CM> AB>Нет, невозможно. Решение в разбиении проекта на независимые самостоятельные части из которых можно собирать полный пазл (например, через git submodules).
CM> И так переразбивать каждый раз, когда мне надо дать кому-то доступ?

Нет, один раз и дальше не объединять а поддерживать нормальную модульность. Монорепозитории — приносят на много больше проблем, чем профита.

Здравствуйте, Anton Batenev, Вы писали:

AB>Нет, один раз и дальше не объединять а поддерживать нормальную модульность. Монорепозитории — приносят на много больше проблем, чем профита.

По репозиторию на каждый подкаталог, на который, может быть, когда нибудь, понадобится дать доступ? Странные у вас представления о нормальности.

Здравствуйте, Anton Batenev, Вы писали:

AB>Нет, один раз и дальше не объединять а поддерживать нормальную модульность. Монорепозитории — приносят на много больше проблем, чем профита.

Вместо одного репозитория, в котором находится законченная сущность, делать кучу мелких проектиков? Нда, ну и кривуля этот гит.

Здравствуйте, AlexRK, Вы писали:

ARK>Вместо одного репозитория, в котором находится законченная сущность, делать кучу мелких проектиков? Нда, ну и кривуля этот гит.

Вы вот лучше подумайте, как вообще можно вести разработку внутри какой-то одной ограниченной части проекта, если она логически не обособлена в самом проекте? Запретили вы чтение большей части проекта, стянулась только разрешённая часть — ну и как это собрать-то, а? Хотя бы скомпилировать?

Здравствуйте, CoderMonkey, Вы писали:

CM> AB>Нет, один раз и дальше не объединять а поддерживать нормальную модульность. Монорепозитории — приносят на много больше проблем, чем профита.
CM> По репозиторию на каждый подкаталог, на который, может быть, когда нибудь, понадобится дать доступ? Странные у вас представления о нормальности.

Не на подкаталог, а на логический модуль. А вообще, я не вижу никакого секрета в исходниках — они никому не интересны и можно дать полный доступ например в копии, а потом смержить, если уж есть страх перед --force (который можно запретить). Хотя если не доверяешь работнику, то, возможно, с ним лучше и не иметь дел вообще, нежели так, на "пол шишечки".

Здравствуйте, Слава, Вы писали:

С>Вы вот лучше подумайте, как вообще можно вести разработку внутри какой-то одной ограниченной части проекта, если она логически не обособлена в самом проекте? Запретили вы чтение большей части проекта, стянулась только разрешённая часть — ну и как это собрать-то, а? Хотя бы скомпилировать?

Ну, она ведь может быть и обособлена. А даже если не обособлена, можно дать права на все нужные части.

Здравствуйте, AlexRK, Вы писали:

ARK> AB>Нет, один раз и дальше не объединять а поддерживать нормальную модульность. Монорепозитории — приносят на много больше проблем, чем профита.
ARK> Вместо одного репозитория, в котором находится законченная сущность, делать кучу мелких проектиков? Нда, ну и кривуля этот гит.

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

Здравствуйте, Anton Batenev, Вы писали:

AB>git разрабатывался (и продолжает) совершенно для другой модели и условий, просто кто-то всегда хочет натянуть сову на глобус.

Ага, опенсорц добровольно-принудительно.

Здравствуйте, Anton Batenev, Вы писали:

AB>Не на подкаталог, а на логический модуль.

Разделение на модули, вероятно, надо знать заранее на 10 лет вперед.

AB> А вообще, я не вижу никакого секрета в исходниках — они никому не интересны и можно дать полный доступ например в копии, а потом смержить, если уж есть страх перед --force (который можно запретить). Хотя если не доверяешь работнику, то, возможно, с ним лучше и не иметь дел вообще, нежели так, на "пол шишечки".

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

Здравствуйте, Слава, Вы писали:

С>Вы вот лучше подумайте, как вообще можно вести разработку внутри какой-то одной ограниченной части проекта, если она логически не обособлена в самом проекте?

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

Здравствуйте, CoderMonkey, Вы писали:

CF>>Под доступом имеется в виду чтение или запись? Если чтение, то без разбиения, видимо, никак.
CM>Чтение. Печальненько.
Зачем?

Здравствуйте, CoderMonkey, Вы писали:

CM>Есть репозиторий с большим проектом. Нужно дать фрилансеру доступ к части этого проекта, которая находится в подкаталоге. Что-то я ищу и не вижу ни одного внятного способа это сделать.
CM>Это вообще возможно?
Я этот вопрос тут поднимал в споре с горсткой упоротых на хайпе гита. Как о стенку горох.

Здравствуйте, CoderMonkey, Вы писали:

CM>В проекте она и так обособлена

Значит это либа. Выделение либы в отдельный подпроект вполне логично. Это естественный процесс, и знать заранее тут ничего не нужно. Если завтра эта либа начнет использоваться в нескольких продуктах, у вас уже не будет возражений против выделения.

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

Здравствуйте, CoderMonkey, Вы писали:

CM>Есть репозиторий с большим проектом. Нужно дать фрилансеру доступ к части этого проекта, которая находится в подкаталоге. Что-то я ищу и не вижу ни одного внятного способа это сделать.
CM>Это вообще возможно?

Средствами гита нет, только через заплатку в виде submodules. Гит часто путают с распределенной файловой системой, чем он не является, это, скорее, архив. Вашему фрилансеру надо выдать папку с сырцами и принимать от него результат в виде патча/патчей, которые потом приделаете через "git am".