гітоз проти гітоліту? [зачинено]

Я шукаю встановити git-сервер для обміну проектами зі своєю командою. Я не хочу створювати обліковий запис користувача на сервері з доступом до SSH для кожного розробника, якому потрібен git доступ. Здається, є два паралельних рішення, які висвітлюють це питання: гітоз та гітоліт.

Я не міг знайти порівняння між обома рішеннями. Які основні відмінності між ними? Чи є інші подібні рішення?

Я шукаю встановити git-сервер для обміну проектами зі своєю командою.

Можна просто використовувати git.

Щоб мати git-сервер, єдине, що вам потрібно на віддаленому сервері, - це git. Якщо вам не потрібні дрібнодоступні дозволи (спільний доступ лише з вашою командою передбачає, що це можливо) або будь-які додаткові функції, вам не потрібен гітоліт чи подібні.

Рішення без встановлення

Якщо git доступний на віддаленому сервері, ви можете робити те, що просите прямо зараз, нічого не роблячи

ssh [user@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare

Місцево:

cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git push -u origin master

Налаштувати git-сервер досить просто.

Якщо ви хочете займатися із спеціальним користувачем git, документи для налаштування сервера git короткі - адже це дійсно досить просто.

Підсумовуючи:

• Встановити git
• Створіть користувача на ім'я git
• Додайте відкриті ключі свого та вашої команди до .ssh/authorized_keysфайлу користувача git
• Змініть оболонку користувача git git-shell
• Створення репостів на сервері
• почати тягнути / натискати на git@yourserver.com

Тільки різниця між використанням виділеного користувача GIT і немає, в тому , що якщо ви налаштуєте користувач мерзотник використовувати git-shellНЕ буде дозволяти собі робити що - небудь ще. Що стосується того, що він виступає як git-сервер, він ідентичний рішенню без встановлення

Основна відмінність полягає в тому, що гітоз зараз застарілий і більше активно не підтримується.

Gitolite є набагато більш повною функцією , і щойно випустив свою третю версію .

Найцікавішою його особливістю є Віртуальна довідка (короткий VREF), яка дозволяє оголосити стільки гачок оновлення, скільки вам потрібно, що дозволяє обмежити натискання на:

• dir / name file :
  Скажіть, ви не хочете, щоб молодші розробники натискали зміни на Makefile, тому що це досить складно:
  - VREF/NAME/Makefile = @junior-devs

• кількість нових файлів :
  скажіть, що ви не хочете, щоб молодші розробники надсилали більше 9 файлів за комісію, оскільки ви хочете, щоб вони мали невеликі комісії:
  - VREF/COUNT/9/NEWFILES = @junior-devs

• розширене виявлення
  файлових типів : Іноді файл має стандартне розширення (яке не може бути "gitignore'd"), але насправді генерується автоматично. Ось один із способів вирішити це:
  - VREF/FILETYPE/AUTOGENERATED = @all
  див. src/VREF/FILETETYPEДля перегляду механізму виявлення.

• перевірка авторської електронної пошти :
  Деякі люди хочуть переконатися, що "ви можете лише надіслати свої власні зобов'язання".
  - VREF/EMAIL-CHECK = @all
  Див src/VREF/EMAIL-CHECK.

• голосування по фіксацій :
  Базова реалізація голосування по фіксації на подив легко:
  - VREF/EMAIL-CHECK = @all.
  # 2 votes required to push master, but trusted devs don't have this restriction
# RW+ VREF/VOTES/2/master = @trusted-devs
# - VREF/VOTES/2/master = @devs
  Дивіться src/VREF/VOTESдля реалізації.

• і так далі...

Просто сіденот. Ви також можете використовувати Герріт для своїх потреб:

Перегляд коду Герріта

Спочатку здається, що Герріт використовується для огляду коду, але ви можете фактично використовувати його також для керування користувачами та надання їм чітко визначених дозволів. Ви можете обійти перегляд коду (через керування доступом ) і використовувати його лише для управління проектами та ssh-клавішами. Джерріт має дійсно потужний механізм контролю доступу:

Герріт Контроль доступу

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

Для ще швидшого і бруднішого рішення просто використовуйте git демон і переходьте до однолітків. Ось стаття про те, що робити саме це.

Редагувати: Я визнаю, що це не відповідає чітко на питання ОП. Я вкладаю це в основному для тих, як я, хто стикається з цим, шукаючи вниз і брудний спосіб спільного використання коду, поки не буде налаштовано обліковий запис підприємства github.

Я певний час заплутався, щоб отримати git-сервер, що працює з LDAP-доступом, дрібнозернистим контролем доступу тощо ... Знайшов одкровення: Використовуйте Gitlab :

• git сховища
• дрібнозернистий доступ (afaik gitlab використовує гітоліт під кришкою)

якщо ви хочете швидкого та швидкого способу встановлення: скористайтеся програмою для встановлення Bitnami