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 Сделки рЕПО
• Сделайте добавочный пакет из master репо (в результате один файл, легче общаться)
• отправить этот файл вместе с SHA1 master Сделки рЕПО

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

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

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