Мы давно используем SVN, и основная причина в том, что он позволяет нам ограничить доступ к разным веткам репозитория для разных разработчиков (через файл authz).
SVN прост для понимания, и все, что нам нужно, — это несколько команд, которые хорошо служили нам на протяжении многих лет.
Но я часто задаюсь вопросом, является ли это случаем «игнорирование — это блаженство», что мы не перешли на GIT, когда весь мир, кажется, делает именно это.
ОТРЕДАКТИРОВАНО: Основываясь на многих комментариях, и особенно на комментарии IMSoP, возникает простой вопрос: существует ли эквивалент функциональности аутентификации SVN. На самом деле, мой первоначальный запрос был запутанным, поскольку он касался ветвей. Я смотрю на то, чтобы ограничить доступ к определенным папкам в репозитории только определенным пользователям, что возможно в SVN через файл конфигурации authz.
Итак, для тех, кто не в курсе SVN, вот пример файла authz:
[repo1:/]
user1 = rw
[repo1:/folder1]
user2 = rw
user3 = r
[repo1:/folder2]
user3 = rw
Таким образом, в то время как пользователь 1 имеет полный доступ ко всему репозиторию, пользователи 2 и 3 имеют доступ только к определенным папкам. Тип доступа также можно контролировать как чтение или чтение-запись. Можно ли это сделать в Git?
Я очень извиняюсь за использованный первоначальный язык, который, как указано, был запутанным. Может ли Git поддерживать вышеуказанную функциональность?
Единственный способ, которым я могу придумать ограничение доступа разработчиков к веткам, — это создать несколько пультов для одного и того же репозитория. Таким образом, кто-то сможет работать над веткой с «ограниченным происхождением», доступ к которой есть только у нескольких разработчиков.
Однако рано или поздно его нужно будет переместить в нормальное происхождение, поскольку его необходимо объединить.
Если вы заботитесь только об ограничении совершения коммитов (или, скорее, отправки) в ветку, то эта функция поддерживается большинством служб хостинга git.
Боюсь, я не могу сильно помочь в сравнении SVN и git, просто прошло много времени с тех пор, как я последний раз использовал SVN.
Как отмечает IMSoP в комментарии, на поставленный вопрос нельзя ответить, но встроенный вопрос может:
В: Есть ли в Git способ запретить людям читать определенные зафиксированные файлы с помощью какого-то механизма контроля доступа? О: Нет.
Это все, что вам нужно на данный момент: возможности просто не существует — не в Git в том виде, в каком она реализована, а дизайн Git делает ее чрезвычайно сложной для достижения на других уровнях, поэтому вы обычно не найдете ее на большинстве хостингов Git. услуги же. Если вы найдете какую-либо услугу хостинга, которая утверждает, что предлагает ее, будьте подозрительны, что их претензии в лучшем случае преувеличены и что есть способы обойти это. Это не гарантируется, но у них должен быть совершенно не ориентированный на Git способ добраться до вещей, чтобы обеспечить надлежащую герметичность.
Есть сопутствующий вопрос:
В: Существуют ли ветки в Git на самом деле?
A: Нет, во всяком случае, не тот, который вы имеете в виду под SVN.
Ветки SVN имеют для них реальное содержание. (Это то, что делает их несколько дорогими в создании по сравнению со сверхдешевой «ветвью» Git, которая стоит всего несколько байтов.) Понятие «ветви» в Git сильно отличается. Есть полностью эфемерные аналоги, которые никуда вас не приведут, потому что они эфемерны, и вещи, которые Git также называет ветвями, которые не связаны с тем, о чем вы думаете, которые никуда вас не приведут, потому что они не связаны.
Можно ли [управление доступом в стиле authz] сделать в Git?
Нет. Git внутри представляет собой файловую систему с адресацией по содержимому, на которую наложен контроль версий. Для доступа к содержимому Git не использует имя пути, поэтому контроль доступа на основе имени пути буквально невозможен. Если вы знакомы с файловыми системами на основе «inode» в стиле Unix, Git работает так, что вы представляете номер inode и получаете содержимое. Вы можете просто просмотреть каждый индексный дескриптор и прочитать каждую часть содержимого, даже если по какой-то причине вы не можете открыть что-либо по пути.