Używając Gita, bardzo często korzystamy (a jeśli nie, to nie wykorzystujemy w pełni jego potencjału) z modelu branchowania podobnego do tego. W modelu tym zależy nam, żeby jakoś wyróżnić gałęzie releasowe od rozwojowych. Ustalamy, że gałąź releasowa jest odbijana zawsze od mastera i jej nazwa ma następujący format:
"In theory, there is no difference between theory and practice. But, in practice, there is." Jan L. A. van de Snepscheut
wtorek, 28 stycznia 2014
Git - zarządzanie aliasami
Poznając Gita prędzej, czy później zaczynamy tworzyć własne aliasy. Z racji tego, że Git jest rozproszonym systemem kontroli wersji, to każdy może mieć lokalnie dowolny zestaw aliasów. W momencie kiedy spójność aliasów zaczyna mieć krytyczne znaczenie dla procesu continuous delivery w danej firmie, pojawia się problem jak tymi aliasami zarządzać, tak aby „zmusić” programistów do używania tych najbardziej aktualnych. Jednak zanim o tym, to może przykład jakiś aliasów, które muszą być takie same u każdego z programistów.
Używając Gita, bardzo często korzystamy (a jeśli nie, to nie wykorzystujemy w pełni jego potencjału) z modelu branchowania podobnego do tego. W modelu tym zależy nam, żeby jakoś wyróżnić gałęzie releasowe od rozwojowych. Ustalamy, że gałąź releasowa jest odbijana zawsze od mastera i jej nazwa ma następujący format:
Używając Gita, bardzo często korzystamy (a jeśli nie, to nie wykorzystujemy w pełni jego potencjału) z modelu branchowania podobnego do tego. W modelu tym zależy nam, żeby jakoś wyróżnić gałęzie releasowe od rozwojowych. Ustalamy, że gałąź releasowa jest odbijana zawsze od mastera i jej nazwa ma następujący format:
Subskrybuj:
Posty (Atom)