Narzędzia

Automatyzacja (częściowa) merga w git

Jako częściowo DevOps guy w firmie jestem odpowiedzialny za przenoszenie kodu pomiędzy gałęziami. Osobiście używałbym czystego GitFlow. My niestety jedynie oparliśmy naszą infrastrukturę o pomysł gałęzi masters i releases. Przy czym gałęzi master nie mamy jednej a wiele, i wielokrotnie więcej gałęzi releases. Dzięki temu potrafimy prowadzić pracę nad nawet kilkoma wersjami na raz (sic!). Niestety na razie nasza aplikacja jest wielkim monolitem tradycyjnie wydawanym z instalatorem wszystkiego. Mam nadzieję, że kiedyś przejdziemy do serwisów lub podobnego rozwiązania rozproszonego.

Żeby ułatwić sobie życie przygotowałem krótki skrypcik w bashu w celu nie łamania zasady DRY:

W razie konfliktów git jest na tyle “mądry” (albo raczej jego twórcy), że nie wykona żadnej kolejnej czynności póki nie rozwiążemy konfliktu. Oczywiście skrypt na razie jest prosty, na pewno będzie rozbudowywany. Niestety w razie konfliktów należy je rozwiązać i wykonać skrypt ponownie.

 

Pierwsza linijka wskazuje systemowi, że to plik wykonywalny (trzeba jeszcze ustawić chmod na możliwość wykonywania pliku dla danego użytkownika).

 

Tu zapamiętujemy gałąź na której jesteśmy. Jest to wyciągnięcie linijki która zawiera * z listy wszystkich lokalnych gałęzi wraz z tej gwiazdki usunięciem za pomocą tr.

 

Kolejne linijki to kolejno przełączenie się na gałąź, ściągnięcie zmian i ewentualnie merge gałęzi pobranej linijkę wyżej. Merge wykonywany bez wrzucenia zmian pod automatycznie nadaną nazwą (–no-commit) i nadanie własnej nazwy.

 

Ostatnie 2 linijki to wysłanie zmian na serwer oraz powrót do poprzednio używanej gałęzi.

 

Swoją droga basha warto się uczyć, albo chociaż Power Shella (tego nie lubię). Ilość narzędzi i możliwości dostępnych pod konsolą jest niesamowita. Do tego ich personalizacja, pisanie swoich, a ich działania łączenie w pipe… Używacie takich narzędzi? Czy staracie się wszystko mieć w VS i tylko stamtąd widzieć świat?

2 thoughts on “Automatyzacja (częściowa) merga w git”

  1. Jak masz pomysł na wdrożenie GitFlow przy równolegle prowadzonych wydaniach to się podziel. masters i releases są jedynie logiczną konsekwencją tego założenia.

    GitFlow takich rzeczy nie wspomaga (słusznie pewnie uznali za zbyt duży hardcore). Mnie jednak dużo bardziej przeraża tendencja do równolegle prowadzonych hotfix’ów (co już jest mega hardcore’m).

    1. Jestem przeciwny wydawaniu programu w ten sposób. Po prostu. Skupiać się powinniśmy na 1 wersji na raz. Z innej strony, skoro nie możemy to podzielmy program na takie kawałki, żeby te kawałki miały swoje wydania w odpowiednim czasie.
      Wiem, że wielu z tych rzeczy nie możemy teraz, bo “jest tak jak jest”, ale mam nadzieję, że zgadzasz się ze mną, że tak być nie powinno?

Leave a Reply

Your email address will not be published. Required fields are marked *