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

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

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

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

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

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

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

Создать исправления:

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

Применить исправления:

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

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

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

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

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

Спасибо!


git git-workflow git-patch
person filippo    schedule 11.07.2011    source источник
comment
я думаю, было бы намного проще настроить сервер git, доступный всем членам вашей команды. afaik format-patch/am будет генерировать уникальные хэши коммитов для каждого репозитория (другой коммиттер). поэтому, даже если деревья в вашем репозитории одинаковы и история в основном одинакова, слияние/сравнение и обсуждение конкретного коммита будет питой (потому что у всех разные коммиты, которые просто оценивают одни и те же патчи). Избавьте себя от хлопот и настройте сервер или создайте учетные записи на одном из множества хостинговых сайтов (github, gitourious и т. д.) — они также предлагают частные репозитории.   -  person knittl    schedule 11.07.2011
comment
чувак.. Я знаю, что это было бы лучше всего. Но прямо сейчас, как я уже сказал, я не могу (действительно не могу) и, честно говоря, как бы не хочу - просто для того, чтобы попытаться найти способ :)   -  person filippo    schedule 11.07.2011
comment
почему ты не можешь? если ваш проект с открытым исходным кодом, вы получаете даже бесплатные аккаунты на вышеупомянутых сайтах (плюс repo.or.cz). для мозговой пищи: вы смотрели на git bundle?   -  person knittl    schedule 11.07.2011
comment
Экологические и корпоративные вопросы. Объяснение в комментариях здесь: #6217273" title="синхронизация репозиториев без возможности отправки и получения коммитов">stackoverflow.com/questions/6217187/ , И нет, никогда не использовал git bundle, посмотрю! благодаря.   -  person filippo    schedule 11.07.2011

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

На принимающей стороне я бы:

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

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

person VonC    schedule 11.07.2011
comment
Итак, допустим, мы трое работаем вместе, мы все немного поработали и отправили наши пакеты в список рассылки. Когда мы придем утром, каждому из нас будет по два пакета. Так мы все делаем: тянем с одного, тянем с другого, все в master0. Вытащите из master0 в masterMine. Вы говорите об этом, все masterMine (трое из них) должны иметь одинаковые состояния файлов (таким образом, один и тот же SHA1), независимо от последовательности, в которой мы делали извлечения? (конечно, мы не узнаем окончательный SHA1, пока не закончим, но вы поняли..) - person filippo; 11.07.2011
comment
@filipo: что касается SHA1, я говорил о master0, а не masterMine (включая ветку yours, содержание которой может сильно различаться). Но даже для репозитория master0... судя по этому ответу, нет. stackoverflow.com /questions/5632520/: родитель коммитов будет отличаться от репозитория master0 к репозиторию master0. - person VonC; 11.07.2011
comment
@filipo: та же схема SHA1 может работать с коммитами, применяемыми в том же порядке (что можно сделать с помощью rebase --interactive и хорошего соглашения об именах в комментариях к указанным коммитам, чтобы изменить порядок того, что вы только что вытащили). ). Но это не тривиальное решение. - person VonC; 11.07.2011