Git dla kodu MQL5: co trafia do repozytorium i co sprawdza hook

W skrócie: w repozytorium trzymam kod i ustawienia, a nie wyniki jego działania. Skompilowane pliki, logi i dane terminala zostają poza nim. Zmiany dzielę na małe commity, a dwa błędy, które wracały mimo zasad spisanych na papierze, wyłapuje hook uruchamiany przed commitem.

Co wchodzi, a co nie

Repozytorium mojego kodu ma już ponad siedem tysięcy commitów i około stu megabajtów historii. Utrzymuje się tak dzięki plikowi z wyłączeniami. Poza repo zostają skompilowane pliki (.ex5 i .ex4), katalog z danymi wykonawczymi bota (logi, zrzuty, pliki CSV z testów), profile wykresów oraz paczki cudzych skryptów i wskaźników dostarczanych z każdą instalacją MetaTradera. Te ostatnie MetaEditor potrafi zmieniać (kodowanie, końce linii) przy samym otwarciu, a w historii wyglądałoby to jak moja robota.

W repo wchodzi kod .mq5 i .mqh, biblioteka klas, notatki, dokumentacja bota i pliki z ustawieniami. Plik binarny można odtworzyć z kodu jednym poleceniem kompilatora, więc nie ma powodu go wersjonować.

Małe commity

Przy wielopunktowej zmianie jednego bota robię jeden punkt, kompilację i jeden commit. Gdy po tygodniu wynik testu się zmienia, chcę wiedzieć, który z punktów go zmienił. Jeden wielki commit z siedmioma zmianami tego nie powie. Opis commita mówi, co dokładnie zawiera.

Tożsamość autora jest jedna, ta sama na każdym komputerze. W wyniku testu zapisuję identyfikator commita, bo wynik bez wersji kodu nie jest niczym więcej niż liczbą.

Dwa błędy, które łapie hook

Pierwszy: plik .mq5 albo .mqh zapisany w UTF-16. MetaEditor tak czasem zapisuje, a git pokazuje taki plik jako binarny, więc diff jest nieczytelny. Hook sprawdza zawartość pliku z indeksu i blokuje commit.

Drugi: numer wersji w nagłówku różni się od stałej wersji w kodzie. To ostrzeżenie, nie blokada, ale przypomina o zasadzie, że każda edycja podbija obie wartości. Dodatkowo hook zwraca uwagę na dwa inputy różniące się tylko wielkością liter, bo w MQL5 to prosta droga do pomyłki.

Sprawdzana jest wersja pliku z indeksu, nie z dysku, bo liczy się to, co wejdzie do commita, a nie to, co leży niezapisane w edytorze.

Testy: raz przed wysłaniem

Testy jednostkowe biblioteki wymagają uruchomienia terminala testowego i trwają około minuty. Kiedy odpalały się przy każdym commicie biblioteki, dziewięć małych commitów oznaczało dziewięć startów terminala. Przeniosłem je do hooka uruchamianego raz przed push i tylko wtedy, gdy wysyłane commity ruszają bibliotekę albo same testy. Jeśli terminal jest akurat zajęty Testerem, testy są pomijane, a push przechodzi.

Kilka komputerów i kilka sesji

Kod bywa zmieniany na kilku komputerach i w kilku sesjach. Przed wysłaniem robię pobranie z rebase i automatycznym odłożeniem niezacommitowanych zmian. Przy konflikcie nie nadpisuję cudzej pracy na siłę, tylko sprawdzam, co przyszło.

Checklista

.ex5, logi, dane wykonawcze i profile w pliku z wyłączeniami.
Jedna zmiana = jedna kompilacja = jeden commit.
W wyniku testu zapisany identyfikator commita.
Hook przed commitem: blokada UTF-16 i ostrzeżenie o wersji.
Testy biblioteki raz przed push, nie przy każdym commicie.
Pobranie z rebase przed wysłaniem, bez wymuszania.

Powiązane

Źródła

Brak źródeł zewnętrznych - praktyka z własnego repozytorium (stan 15.11.2026).

Ostrzeżenie: artykuł ma charakter edukacyjny i nie jest poradą inwestycyjną. Wyniki z przeszłości nie gwarantują przyszłych. Handel na rynkach finansowych wiąże się z ryzykiem utraty kapitału.