Comments 21
А теперь самое интересное. Администрирование. Как добавить пользователя в систему? Как добавить репозиторий? Как раздавать права? Как просматривать, у кого куда есть доступ? Как удалить пользователя? Как делегировать права на администрирование?
Зачем это все, когда есть готовые решения типа gitea? Администрирование таких решений проще в разы, не требуется лепить костыли для работы через вебклиент.
Судя по картинкам интерфейса 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. У вас не так разве?
Что программист накодил - то и делает.
B GitWeb есть работа с pull requests? Я слышал, что нет.
А GitLab не такой уж и тяжёлый, чтобы заморачиваться со всеми этими настройками.
Если же речь идёт о Git в чистом виде, то понятие Git server это nonsense. Весь смысл распределение системы в том и заключается в том, что нет единого сервера.
ну а в 2024 людям снова нравятся велосипеды)
вам пора идти вперёд, а то остановились на github, gitlab в своем 14м
/s
Уж простите за занудство. Но sshd_config предназначен для системы и он может измениться при обновлении системы. Для пользовательских настроек предназначена папка sshd_config.d.
В нее и нужно добавить свой .conf файл со своими настройками.
И уж из полного занудства, ставить ufw в 2024 году... Хорошо хоть не iptables. Простые правила для nftables не так ужасны в прочтении.
Я правильно понял, что при таком сетапе у нас все могут писать во все репозитарии ?
Привет. В моем случае да, но это было сделано ради упрощения. В реальности же, если брать в пример тот же GitHub, все работают по SSH через одного и того же пользователя - пользователя git, но на сервере идет проверка кому принадлежит SSH-ключ(мы его отдельно указываем в настройках GitHub) и считывает его права на чтение, запись и администрирование. То есть для каждого человека создается собственный пользователь с определенными правами, а сервер во время соединения по SSH к пользователю git ищет нужного нам пользователя с тем же ключом и использует его права. Я подумаю как это можно реализовать и может быть добавлю в статью.
P.S: Поправьте если я не прав.
Немного не так. Никаких пользователей не создается. При соединии по ключу запускается враппер, который сопоставляет ключ и репозиторий и решает, достаточно ли прав. В учебных целях можно запилить, но лучше взять готовое.
Привет. В моем случае да, но это было сделано ради упрощения.
я понимаю, но без полноценной авторизации, такой сетап чуть более чем полностью бесполезен. Ну только если вас не два человека
Настройка Git сервера с нуля