Jak zapisać aktualny stan strony w GitHub bez przenoszenia historii

Snapshot to aktualny stan, nie przeprowadzka historii

Repozytorium wspólne ma umożliwić dalsze utrzymanie serwisu. Potrzebne są więc pliki, z których da się zbudować i wdrożyć bieżącą stronę. Nie jest potrzebny dawny przebieg prac, każdy roboczy commit ani metadane lokalnego repozytorium.

W praktyce docelowy katalog domeny dostaje aktualne HTML-e, style, skrypty, obrazy oraz narzędzie budujące, gdy strona go używa. Jeśli generator czyta dane wejściowe, na przykład pliki treści, one także należą do snapshotu. Po stronie GitHub pojawia się jeden nowy commit opisujący stan przeniesienia.

Lokalna historia nie jest kasowana ani przepisywana. Zostaje w pierwotnym katalogu, gdzie może być nadal przydatna do pracy zespołu. Centralne repozytorium dostaje prostą, czytelną linię startową dla dalszych zmian.

Najpierw ustalamy, co jest źródłem obecnej strony

Nie wystarczy skopiować samego docrootu, gdy serwis powstaje z generatora. Wtedy kolejna drobna poprawka byłaby trudna albo przypadkowo nadpisana przy budowaniu. Warto sprawdzić, które pliki są wejściem, a które są wynikiem procesu.

• Włączamy: aktualne strony, zasoby, plik konfiguracji serwera potrzebny do routingu oraz generator i jego jawne dane wejściowe.
• Włączamy rozważnie: zależności tylko wtedy, gdy bez nich nie da się odtworzyć builda. Dla typowego projektu wystarczą manifest i lockfile, nie cały katalog roboczy narzędzia.
• Wyłączamy: katalog .git, backup starego CMS-a, bazę danych, cache, logi i pliki tymczasowe.

To rozróżnienie jest proste, ale oszczędza później wiele czasu. Repozytorium ma odtwarzać bieżącą stronę, nie archiwum wszystkich stanów, które kiedykolwiek leżały na serwerze.

Sekrety są poza snapshotem

Konfiguracja formularza, SMTP, tokeny API, prywatne klucze i pliki środowiskowe pozostają poza repozytorium. Nawet krótki test z prawdziwym sekretem nie jest dobrym pomysłem: usunięcie pliku w kolejnym commicie nie usuwa go z historii.

Reguły można utrzymać w katalogu głównym repozytorium oraz, gdy to potrzebne, przy konkretnej domenie:

# Dane dostępowe i lokalne ustawienia
config.php
send-config.php
.env
.env.*
*.pem

# Artefakty niepotrzebne do odtworzenia strony
__pycache__/
backups/
send_error.log

Bezpieczny szablon, taki jak send-config.example.php albo .env.example, można dodać tylko wtedy, gdy nie zawiera żadnej prawdziwej wartości. Powinien wyjaśniać nazwy wymaganych zmiennych, nie przechowywać ich.

Kopiujemy bieżący stan do katalogu domeny

Wspólne repozytorium jest klonowane zwyczajnie, a nowy katalog domeny wypełniamy wyłącznie plikami roboczymi. Poniższy przykład kopiuje zawartość źródła do świeżego katalogu docelowego. Przełącznik --delete ma sens tylko po uprzednim sprawdzeniu celu; usuwa nadmiarowe pliki w katalogu docelowym, nigdy w źródle.

git clone https://github.com/organization/websites.git
cd websites

SOURCE="$HOME/work/example-site.pl"
TARGET="$PWD/example-site.pl"

rsync -a --delete \
  --exclude='.git/' \
  --exclude='.env' \
  --exclude='config.php' \
  --exclude='send-config.php' \
  --exclude='*.pem' \
  --exclude='__pycache__/' \
  --exclude='backups/' \
  "$SOURCE/" "$TARGET/"

Przed właściwym kopiowaniem warto dodać do polecenia --dry-run. Wydruk pokaże plan zmian bez ich wykonywania. Przy katalogu, który nie jest świeży, to obowiązkowy etap: być może w repozytorium istnieje plik utrzymywany niezależnie od lokalnej kopii strony.

Przed commitem sprawdzamy dokładnie, co trafi do historii

Najważniejszy moment nie jest przy git push, ale przed git add. Najpierw oglądamy listę nowych plików. Potem dodajemy wyłącznie katalog domeny i oglądamy staged diff.

git status --short
git add -- example-site.pl

git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git check-ignore -v -- example-site.pl/send-config.php

Wynik git check-ignore powinien wskazać regułę ignorowania pliku konfiguracyjnego. Jeśli git status --short pokazuje backup, cache albo zaskakujący katalog, zatrzymujemy się i doprecyzowujemy wykluczenie. Nie poprawiamy tego po wysłaniu.

Do kontroli warto dołączyć test odtwarzalności: uruchomić generator lub kompilację w katalogu docelowym, zweryfikować mapę strony oraz przynajmniej otworzyć stronę główną, formularz i ważne adresy 301. Komplet plików ma działać bez korzystania z przypadkowych artefaktów pozostawionych w katalogu źródłowym.

Jeden commit, potem osobne wdrożenie

Po kontroli commit dokumentuje stan, który został przeniesiony. Opis ma mówić o domenie i snapshotcie, a nie udawać długą historię projektu.

git commit -m "example-site.pl: add current source snapshot"
git push origin main

Wysłanie zmian do GitHub nie jest wdrożeniem produkcyjnym, chyba że dla danego repozytorium wyraźnie skonfigurowano automatyczne publikowanie. W zwykłym procesie po pushu uruchamiamy właściwy dla serwisu deploy, a następnie sprawdzamy odpowiedź HTTP i widoczną wersję strony.

Taki podział jest zdrowy: repozytorium utrzymuje źródło prawdy dla kodu, a wdrożenie ma własny, kontrolowany krok. Gdy później potrzebne będzie wycofanie zmiany, wiadomo dokładnie, który commit i który zestaw plików odpowiada za daną wersję.

Krótka checklista

1. Ustalić aktualne źródła strony, generator i dane potrzebne do odtworzenia builda.
2. Nie przenosić katalogu .git, wcześniejszych commitów ani backupu poprzedniego systemu.
3. Wykluczyć konfigurację, tokeny, klucze, cache, logi i pliki tymczasowe.
4. Skopiować zawartość do katalogu domeny w repozytorium; przed --delete użyć --dry-run, gdy cel nie jest pusty.
5. Sprawdzić git status, staged diff i reguły .gitignore.
6. Wykonać build lub test lokalny z katalogu docelowego.
7. Utworzyć jeden commit aktualnego snapshotu, wysłać go i wdrożyć stronę osobnym krokiem.

W ten sposób wspólne repozytorium zaczyna od czystego, użytecznego stanu. Bez ukrytych danych, bez niepotrzebnego bagażu i bez utraty wiedzy o tym, z czego obecna strona naprawdę powstaje.