Czy powinienem scalić się w master, a potem z powrotem po tagowaniu?

Question

Pytanie brzmi - jak uzyskać poprawną wersję (pokazaną pod git describe) na develop po tym, jak połączyłem ją z master i otagowałem master.

Używam wspólnego rozgałęzienia git - master do produkcji. Powiedzmy git describe pokazuje 1.5 na na master, a po połączeniu z develop, master pokazuje 1.5-234-g1e894af.
Tak więc utworzę nowy znacznik z przypisami o numerze git tag -a 1.6, a tym samym git describe master, który teraz pokazuje 1.6.

ALE: git describe develop nadal pokazuje 1.5-something, co jest dziwne jak dla mnie - ma takie same jak w master zobowiązuje - dlaczego git myśli, że nadal należą do 1.5 wersja?

Nic lepszego nie przychodzi mi do głowy, więc po prostu łączę mistrza w rozwój, a potem rozwija się wersja 1.6-2-..., która jest akceptowalna, ale produkuje 1 więcej bezużytecznego commitowania i ostrzega mnie przed "scaleniem stworzonym przez rekurencję", co też uważam za nie ma sensu robić, ale jak wtedy uzyskać poprawną wersję?

Answer 1

Zważywszy git describe jest o „znalezieniu najnowszy znacznik, który jest osiągalny z commit”, wydaje się ok, że git describe na develop wrócić do master na commit której nowa 1.6 tag nie został jeszcze ustawiony.

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

Po połączeniu mistrza rozwijać

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

Jeśli inni współpracownicy nie pracują na develop, można rozważyć rebasingdevelop oddział na szczycie master, aby wrócić planowanej tag. ()

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

Answer 2

Wygląda na to, że coś jest nie tak z twoim użyciem gita. Jeśli łączenie develop do master, ale nigdy master do develop, następnie master rozchodzą się swobodnie - wszelkie zmiany dotyczące master będzie nigdy nie dostać się do develop oddziału. Dlatego twoje oświadczenie, że mają te same zatwierdzenia, jest fałszywe. Stosując schemat VonC, w

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

W Zobowiązuje Mam oznaczony „M1” i „M2” nigdy nie dostać się „rozwijać”. Jeśli nie ma takich zatwierdzeń - nie wykonujesz żadnej pracy nad mistrzem - wtedy, gdy wykonasz scalenie w master, powinno to być szybkie przewijanie do przodu; oni będzie mają te same zobowiązania następnie i wszystko będzie działać tak, jak opisałeś.

Rozwiązanie zależy oczywiście od przepływu pracy, który próbujesz osiągnąć.

• Osobiście, chciałbym w tym momencie albo usunąć i odtworzyć develop oddział począwszy od mistrza, lub szybko przesłać je do 1.6, tak, że podczas dalszej pracy nad develop masz tę strukturę:

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

  Następnie git describe uzna, że ​​jest oparty na 1.6, tak jak jest w rzeczywistości.

• Jeśli masz intencję, że develop jest ciągłą gałęzią rozwojową, a master jest od czasu do czasu odgałęzieniem "wydania", powinieneś unikać tworzenia zatwierdzeń takich jak m1 i m2; o ile to zrobisz, git describe jest dokładnie mówiąc, że coś jest inne.

Nie jestem ekspertem od używania git w zespołach, więc weź to wszystko z przymrużeniem oka.