IQhost.pl
Załóż konto
Hosting Migracja Domeny O nas Kontakt
Zaloguj się
ZARZąDZANIE HOSTINGIEM (DIRECTADMIN) • 5 MIN READ

Git Manager — repozytoria Git

Git Manager w DirectAdmin pozwala klonować repozytorium z GitHub/GitLab/Bitbucket prosto w public_html. Auto-deploy z webhooks. Konfiguracja, klucze deploy.

Zespół IQHost 14 maj 2026 5m read
#DirectAdmin #IQHost #hosting

Git Manager w DA to integracja z Git — możesz klonować repozytorium (np. z GitHub) do swojego konta i robić git pull z panelu jednym kliknięciem. Plus webhooks: auto-deploy gdy push do main.

Co zyskasz

  • Sklonujesz repozytorium z GitHub/GitLab/Bitbucket do public_html.
  • Skonfigurujesz auto-deploy (push → strona aktualna).
  • Wygenerujesz deploy key dla bezpiecznego dostępu.
  • Zarządzasz wieloma branchami.

Wymagania wstępne

  • Konto DA z Git Manager (pakiet typowo HS5+, sprawdź w pulpicie).
  • Repozytorium na GitHub/GitLab/Bitbucket.

Wskazówka

Git Manager vs SSH git:

  • Git Manager — interfejs DA, klik clone/pull/checkout
  • SSH git — pełen Git CLI (git pull, git push, git checkout), HS5+ z SSH

Oba działają. Git Manager prostszy dla webmasterów.

Krok 1: Otwórz Git Manager

Dodatkowe funkcje → Git Manager lub menu Repozytoria.

Strona Git Manager w DA na koncie host36592

Lista istniejących repozytoriów + przycisk + Utwórz repozytorium. Pełna strona Git Manager — repozytoria użytkownika

Krok 2: Utwórz nowe repozytorium

Klik + Utwórz repozytorium. Formularz:

  • Nazwa lokalna — folder gdzie sklonować (np. moja-strona)
  • Lokalizacja — gdzie w drzewie (typowo domains/mojafirma.pl/public_html)
  • URL repozytorium — pełny URL git remote
  • Branch — który branch domyślnie (zwykle main lub master)
  • Deploy key — czy wygenerować (zalecane)

Krok 3: Public vs Private repo

Public repo (np. open source na GitHub):

  • URL: https://github.com/user/repo.git
  • Klonowanie bez authentication

Private repo:

  • URL: [email protected]:user/repo.git (SSH format)
  • Wymaga deploy key — DA generuje, ty dodajesz do GitHub

Krok 4: Deploy key

DA wygeneruje publiczny klucz SSH. Skopiuj.

GitHub:

  1. Repo → Settings → Deploy keys → Add deploy key
  2. Tytuł: IQHost host36592
  3. Wklej klucz
  4. Allow write access: zwykle NIE (read-only wystarczy dla deploy)
  5. Add

GitLab:

  • Settings → Repository → Deploy Keys → Add

Bitbucket:

  • Repository settings → Access keys → Add key

Po dodaniu deploy key — wróć do DA, Clone → repo zostanie sklonowane.

Krok 5: Webhooks (auto-deploy)

Konfiguracja w GitHub Settings → Webhooks:

  • Payload URL — DA podaje (typowo https://host36592.iqhs.pl:2222/CMD_PLUGINS/git/webhook)
  • Content type — application/json
  • Secret — wygeneruj, wpisz w DA też
  • Events — Just the push event

Po każdym push do main → GitHub wysyła webhook → DA robi git pull automatycznie → strona aktualna.

Typowy workflow

  1. Develop lokalnie — edytuj kod, git commit
  2. Push do GitHub — git push origin main
  3. Auto-deploy — webhook → IQHost git pull → strona zaktualizowana
  4. Test — otwórz stronę, sprawdź zmiany

Wielobranchowy setup

Production + staging:

  • Repo 1: public_html/ — branch main
  • Repo 2: staging.mojafirma.pl/public_html/ — branch develop

Push do main → produkcja aktualna. Push do develop → staging aktualny.

Bezpieczne testowanie zmian przed wypuszczeniem.

Po pull — co jeszcze

git pull aktualizuje pliki, ale nie wykonuje:

  • composer install (Laravel, Symfony)
  • npm install && npm run build (frontend assets)
  • php artisan migrate (Laravel migrations)

Te kroki dodaj w post-receive hook albo skrypt deploy ręcznie.

Dla zaawansowanych deploy → narzędzia: Deployer, Capistrano, Envoy.

Najczęstsze problemy

1. „Clone zawiódł — permission denied"

  • Deploy key dodany? (GitHub Settings → Deploy keys)
  • Klucz publiczny dokładnie taki sam jak z DA?
  • Repo jest private a nie dodałeś deploy key

2. „Webhook nie działa — push, ale brak update"

  • Sprawdź log webhooks w GitHub (Settings → Webhooks → kliknij → Recent Deliveries)
  • Payload URL poprawny?
  • Secret się zgadza?

3. „Git pull conflict — błąd"

Ktoś edytował pliki w public_html ręcznie (przez Menedżer Plików). Git widzi konflikt.

Rozwiązanie:

  • Reset — wymuszony powrót do remote: git reset --hard origin/main (przez SSH)
  • Albo usuń lokalne zmiany, klon na nowo

4. „Mogę commitować z serwera?"

Tak (SSH) — git commit && git push. Wymaga deploy key z write access (lub osobny SSH key).

Ale anti-pattern — edycja na serwerze, nie wraca do dev. Lepiej: dev lokalnie, push, pull na serwer.

5. „Wielkie repo (1 GB) — clone bardzo wolne"

Użyj --depth=1 (shallow clone):

  • SSH: git clone --depth=1 ...
  • DA Git Manager może mieć checkbox „Shallow"

6. „Submodules — działają?"

W Git Manager DA — częściowo. Lepiej przez SSH: git submodule update --init --recursive.

7. „Mogę mieć .gitignore na serwerze?"

Tak — standardowy mechanizm Git. W repo dodaj .gitignore, push, na serwerze git pull.

Typowy .gitignore dla WordPress:

wp-content/uploads/
wp-content/cache/
wp-config.php
.htaccess

Słowniczek

  • Deploy key — klucz SSH z read-only access do konkretnego repo.
  • Webhook — HTTP request wysyłany przez GitHub gdy event (push).
  • Bare repo — repozytorium bez working directory (server-side).
  • Shallow clone — clone tylko ostatnich N commitów.

Related

Feedback

Czy ten artykuł pomógł?

Potwierdź