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

Ответ 1

Зависит от того, что вы подразумеваете под "сервером". Git будет работать без центрального сервера, хотя многим командам удобно иметь центральный репозиторий.

Если "сервер" означает "установить серверное программное обеспечение", Git также будет работать (центральный репозиторий или нет) без какого-либо специального программного обеспечения через ssh или в файловой системе.

См. этот документ для возможных рабочих процессов

Рабочий процесс с общим хранилищем

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

• Разработчик A нажимает на центральный
• Разработчик B нажимает на центральный
• Разработчик C тянет (получает изменения от A и B)
• Разработчик A тянет (получает изменения от B)
• ...

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

Рабочий процесс с электронной почтой

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

• Разработчик A отправляет изменения в виде электронной почты в команду.
• Другие разработчики применяют изменения из писем

Это можно сделать полуавтоматическим способом

Рабочий процесс без центрального сервера

Вы можете настроить Git на использование более одного репозитория "remote". Предостережение заключается в том, что вы должны никогда нажимать на репозиторий, который был выгружен (то есть экземпляр разработчика, на котором работает кто-то). Поэтому в этом случае поток будет выглядеть следующим образом:

• Разработчик A вносит изменения.
• Разработчик B вносит изменения.
• Разработчик C переносит изменения с A
• Разработчик C переносит изменения с B
• Разработчик B тянет изменения от A
• ...
• Никто не должен нажимать

IMHO этот тип рабочего процесса быстро приведет к путанице и сбоям.

Ответ 2

Сначала вам нужно подумать над тем, какой рабочий процесс уже существует, и настроить 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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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 или более ветвей развития.

Ответ 7

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

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