Mam gałąź feature
i gałąź (dla początkowej regresji). Chciałbym mieć kopię roboczą dostępną dla mojego oddziału testing
dla środowiska testowego. Jednak potrzebuję skompresować część kodu źródłowego (nie do binarnego, po prostu optymalizować) za pomocą skryptu. Mogę wprowadzić ten skrypt za pomocą haka Git po otrzymaniu.Jak poprawnie używać skryptów CI z hakami Git do kompresji źródła
Próbuję zaprojektować mój skrypt bash (dla CI), aby był dość solidny i chciał uniknąć automatyzacji powodując konflikty Git. Zastanawiam się nad posiadaniem repozytorium głównego (origin
) i repozytorium środowiska testowego (ci_test
), aby zezwolić CI na zatwierdzenie.
Zastanawiam się nad popychaniem do ci_test/testing
podczas promowania źródła. CI powinien kompresować, dodawać, zatwierdzać, pobierać od origin/testing
, scalać w razie potrzeby (przyjmując ich pełne konflikty iff), a następnie naciskać na origin/testing
.
Problem z powyższym modelem jest taki, że Git uskarża się, gdy próbuję przesłać do ci_test/testing
, ponieważ ma kopię roboczą (ma to sens, ponieważ może nie być zsynchronizowana). Czy istnieje odpowiedni (zautomatyzowany) sposób korzystania ze skryptów Continuous Integration z Git, aby nadal były śledzone?
[Push-to-checkout] (https://git-scm.com/docs/githooks#_push_to_checkout) wygląda obiecująco. Nie wiedziałem o istnieniu tego haka. Powodem, dla którego chciałem, aby ci_test miał kopię roboczą, jest to, że haczyk modyfikuje źródło i chcę dokonać zmian (nie wyobrażam sobie, że mogę to zrobić bez kopii roboczej). Używam również kopii roboczej jako katalogu, który jest używany do czytania wersji testowej aplikacji. – BLaZuRE
@BLaZuRE tak, w twoim przypadku wypychanie do wypłaty wydaje się być dobrym rozwiązaniem. – VonC