Skip to main content

Wprowadzenie

Zanim zagłębisz się w rozwój projektu, prosimy o zapoznanie się z następującymi kwestiami:
  • Overleaf jest oficjalnie rozwijany w wewnętrznym repozytorium, a wersja społecznościowa (Community Edition) jest publikowana w overleaf/overleaf. Za synchronizację kodu między repozytorium wewnętrznym a publicznym odpowiada copybot.
  • Ayaka-notes/overleaf-pro to fork wersji społecznościowej Overleaf. Chcemy, aby ten projekt był rozwijany długoterminowo, dlatego przed wniesieniem wkładu prosimy o przestrzeganie poniższych zasad.

Zasady dotyczące commitów

  • Prosimy nie wprowadzać rozległych modyfikacji w istniejącym kodzie Overleaf. Skupiaj jak najwięcej funkcjonalności w katalogu services/web/modules. Zminimalizuje to nakład pracy przy późniejszym scalaniu i aktualizowaniu kodu.
  • Vibe coding to rzeczywiście bardzo wygodna metoda, ale łatwo może wprowadzić bałagan w projekcie i sprawić, że później stanie się on trudny w utrzymaniu, dlatego korzystaj z niego ostrożnie.
  • Prosimy nie dodawać podczas rozwoju żadnych treści związanych z tłumaczeniami; w miarę możliwości korzystaj z istniejących tłumaczeń.
  • Unikaj wprowadzania zmiennych środowiskowych, o ile nie jest to absolutnie konieczne. Jeśli są wymagane, zadbaj o to, aby były jak najbardziej spójne z tymi z Overleaf Toolkit lub docs.overleaf.com.

Zasady dotyczące gałęzi

Do rozwoju overleaf-pro używamy następujących gałęzi:
  • main: Ta gałąź służy wyłącznie do synchronizacji kodu z upstreamu, prosimy NIE commitować do niej żadnych zewnętrznych zmian. W tej gałęzi ustawiamy tagi takie jak ce-v[X.x.x], które oznaczają, że dany stan odpowiada wersji v[X.x.x] oficjalnej wersji Overleaf Community Edition. Uwaga: te tagi są niezmienne!
  • server-pro: Domyślna gałąź do codziennego rozwoju.
  • feature-X: Gałąź służąca do rozwoju konkretnej funkcji.
  • release-vX.0.0: Gałąź przeznaczona dla wydania; przed wydaniem wprowadzamy w niej poprawki typu hot-fix.

Zasady dotyczące gałęzi w Overleaf Pro

GitHub Action

GitHub Action odpowiada za automatyczne CI/CD, w tym:
  • Conocną aktualizację gałęzi main
  • Budowanie obrazu Docker do celów rozwojowych
  • Publikowanie obrazu Docker

Pytania i odpowiedzi

Najpierw pobierz obraz Docker i uruchom poniższe polecenie, aby sprawdzić etykiety tego obrazu:
bash
Następnie możesz sprawdzić, czy commit (b0d05c0) znajduje się w gałęzi master upstreamu.
To zamierzone zachowanie. Wydanie 6.0.1 jest drobnym wydaniem poprawkowym zbudowanym na bazie obrazu 6.0.0. Zmiany są nakładane poprzez łatanie istniejącego obrazu 6.0.0, a nie przez przebudowanie obrazu z nowego commitu. Dlatego hash commitu wewnątrz obrazu jest identyczny w wersjach 6.0.0 i 6.0.1.Szczegółowe informacje znajdziesz w hotfix.
Ostatnia modyfikacja 4 października 2026