Рабочий процесс 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 Торвальдс - нет центрального репозитория, к которому все подталкивают, но Линус поддерживает репозиторий, который содержит весь код, который он считает "готовым" (и так делают несколько других людей, для разных определений "готов"). Таким образом, у вас есть каноническое определение того, что такое код, и место для определения ваших выпусков.

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

Как уже упоминалось, 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 или более ветвей разработки.