Strona główna » Blog » Git pull bez nadpisywania plików konfiguracyjnych

Git pull bez nadpisywania plików konfiguracyjnych

Czasami można użyć Git jako proste i szybkie narzędzie do deploymentu – zespół deweloperski wystawia zmiany do repozytorium, do określonej gałęzi, a serwer produkcyjny zasysa zmiany poprzez git pull. Problem jednak w tym, że czasami zmiany te mogą nadpisywać pliki konfiguracyjne. Czasami konfiguracja nie jest scentralizowana w jednym pliku, który jest konsekwentnie ignorowany prez .gitignore, lecz z różnych przyczyn jest rozproszona po wielu plikach (np. .htaccess), które z różnych przyczyn nie powinny być niewersjonowane, aczkolwiek zwersjonowane w nich dane (np. dane dostępowe, loginy i hasła) nie powinny być inne niż czysto deweloperskie.

Można na to znaleźć różne rozwiązania. Prostym wydaje się git stash. Jest to polecenie, które aktualne zmiany w plikach (czyli różnice w stosunku do tego, co jest w repozytorium) odkłada do swojego rodzaju schowka, który zachowuje się jak sterta albo stos. Można więc składować kolejne zmiany “jedna na drugą” a później je z tego stosu zdejmować poleceniem git stash pop lub git stash apply (apply nie usuwa zmian ze stosu).

W najbardziej podstawowej wersji, gdy składujemy tylko jeden zestaw zmian, otrzymujemy więc schowek, do którego “wycinamy” zmiany i później je “wklejamy”. Możliwy jest więc taki przebieg synchronizacji plików z repozytorium, że:

  1. git stash – wycinamy pliki konfiguracyjne i składujemy w schowku;
  2. git pull – synchronizujemy wszystko z repo (pliki konfiguracyjne zostaną nadpisane);
  3. git stash pop – przywracamy pliki konfiguracyjne ze schowka,

W okolicznościach, w których chcemy szczególnie nadzorować jakie pliki zostaną nadpisane i ewentualnie manualnie rozwiązywać potencjalne konflikty, można rozpocząć od git fetch (aktualizacja bazy danych repo), przejrzeć listę zmian za pomocą git status oraz zbadać indywidualne zmiany za pomocą git diff.