Должен ли я использовать Git Merge Develop в Master и затем вернуться после пометки? - PullRequest
Новая
       6

Должен ли я использовать Git Merge Develop в Master и затем вернуться после пометки?

7 голосов
/ 05 февраля 2012

Вопрос: как мне получить правильную версию (показанную с git describe) на develop после того, как я слил ее в master и пометил master?

Я использую обычное ветвление git -master для производства.Допустим, git describe показывает 1.5 на master, и после слияния с develop, master показывает 1.5-234-g1e894af.
Итак, я создаю новый аннотированный тег с git tag -a 1.6 и, таким образом, git describe master теперь показывает1.6.

НО: git describe develop все еще показывает 1.5-something, что странно для меня - у него те же коммиты, что и в master - почему Git считает, что он все еще принадлежит 1.5 версии?

Ничто лучше не приходит в мой мозг, поэтому я просто объединяю master с development, и после этого развертка показывает версию 1.6-2-..., которая является приемлемой, но производит еще 1 бесполезный коммит слияния и предупреждает меня о слиянии, выполненном рекурсивно«что я тоже считаю бессмысленным делать, но как тогда добиться правильной версии?

Ответы [ 2 ]

3 голосов
/ 06 февраля 2012

Похоже, что-то не так с вашим использованием git. Если вы объединяете develop в master, но никогда не master в develop, тогда master может свободно расходиться - любые изменения master не будут никогда не попадут в ветку develop . Поэтому ваше утверждение, что они имеют одинаковые коммиты, является ложным. Используя диаграмму VonC, 

m(1.5)--m1--m2--m(1.6, master)
 \              / 
  d-------d----d (develop)

Коммиты, которые я обозначил "m1" и "m2", никогда не попадут на "развернуть". Если таких коммитов нет - вы не работаете с мастером - тогда, когда вы делаете слияние из развития в мастера, это должно быть слияние с ускорением; тогда они будут иметь такие же коммиты, и все будет работать так, как вы описали.

Конечно, решение зависит от рабочего процесса, которого вы пытаетесь достичь.

  • Лично я бы на этом этапе либо удалил и пересоздал ветку develop, начиная с мастера, либо перемотав ее вперед до 1.6, чтобы при продолжении работы с develop у вас была эта структура : 

    m(1.5)--m1--m2---m(1.6, master)
 \              / \ 
  d-------d----d   d--d (develop)

    Тогда git describe будет считать, что оно основано на 1.6, как на самом деле.

  • Если вы намереваетесь, что develop - это ветвь непрерывной разработки, а master - это ветвь периодического "выпуска", тогда вам следует избегать создания любых коммитов, таких как m1 и m2; насколько вы знаете, git describe - это , точно говорящий вам, что что-то отличается .

Я не эксперт по использованию git в командах, поэтому возьмите все это с крошкой соли.

1 голос
/ 05 февраля 2012

Учитывая, что git describe относится к «поиску самого последнего тега, доступного из коммита», вполне нормально, что git describe в develop вернется к master при коммите где ваш новый тег 1.6 еще не установлен. 

m(1.5)--m--m--m(1.6, master)
 \            / 
  d-------d--d (develop)          => git describe develop will return 1.5-xxx

После объединения мастера в разработку 

m(1.5)--m--m--m(1.6, master)
 \            / \
  d-------d--d---d (develop)      => git describe develop will return 1.6-xxx

Если другие участники не работают над develop, вы можете рассмотреть возможность перебазировать ветку develop поверх master, чтобы вернуть ожидаемый тег. ( git rebase ) 

m(1.5)--m--m--m(1.6, master)
               \            
                d--d--d (develop) => git describe develop will return 1.6-xxx
...