Рабочий процесс Git: без сервера

Что вам нужно сделать в первую очередь, это продумать, какой рабочий процесс у вас уже есть, и настроить git для работы с ним. Как только у вас что-то есть и работает, вы можете точно настроить его. Нет необходимости устанавливать отдельный компьютер в качестве сервера. Если вы привыкли иметь центральный репозиторий, все, что вам нужно сделать, это создать голый репозиторий, к которому все стремятся. Почему не в локальной сети?

Центральное РЕПО:

mkdir foo.git
cd foo.git
git init --bare

Ваше РЕПО:

mkdir foo
cd foo
git init
// add files
git add .
git commit -m "Initial commit"
git remote add origin //path/to/central/repo/foo.git
git push origin master

Другое РЕПО:

git clone //path/to/central/repo/foo.git

Теперь любой может толкать и тянуть непосредственно из главной ветви. Этого должно быть достаточно, чтобы вы начали.

Вам не обязательно помещать копию на физический сервер где-то, но это может помочь иметь "благословенный" репозиторий где-то-сделать одного из вашей команды (возможно, на ротации) ответственным за сбор и управление изменениями людей, когда они готовы рассматриваться как окончательные. Они могут либо хранить филиал в своем обычном репозитории, либо поддерживать отдельный репозиторий в своей локальной системе для хранения основных источников.

В качестве конкретного примера рассмотрим Linux и Linus Torvalds -- нет никакого центрального хранилища, к которому все стремятся, но Линус поддерживает хранилище, которое содержит весь код, который он считает "готовым" (и так делают несколько других людей, для различных определений "готов"). Таким образом, у вас есть каноническое определение того, что такое код, и место для определения того, что такое ваши релизы.

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

Как уже упоминалось, Git отлично работает без централизованного сервера. Но хорошая причина иметь центральный сервер-это иметь "всегда включенное" место для отправки кода после завершения функции, которую другие разработчики могут извлечь, не имея доступа к вашей локальной машине.

Например, в настоящее время я работаю в команде разработчиков из 3 человек. Мы все работаем на ноутбуках. У нас может быть рабочий поток, где мы просто тянем друг у друга машины. Но если я работаю над функцией и фиксирую свои шансы после того, как все покинули офис, и я хочу, чтобы они взглянули на эту систему, они ничего не могут сделать, если мой ноутбук включен и доступен в сети. Если ребята появляются раньше меня (что они всегда делают), им приходится ждать, пока мой ноутбук не вернется в сеть.

Если я нажимаю на что-то вроде BitBucket или GitHub или просто всегда на сервере в офисе, любой из других разработчиков может просто вытащить изменения, которые я сделал, когда они будут в следующий раз онлайн.

Что для меня является главная причина иметь центральный сервер, и на самом деле это не ошибка с Git, а скорее следствие работы с ноутбуками.

Взгляните на Git для начинающих: окончательное практическое руководство

Раздел "Как настроить общий командный репозиторий?"

Git довольно хорошо работает с такого рода настройками, хотя вы захотите избежать переноса изменений в чью-то проверенную ветку ( https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F). У вас может быть ветвь интеграции, в которую вы отправляете код и объединяете изменения других людей.

Я думаю, что основная причина, по которой центральное РЕПО используется много, заключается в том, что его можно взять за каноническую основу для всех ваших код, в то время как это может быть немного сложнее рассуждать о том, что вы должны объединяться, когда у вас есть 3 или более ветвей разработки происходит.