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

Question

git должен быть децентрализованной системой, но все учебные пособия и лучшие рабочие процессы, которые я нашел в google, предлагают использовать сервер (обычно github или настроить свой собственный)

Я использую gitдля небольших личных проектов (2-3 человека), где я могу найти лучший рабочий процесс для синхронизации изменений непосредственно между компьютерами членов команды.В качестве альтернативы, каковы убедительные аргументы, почему я должен избегать этого и вместо этого настроить «центральный» сервер?

Спасибо,
Бен

Answer 1

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

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

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

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

Рабочий процессмногие используют то, что все разработчики «отправляют» (отправляют) свои изменения в общий репозиторий и получают все изменения из этого репозитория.Примерно так:

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

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

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

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

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

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

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

Вы можете настроить git для использования более одного «удаленного» хранилища.Предупреждение состоит в том, что вы не должны никогда отправлять данные в извлеченный репозиторий (то есть копию разработчика, над которой кто-то работает).Таким образом, в этом случае процесс будет выглядеть следующим образом:

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

ИМХОЭтот тип рабочего процесса быстро приведет к путанице и поломке.

Answer 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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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