Я давно користувач Subversion, який збирається спробувати Git. Я прочитав дещо про це і зрозумів розподілену природу - я бачу багато переваг.

Однак мені подобається ідея центрального сервера, який може взяти на себе роль резервного копіювання, системи запису тощо, в той час як Git все ще використовує для свого локального розгалуження та обміну. Я не роблю проект з відкритим кодом, тому не можу користуватися Github (без оплати), тому моє запитання насправді таке: який найкращий спосіб запустити локальний сервер git?

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

Дякую!

Ви можете просто встановити ssh-сервер і запустити там центральний сховище. Тоді всі розробники просто погоджуються (як правило) напросити на сервер, коли вони роблять зобов’язання. Це схема використання на моєму робочому місці. Дуже CVS та SVN-подібний.

1. Знайдіть десь помістити сховище ( /var/gitrootнаприклад).
2. Створіть нове репо ( mkdir project.git && cd project.git && git init --bare --shared=group).
3. Потім на своєму клієнті клонуйте віддалений репо ( git clone ssh://yourserver.com/var/gitroot/project.git && cd project)
4. додати кілька файлів ( git add README)
5. фіксувати ( git commit -m "Initial import"),
6. push ( git push origin master)

Це повинно налаштувати речі.

Gitorious - це веб-інтерфейс з відкритим кодом, який може працювати на власному сервері, як github:

http://getgitorious.com/

Оновлення:

http://gitlab.org/ - це ще одна альтернатива.

Оновлення 2:

Gitorious тепер приєднався до GitLab

Спробуйте GitLab

Найкращий інструмент для використання GUI, який я коли-небудь використовував. Він дуже схожий на GitHub.

Він є відкритим кодом (Ліцензія MIT) і є найбільш встановленим програмним забезпеченням для управління git із встановленням понад 25 000. Він має щомісячні випуски та активну спільноту з понад 375 учасниками. Ви можете мати необмежену кількість приватних, внутрішніх та публічних сховищ на власному сервері. Це додаток Ruby on Rails, який працює на більшості платформ Unix.

Якщо ви не заперечуєтесь з брудним та командним рядком, gitolite - це абсолютно задоволення під час роботи у корпоративному середовищі, де потрібно встановити різні права доступу на різні сховища. Це свого роду новіша версія гітозу, згадана @Chris.

Ось резюме з веб-сайту автора:

Gitolite дозволяє використовувати одного користувача на сервері для розміщення багатьох git-сховищ та надання доступу багатьом розробникам, без необхідності надавати їм реальні користувальницькі послуги або доступ до оболонки до сервера. Найважливішою магією для цього є доступ до скриньки ssh та файл санкціонованих_кіїв, а натхненням була старіша програма під назвою gitosis.

Гітоліт може обмежувати, хто може читати (клонувати / витягувати) або писати (натискати) у сховище. Він також може обмежити того, хто може натиснути на ту галузь чи тег, що дуже важливо в корпоративному середовищі. Gitolite можна встановлювати, не вимагаючи дозволів root, і без додаткового програмного забезпечення, ніж git себе та perl.

Він має досить вичерпний набір функцій, але одне, що мені дуже подобається, - це те, що щоденне редагування конфігурації здійснюється через спеціальне сховище git Тобто додавання користувача просто

• Додати користувача у файл конфігурації
• Додайте ключ ssh користувача
• Здійсніть зміни
• Притисніть його до гітоліту
• Voila, конфігурація в прямому ефірі!

І коли потрібно переглянути код через браузер, gitolite має підтримку для "синхронізації" конфігурації з gitweb. Або якщо вам подобається cgit , який є дуже хорошим веб-інтерфейсом для git, написаного на C, краще, тоді вам слід ознайомитись із цим способом .

Ви можете розглянути Gitblit , відкритий, інтегрований, чистий сервер Java Git, переглядач та менеджер сховищ для невеликих робочих груп.

Огляд голих кісток

git instaweb --httpd=webrick

з книги git scm

комбінуйте це з чимось на зразок описаного тут підходу для розподіленої розробки (кредит для datagrok для добре описаної концепції)

Запустіть одноразовий git-сервер із будь-якого локального сховища.

Я це вже написав, але думав, що це може використати деяке розширення:

Увімкнути децентралізований робочий процес git: git config alias.serve "daemon --verbose --export-all --base-path = .git --reuseaddr --strict-paths .git /"

Скажімо, ви використовуєте git робочий процес, який передбачає роботу з основним "офіційним" сховищем, яке ви перетягуєте та висуваєте із змін і в них. Я впевнений, що багато компаній роблять це, як і багато користувачів таких служб хостингу, як Github.

Скажіть, що сервер чи Github трохи знижується.

Не хвилюйтесь, адже одна з причин використання git полягає в тому, що у вас є копія всієї історії проекту у вашому локальному клоні.

Ви можете продовжувати кодувати та виконувати записи, поки ви будете чекати, поки команда операцій поверне сервер до життя. Примітка для себе: купуйте пончики для операційної групи.

Але що робити, якщо під час цього простою ви хочете співпрацювати з іншою людиною, яка може не бути експертом з git, у тому ж сховищі?

Або замість простою, що робити, якщо ви та ваш колега в полі, і чомусь ви не можете отримати VPN, щоб дозволити вам підключитися до офіційного репо?

Або що робити, якщо ви та ваш співавтор випробовуєте купу експериментальних змін, і, хоча у вас є доступ, ви не хочете штовхати свою незакінчену безладу в офіційний центральний сховище? (Навіть не як функції гілок.) Можливо, ви в середині очищення катастрофічної бази або злиття, і гілки всюди.

Що ж, git, як ви, напевно, знаєте, - це "розподілена" система управління версіями .

Незважаючи на те, що ви можете використовувати центральне "офіційне" сховище git у своєму робочому процесі, ви все одно маєте можливість використовувати git у режимі однорангових, коли ви та ваш колега просто будуєте та ділитесь комунікаціями між собою та центральним Сервер ніколи навіть не повинен знати.

Отже, як ви отримуєте свої гілки та зобов’язуєтесь над ними, чи навпаки?

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

Напевно, можна придумати й інші методи. Але є дуже простий спосіб: якщо ви бачите один одного в мережі, ви можете запустити одноразовий сервер git, який вони можуть використовувати як віддалений для клонування, отримання та витягування змін, і вбивати їх, коли ви зроблено з ним.

Інструмент, який це дозволяє git daemon, є безліччю варіантів та функціональних можливостей, але для того, щоб зробити це легким одноразовим "просто обслуговуючи репо, в якому я перебуваю", спосіб його використання - створити псевдонім. Мені подобається це називати git serve. Виконати:

git config --global alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

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

Використовуйте нове git serveтак:

1. Біжи git serve . "Готовий до гуркоту", він повідомить. Гіт - погана дупа.
2. Дізнайтеся свою IP-адресу. Скажімо, це 192.168.1.123.
3. Скажіть: "Ей Джейн, я не готова / здатна підштовхнути ці зобов'язання до початку, але ви можете запустити мої зобов'язання у ваш клон, запустивши git fetch git://192.168.1.123/ "
4. Натисніть ctrl + c, коли ви більше не хочете подавати цю репону.

Ви також можете сказати Джейн, git clone git://192.168.1.123/ local-repo-nameякщо вона ще не має клона сховища. Або скористайтеся git pull git://192.168.1.123/ branchnameдля того, щоб зробити витяг та злиття одразу, корисно, якщо ви працюєте разом у відділенні функції.

Однак зауважте, що ви не повинні робити цього у ворожих мережах, якщо ви зберігаєте секрети у своєму сховищі, оскільки немає автентифікації. Це не рекламує його існування, але кожен, хто має сканер портів aa, може знайти його, підключити до нього і клонувати репо.

Але це не надто небезпечно, оскільки воно використовується лише для читання за замовчуванням. Уважно прочитайте сторінку git daemonчоловіка, якщо ви думаєте, що хочете включити доступ для запису. У випадку, коли ви хочете отримати зобов’язання свого співавтора, набагато безпечніше залишити його лише для читання, і попросіть співпрацівника також виконати цю команду, щоб ви могли витягнути з них.

Дотично пов'язане: на предмет одноразових серверів, якщо ви хочете тимчасово ділити купу статичних файлів через HTTP: python -m SimpleHTTPServer

Якщо вам потрібен хороший, простий сервер GIT, ніж ви повинні спробувати GitBlit. Також я використовую гітоліт, але це лише сервер, з GitBlit ви отримуєте все в одному, сервер, адміністратор, репост. менеджер ... URL: http://gitblit.com/

https://rhodecode.com - це веб-додаток з відкритим кодом для Git & Mercurial, який можна легко встановити в будь-якій операційній системі (програма встановлення включена).

RhodeCode (нова версія називається RhodeCode Enterprise) додає відсутні функції, такі як Git, як огляд коду, і це, як правило, дуже швидко та надійно.

Ви також можете встановити Indefero , це GPL-клон GoogleCode, оскільки він підтримує і Subversion, і Git, ви можете мати плавний перехід. Я автор Indefero.

Ви навіть можете встановити GitHub на свій локальний сервер (але не безкоштовно):

https://enterprise.github.com/

Це може бути не найпоширеніша настройка сервера git, але, граючи з різними макетами, інструментами, дзеркальними дзеркалами та схемами дозволів, я б сказав, що одна досить солідна альтернатива для корпоративних репозиторіїв - це Герріт , що може здатися дивним, оскільки це більше відоме як інструмент перегляду коду. Ми почали використовувати його як перегляд коду, і він повільно став нашим основним сховищем, знецінивши g3 / gitolite

• Розгортати його просто (ви в основному опускаєте .war у tomcat)
• має веб-інтерфейс для управління сховищами, групами та дозволами (або ssh cli)
• має вбудовану програму java ssh та git, тому вам більше нічого не потрібно налаштовувати
• підтримка ldap для користувачів та груп (як правило, обов'язково для компаній)
• дуже гнучка система дозволів (з групами проектів, спадкування дозволів, обмеження читання / запису / розгалуження / непереглянуті записи / тощо)
• можливості перегляду коду (якщо ви в цьому займаєтесь)
• дзеркальне відображення репо (для переміщення деяких сховищ до github чи інших загальнодоступних репо)

Крім того, його використовують у великих проектах (наприклад, андроїд, хром), тому він має масштаби і зараз досить міцний. Просто дайте своїм користувачам дозвіл PUSH, якщо ви хочете дозволити обхід частини огляду коду.

Для віддаленого хостингу Як уже говорили інші, bitbucket.org пропонує безкоштовні приватні сховища, я ним користувався без проблем.

Для локальної чи локальної мережі я додам цей scm-manager.org (Один виконуваний файл, дуже просто встановити, він зроблений на Java, щоб він міг працювати в Linux або Windows). Про всяк випадок, коли ви встановите це, це паролі за замовчуванням.

Username: scmadmin
Password: scmadmin

Тим часом, Mercurial хостинг-сайт Bitbucket також почав пропонувати Git-сховища.

Тож якщо вам не потрібен місцевий сервер, а лише якесь центральне місце, де ви можете безкоштовно розміщувати приватні сховища Git, IMO Bitbucket - найкращий вибір.

Безкоштовно ви отримуєте необмежені приватні та громадські сховища Git та Mercurial.
Єдине обмеження полягає в тому, що у вільному плані не більше п'яти користувачів можуть отримати доступ до ваших приватних сховищ (за більше, вам доведеться платити).
Дивіться https://bitbucket.org/plans для отримання додаткової інформації!

Якщо ви хочете витягнути запити, є проекти з відкритим кодом RhodeCode та GitLab та платний приклад

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

Якщо ви хочете "справжній" веб-сайт на вашому локальному сервері, я знаю веб-сайт Git хостингу http://repo.or.cz .
Здається, має менше функцій, ніж GitHub, але на відміну від GitHub, ви можете отримати вихідний код і розмістити його на власному локальному сервері.

Відмова: Я читав лише про repo.or.cz, я сам ніколи не пробував цього!

для простих налаштувань ви можете надати ssh доступ до центрального сервера та налаштувати робочий каталог кожного користувача, щоб натиснути / витягнути з цього "джерела". Це було б найпростішим і поширеним налаштуванням для невеликих команд.

Ви також можете заглянути в гітоз, який дає вам http-сервер і можливість керувати ним дистанційно. Таким чином, вам не потрібно надавати доступ до ssh та всього, що пов'язано з кожним виконавцем.

Щоб додати те, що сказав Кріс, ви можете використовувати gitosis (http://eagain.net/gitweb/?p=gitosis.git), щоб контролювати, хто насправді може отримати доступ до репо.

Залежно від вашого використання, ви також можете використовувати гачки (у папці .git / hooks), щоб ваш код автоматично перетягувався у файлову систему сервера при натисканні з локальної машини. Ось популярний сценарій для цього: http://utsl.gen.nz/git/post-update . Однак це не буде потрібно у всіх випадках.

http://repo.or.cz , хоча досить добре, як правило, є проблеми з деякими користувачами.

Якщо ви один із них, рекомендую спробувати http://unfuddle.com оскільки ви походили з підривної програми.

Перевірте " 30-й другий тур ": http://unfuddle.com/about/tour/plans

http://code.google.com/p/luna-tool/ - це програма Scala, яка реалізує більшість потрібних мені частин github