Как стать автором
Обновить

Комментарии 21

А теперь самое интересное. Администрирование. Как добавить пользователя в систему? Как добавить репозиторий? Как раздавать права? Как просматривать, у кого куда есть доступ? Как удалить пользователя? Как делегировать права на администрирование?

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

Затем, что gitea и gitlab - это не git сервер, а хостинг проектов

Если нужен git без свистелок, то нет никакого смысла ставить то, что использоваться не будет

Почему-то многие забывают, что git - это распределённая система контроля версий прежде всего, и уже потом основа для hub/lab/ea и т.д.

Судя по картинкам интерфейса GitWeb из статьи, сейчас у нас где-то 2007 год. А в качестве тикетной системы автор, видимо, используется Redmine, вместо Jira.

В 2014 году, когда есть Gitlab, Gitea, GitHub, никто подобные велосипеды из 2007 года не изобретает, т.к. изначально принято пользоваться нормальными и популярными инструментами.

Gitlab и другие инструменты в отличии от простого git+ssh+web из примера будет по производительности быстрее, да и зачем разработчикам все эти gitlab'ы с их красивым интерфейсом, когда основная работа идёт в консоли и репозиторий нужен для синхронизации кода между разработчиками и хранения этого кода. Зачем городить тяжёлые комбайны в виде того же gitlab...

Производительность, как правило, пофиг. Узкое место - программист.

основная работа идёт в консоли

Хм. Может всё же в IDE? В консоли неудобно код писать.

Зачем городить тяжёлые комбайны в виде того же gitlab..

А в чем проблема? Ну, тяжелый. Но его же на raspberry запускают.Зато даёт кучу очень удобных и полезных плюшек.

Хм. Может всё же в IDE? В консоли неудобно код писать.

Основная работа с git.

Если вся работа заключается в git pull/commit -a/push - пожалуй да . Но это не точно. А остальное.. Навигация по коммитам удобнее через gui. конфликты решать удобнее через gui.

Только всё ровно наоборот. В консоли ты вызываешь команду и знаешь, что она сделает. Что сделает гуй по нажатию на кнопку, неизвестно. А "решать конфликты", это работа с кодом, а не с гитом.

Что сделает гуй по нажатию на кнопку, неизвестно

Ох уж этот магический GUI , написанный рептилойдами... Невозможно постичь ихнюю логику.. Нажимаешь кнопку commit - получается commit. У вас не так разве?

Что программист накодил - то и делает.

Если вся работа заключается в git pull/commit -a/push - пожалуй да . (c)

Жаль, что мы так и не услышали начальника транспортного цеха что за работа в git, которая в консоли выполняется в 10 раз быстрее чем в gui. И что за GUI , неизвестно что делающее.

B GitWeb есть работа с pull requests? Я слышал, что нет.

А GitLab не такой уж и тяжёлый, чтобы заморачиваться со всеми этими настройками.

Если же речь идёт о Git в чистом виде, то понятие Git server это nonsense. Весь смысл распределение системы в том и заключается в том, что нет единого сервера.

ну а в 2024 людям снова нравятся велосипеды)

вам пора идти вперёд, а то остановились на github, gitlab в своем 14м

/s

Уж простите за занудство. Но sshd_config предназначен для системы и он может измениться при обновлении системы. Для пользовательских настроек предназначена папка sshd_config.d.
В нее и нужно добавить свой .conf файл со своими настройками.
И уж из полного занудства, ставить ufw в 2024 году... Хорошо хоть не iptables. Простые правила для nftables не так ужасны в прочтении.

первый полезный и адекватный коммент.. моё почтение.

а комментаторам выше могу порекомендовать перестать покупать мерседес ради того чтобы было где посидеть за пределами дома.

Привет, спасибо за критику. Про sshd_config.d ты прав, позже исправлю.

Я правильно понял, что при таком сетапе у нас все могут писать во все репозитарии ?

Привет. В моем случае да, но это было сделано ради упрощения. В реальности же, если брать в пример тот же GitHub, все работают по SSH через одного и того же пользователя - пользователя git, но на сервере идет проверка кому принадлежит SSH-ключ(мы его отдельно указываем в настройках GitHub) и считывает его права на чтение, запись и администрирование. То есть для каждого человека создается собственный пользователь с определенными правами, а сервер во время соединения по SSH к пользователю git ищет нужного нам пользователя с тем же ключом и использует его права. Я подумаю как это можно реализовать и может быть добавлю в статью.

P.S: Поправьте если я не прав.

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

Привет. В моем случае да, но это было сделано ради упрощения.

я понимаю, но без полноценной авторизации, такой сетап чуть более чем полностью бесполезен. Ну только если вас не два человека

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории