Git рабочий процесс, когда вы не можете толкать или тянуть - PullRequest
4 голосов
/ 11 июля 2011

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

Быстро объясните мою ситуацию: я нахожусь в среде, где у меня нет 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 была только вотслеживание того, что есть у других людей или нет.

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

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

Спасибо!

1 Ответ

2 голосов
/ 11 июля 2011

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

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

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

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

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

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

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

...