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

Question

Это повторяющийся вопрос для меня, но я хотел бы повторить.

Быстро объясните мою ситуацию: я нахожусь в среде, где у меня нет git-серверани общего раздела, ни какой-либо общей точки среди кодировщиков.Не иметь, не иметь, не может иметь.Период.

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

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

• Ветви: marster и yours
• master - это синхронизацияветвь, которая будет держать вас в курсе и отслеживать, что другие разработчики все еще не имеют вашего кода.
• yours будет вашим новым мастером, и именно там должен быть ваш окончательный код.Вы не работаете в master.
• каждый отправляет патчи в список обсуждений.
• Я считаю, что очень редко два человека будут работать в одном файле.

В рабочем процессе есть два основных действия:

Создание исправлений:

1. Получено yours
2. Создание патчей из master (git format-patch master)
3. Переход к master
4. Объединение yours в master
5. > Перейдите к yours, продолжайте работу с yours

Примените патчи:

1. Перейдите к master ответвление
2. Применение полученных исправлений
3. Переход к yours ответвлению
4. Объединение master в yours
5. > Продолжить работу с yours

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

Не то, чтобы ветка yours была только вотслеживание того, что есть у других людей или нет.

Есть несколько проблем, которые япытаюсь понять, будет ли слишком много хлопот:

• Порядок применения патчей?
• Как избежать и обнаружить, когда кто-то пропустит патч?
• Какмного проблем может быть, когда кто-то пропустит патч?
• Другие проблемы, которые могут возникнуть, я даже не задумывался?

Спасибо!

Answer 1

Вместо одного репо с двумя ветками я предпочел бы два репо:

• один только с master веткой в ​​нем
• один (клонирован с первого) с master и yours

Таким образом, я могу:

• объединить то, что мне нужно, от yours филиала до master в репо 'yours'
• извлекает изменения из ветви master репо yours в ветку master репо master 1024 *
• Создайте инкрементный пакет из репо master (в результате получается один файл, который легче общаться)
• отправьте этот файл по почте вместе с SHA1 репо master 1034 *

На приемном конце я бы:

• вытащить из связки в master репо
• проверьте его SHA1 (таким образом, я уверен, что я ничего не пропустил)
• вытяните ветку master из репо master в ветку master репо "ваш"
• объедините то, что мне нужно, из ветви master в ветку yours.

Идея иметь два отдельных репо состоит в том, чтобы иметь один с SHA1, который можно проверить на принимающей стороне: он должен быть одинаковым на обоих сайтах.