„Kurs Arduino Dla Początkujących + Pakiet Sprzętu” został dodany do koszyka. Zobacz koszyk

Kurs Git dla Embedded

Name: Kurs Git dla Embedded - Sklep msalamon
SKU: KURS_GIT
Price: 299.00 PLN
Availability: InStock

Pracuj z gitem tak, jak pracują zespoły programistyczne — ćwiczone na prawdziwym projekcie mikrokontrolera. Od pierwszego commita po pull request i release z plikiem firmware’u. 14 lekcji wideo, 4 godziny 10 minut — dostępne od razu, w całości i na zawsze. Płytka nie jest potrzebna.

klientów kupiło ten produkt

299,00 zł z VAT

Cena netto: 243,09 zł

Korzyści

30 dni na zwrot
Od 400zł wysyłka gratis
Wysyłka z Polski w 24h
Wsparcie inżyniera

Pytanie do produktu

Dodaj do Schowka

Kursy Online

STM32 dla Początkujących
STM32 dla Początkujących + Sprzęt
Język C dla Mikrokontrolerów
FreeRTOS na STM32
STM32 Na Rejestrach
STM32 Na Rejestrach + Sprzęt
Git dla Embedded
Arduino dla Początkujących
Ebook 10 Projektów Arduino

Płatność & Wysyłka

SKU: KURS_GIT Kategoria: Kursy Tag: TOP

Produkt wykluczony z promocji kuponów rabatowych

🖥️ Kurs Git dla Embedded

Dla programistów embedded, którzy chcą pracować z gitem tak, jak pracują zespoły programistyczne — i przestać kopiować katalogi.

„Wczoraj działało, dziś nie działa.” Na dysku katalogi projekt, projekt_kopia, projekt_final_v3. A klient pyta o urządzenie sprzed pół roku i nikt nie wie, który z tych katalogów ma wgrany.

Ten kurs uczy pracy z gitem tak, jak pracują zespoły programistyczne: z czytelną historią, powrotem do każdego release’u i zmianami, które przechodzą code review, zanim trafią do kodu produkcyjnego. 14 lekcji wideo, 4 godziny 10 minut, dostęp dożywotni. Płytka nie jest potrzebna — wystarczy dowolny Twój projekt.

14 lekcji

wideo, krok po kroku

4 h 10 min

konkretnie, bez dygresji

dostęp dożywotni

od razu po zakupie

▶

🎬 Zobacz, o co chodzi w kursie

Kilka minut o tym, jak wygląda porządna praca z gitem w projekcie embedded — i co dokładnie jest w kursie.

😩 Znasz gita. Mniej więcej.

Większość z nas łapie gita z doskoku. Kilka komend na pamięć, reszta „jakoś to będzie”. I przez długi czas to działa. Aż do dnia, w którym:

❌ wczoraj działało, dziś nie działa — i nie masz pojęcia, co zmieniłeś,
❌ na dysku masz projekt, projekt_kopia, projekt_final i projekt_final_v3_NIE_RUSZAC,
❌ klient dzwoni w sprawie urządzenia sprzed pół roku, a Ty nie wiesz, która wersja jest u niego wgrana,
❌ asystent AI poprawił kilkanaście miejsc w trzech plikach i nie wiesz, które z nich chcesz zostawić,
❌ git wypisuje coś na czerwono, więc kopiujesz katalog i zaczynasz od nowa,
❌ zaczynasz pierwszą pracę, a zespół zakłada, że gita już znasz — nikt Cię go na wejściu nie będzie uczył.

👉 Problem nie siedzi w komendach. Komendę znajdziesz w pięć sekund.
👉 Siedzi w sposobie pracy — i tego żaden tutorial z pojedynczą komendą Cię nie nauczy.

🔧 Git w embedded — w czym jest inny

Git jest ten sam. Projekt — nie do końca. Uczciwie: większość pracy z gitem wygląda tak samo w każdej branży. Ale projekt embedded ma kilka rzeczy, o które inni się nie potykają:

🔹 Ponad dwieście plików w świeżym projekcie z CubeMX. Część to Twój kod, część wygenerował CubeMX, część to biblioteki producenta, a część to śmieci po kompilacji, które zmieniają się przy każdym buildzie. Co z tego ma trafić do repozytorium?
🔹 Generator kodu. Przegenerujesz projekt, a CubeMX nadpisze Ci pliki. Bez gita nie wrócisz do tego, co było.
🔹 Firmware żyje na urządzeniach. W webie wdrażasz nową wersję i po sprawie. U nas stara wersja siedzi u klienta w szafie latami — i musisz umieć do niej wrócić, dokładnie do niej.
🔹 Kod pod NDA. Nie każde repozytorium może trafić na cudzy serwer.

Część z tych rzeczy da się wywnioskować samemu. W kursie widzisz je jednak na prawdziwym projekcie wygenerowanym w CubeMX — z przykładami, dzięki którym od razu widać, czego do repozytorium nie wrzucamy i dlaczego.

Jedna rzecz, żeby było jasne od początku: gita ćwiczymy na projekcie STM32, bo na prawdziwym projekcie widać, jak git się zachowuje. Ale to kurs gita, nie programowania STM32 — zmiany w kodzie są drobne i czasem niezbyt sensowne, bo mają dać gitowi materiał do pracy.

📚 Co zyskasz, dołączając do kursu?

„Co ja zmieniłem od piątku?”

widzisz dokładnie te linie, które się zmieniły, z opisem, który po pół roku dalej coś mówi.

Klient z wersją sprzed pół roku

każdy release ma swój tag, a Ty w kilka sekund masz na dysku dokładnie ten kod, który jest u niego.

„Wczoraj działało”

cofasz się do wersji, która działała, sprawdzasz i wracasz. Zakomentowane stare funkcje w main.c możesz wreszcie skasować.

Release’y są nietykalne

rdzeń firmware’u, czyli kolejne release’y, zostaje nietknięty, a każdy nowy feature piszesz obok. Jutro prezentacja, a Ty w połowie przepisywania sterownika? Wgrywasz ostatni release i śpisz spokojnie. Nieprzetestowane nie trafia do kodu produkcyjnego.

Koniec z kodem wysyłanym mailem i ZIP-em

w zespole tak się nie pracuje, bo po tygodniu nikt nie wie, kto co komu wysłał i kto ma które pliki. Jedynym źródłem prawdy jest repozytorium, do którego wszyscy się synchronizują i z którego wszyscy korzystają.

Wiesz, co zmienił kolega

bez pytania, proszenia i przypominania. Wszystko jest na serwerze, a Ty widzisz to przy najbliższej synchronizacji.

Wszyscy grają według tych samych zasad

wiesz, jak wysyłać swoje zmiany i jak pobierać cudze, a reszta zespołu robi dokładnie to samo.

Zmiany od AI pod kontrolą

każdą widzisz czarno na białym i cofasz te, których nie chcesz.

Pięć roboczych commitów → jeden porządny

tak się pracuje naprawdę, tylko nikt tego nie pokazuje. Oryginał zostaje nietknięty obok.

Pull request i code review

kolega zostawia komentarz przy konkretnej linii, poprawiasz, zatwierdza.

Pierwszy tydzień w nowej pracy

„zrób brancha, wystaw PR-a, ktoś Ci zrobi review”. I wiesz, o co chodzi.

🗺️ Jak wygląda Twoja droga w kursie?

Trzy etapy — od pustego katalogu do release’u.

1. Praca lokalna

Instalacja i repozytorium na projekcie z CubeIDE. Przede wszystkim jednak jak się zachowywać przy wprowadzaniu zmian: jak je dokumentować, jak pisać opis commita, który coś mówi po pół roku, jak wprowadzać zmiany małymi krokami i jak nie wpuścić do repozytorium tego, co nie ma do niego trafić. Do tego cała lekcja o tym, jak wyjść z typowych wpadek — od cofnięcia niezapisanej zmiany po powrót do wersji firmware’u, która działała.

2. Sposób pracy

Model zbliżony do Git Flow, z pewnymi uproszczeniami. Branche i konflikty — skąd się biorą i jak z nich wyjść, gdy git je zgłosi. Rebase i squash, czyli jak przygotować porządną zmianę do code review: pięć roboczych commitów zamienionych w jeden, a debugowe printfy w stylu „dupa1″, „dupa2″ zostają za drzwiami — nie wchodzą do kodu. I zasady, dzięki którym w zespole branch z release’ami zawsze działa.

3. Zdalne repozytorium

Zdalne repozytorium to podstawa pracy zespołowej — i tego, jak się wobec niego zachowywać. Wstęp do GitHuba od podstaw: zakładanie repozytorium, praca z nim, wysyłanie i pobieranie zmian. Zobaczysz też, jak zdalne repozytorium wygląda u Ciebie lokalnie, w gicie. Do tego co wolno wysłać na serwer, a czego nigdy, pull request od początku do końca i release z plikiem firmware’u do pobrania.

👉 To jest cała droga jednej zmiany: od pomysłu do release’u. Dokładnie to, co będziesz robić w zespole.

🎯 To nie jest encyklopedia gita

Git ma setki komend i opcji, a większości z nich przez lata pracy nie użyjesz. Ten kurs to podstawa pracy z gitem w życiu zawodowym — wybrana na podstawie tego, czego sam używam na co dzień w projektach embedded.

To kompletna ścieżka od początku do końca — cała pętla pracy z gitem, którą potem możesz dowolnie dopasować do siebie. A jeśli trafisz do zespołu, który korzysta z gita trochę inaczej, i tak będziesz wiedział, jak się zachować: rdzeń pracy z gitem jest wszędzie ten sam, a różnice załapiesz od razu.

Tematy zaawansowane, takie jak szukanie błędu w historii, podmoduły, kilka katalogów roboczych jednego repozytorium czy automatyczne budowanie na serwerze, pojawiają się na koniec jako mapa dalszej drogi, a nie jako materiał kursu. Gdy będą Ci potrzebne, doczytasz je bez trudu, bo będziesz już rozumieć, jak git działa pod spodem.

🗂️ Agenda kursu — 14 lekcji

Rozwiń etap, żeby zobaczyć, co jest w każdej lekcji.

1. Start — instalacja i konfiguracja gita: cztery ustawienia, które robisz raz na całe życie. Jak git w ogóle działa — trzy obszary, w których żyją Twoje zmiany, i wskaźnik, który mówi, gdzie w historii stoisz. Na koniec różnica między gitem a GitHubem, którą myli większość początkujących.

2. Nowe repozytorium i .gitignore — zakładasz repozytorium na świeżym projekcie z CubeIDE i patrzysz, co git widzi. Dzielisz pliki na trzy grupy: co trafia do repozytorium, co nie, i czego nie wolno tam wrzucić nigdy. Piszesz własny .gitignore, dowiadujesz się, dlaczego biblioteki producenta zostają, i poznajesz procedurę ratunkową na wypadek, gdy śmieci już się dostały.

3. Pierwszy commit — po co git ma osobny krok przed commitem i jak sprawdzić, co dokładnie do niego wejdzie, zanim go zrobisz. Pierwszy commit, wycofanie się z przygotowanej zmiany i historia projektu w narzędziu graficznym — obraz, który będzie Ci towarzyszył do końca kursu.

4. Rytm pracy — pętla, którą będziesz robić codziennie: zmiana, sprawdzenie, commit. Trzy kolejne zmiany w firmware’ze, szukanie w historii, zaglądanie do jednego konkretnego commita — i odpowiedź na pytanie, jak często commitować.

5. Porządne commity — jeden plik, dwie niezwiązane zmiany: jak rozdzielić je na dwa osobne commity. Commit, który robi jedną rzecz, jak pisać jego opis — i antyprzykłady, które zobaczysz w niejednym repozytorium.

6. Kiedy coś pójdzie nie tak — cztery sytuacje, cztery narzędzia: cofnięcie zmian, których jeszcze nie scommitowałeś; cofnięcie commita, który jest już w historii, tak żeby został po tym ślad; skasowanie commitów, których nikt jeszcze nie widział; powrót do dowolnej wersji z przeszłości. Do tego półka na przerwaną pracę i oznaczanie wersji firmware’u.

7. Branche i merge — po co w ogóle branch i jak pracować obok release’ów. Dwa różne wyniki merge’a — i dlaczego raz powstaje dodatkowy commit, a raz nie. Sprzątanie po merge’u: branch znika, praca zostaje.

8. Konflikty — skąd się biorą i jak wygląda konflikt w pliku. Jak się z niego wycofać, jak go rozwiązać, cztery kroki wyjścia z każdego konfliktu i pułapki, w które wpada się najczęściej. Na koniec rada: jak się zachować, gdy konflikt wypadnie w kodzie wygenerowanym przez CubeMX.

9. Rebase — Twój branch został w tyle: jak przenieść swoją pracę na aktualny stan projektu. Konflikt w trakcie, droga odwrotu i odpowiedź na pytanie, które zadaje każdy: merge czy rebase?

10. Squash i przygotowanie zmiany do code review — pięć roboczych commitów zamieniasz w jeden porządny, na kopii, więc oryginał zostaje nietknięty. Wybierasz, co z roboczych zmian trafia do finalnej wersji, dopisujesz opis, który wyjaśnia „dlaczego”, i przenosisz pojedynczą zmianę między branchami.

11. Praca w zespole — zespół to wspólne repozytorium. Pięć zasad, na które się umawia: branch z release’ami zawsze da się wgrać, nazwa brancha mówi, co się dzieje, branche żyją krótko, każda zmiana przechodzi code review, a release’y mają swoje tagi. Na koniec cała droga jednej zmiany w jednym obrazku.

12. GitHub — czym jest zdalne repozytorium i jak wygląda u Ciebie lokalnie. Zakładasz repozytorium, ustalasz, co trafia na serwer, a co nigdy, i gdzie w ogóle może mieszkać repozytorium z kodem firmy. Logowanie bez ręcznego generowania tokenów, pierwsze wysłanie projektu i pobranie go na nowy komputer.

13. Zdalne repozytorium na co dzień — pobieranie cudzych zmian i dwa sposoby, żeby to zrobić. Co zrobić, gdy serwer odrzuci Twoją zmianę, bo ktoś był szybszy. Pull request od początku do końca — z komentarzem przy konkretnej linii — i release z plikiem firmware’u do pobrania.

14. Podsumowanie i co dalej — co masz w rękach po kursie, inne narzędzia graficzne do gita i sześć tematów na kolejny krok, gdy będą Ci potrzebne.

🔍 Sześć rzeczy, które zwykle wychodzą dopiero w pracy — i to boleśnie

Dlaczego biblioteki producenta zostają w repozytorium, a śmieci z kompilacji nie

Jak odłożyć przerwaną pracę na bok, gdy trzeba pilnie coś poprawić

Jak wrócić do wersji firmware’u, która działała — bez kopii katalogów

Konflikt przy merge’u — skąd się bierze i jak z niego wyjść, także wycofując się

Pięć roboczych commitów zamienionych w jeden porządny — bez ryzyka dla oryginału

Czego nigdy nie wysyłasz na serwer — i czego nie wysyłasz na cudzy

🖥️ Z jakiego oprogramowania korzystamy w kursie i dlaczego?

Git w terminalu

na Windowsie, tak jak w większości zespołów. Na Linuksie i macOS zrobisz dokładnie to samo — inaczej wygląda tylko instalacja i uruchamianie gita.

Narzędzia graficzne dołączone do gita

do oglądania historii i do wybierania, które zmiany trafią do commita. Są w każdej instalacji gita, nic nie dokupujesz.

Zwykły edytor tekstu

żeby widzieć, co robi git, a nie co robi IDE za Twoimi plecami. Projekt pochodzi ze STM32CubeIDE, ale samego IDE w kursie nie uruchamiamy — wszystko zadziała z każdym środowiskiem.

GitHub

darmowe konto, przyda się od lekcji 12.

👥 Dla kogo jest ten kurs — a dla kogo nie?

✅ Dla Ciebie, jeśli:

✅ wysyłasz sobie projekt mailem albo nosisz go na pendrivie,
✅ w projekcie na studiach pytacie się na Messengerze, kto ma najnowszą wersję,
✅ znasz kilka komend gita na pamięć, ale gdy coś wyskoczy na czerwono — kopiujesz katalog,
✅ niedługo zaczynasz praktyki albo pierwszą pracę i wiesz, że tam git jest czymś oczywistym,
✅ pracujesz sam i myślisz, że git to narzędzie dla zespołów — połowa kursu to praca w pojedynkę.

❌ Nie dla Ciebie, jeśli:

❌ na co dzień robisz rebase’y i pull requesty w zespole i nic Cię tu nie zaskoczy,
❌ szukasz wszystkich zaawansowanych opcji gita,
❌ chcesz nauczyć się programowania STM32 — tu STM32 jest tylko tłem.

👨‍🏫 Twój instruktor — Mateusz Salamon

Cześć! Nazywam się Mateusz Salamon. Od ponad 10 lat programuję mikrokontrolery, pracowałem w Intelu, gdzie pisałem BIOS na x86 w czystym C, a dziś uczę embedded — jestem autorem kursów STM32 dla Początkujących, STM32 na Rejestrach, FreeRTOS i Język C. Przez moje materiały przeszło ponad 1500 osób, a bloga msalamon.pl co miesiąc czytają tysiące programistów.

Trzonem tego kursu jest git z pracy w korporacji — w międzynarodowym zespole w Intelu. Nikt mnie go tam nie uczył na szkoleniu: wszyscy zakładali, że już umiem. To, czego się tam nauczyłem, stosuję do dziś we własnych projektach. Wdrożyłem to w mojej firmie i w wielu projektach, w których brałem udział, a które z jakiegoś powodu z gita nie korzystały.

Widzę to bardzo często: początkujący i małe firmy mają duży opór przed gitem. Zupełnie niepotrzebnie. To narzędzie mnóstwo ułatwia, upraszcza i przyspiesza — i moim zdaniem jest wręcz obowiązkowe od samego startu projektu.

Prowadzący jest Oficjalnym Partnerem ST (ST Partner Program)

🎬 Jak wygląda kurs od środka?

Bez podglądu lekcji — ale z konkretem, co dostajesz przy każdej z nich:

🎬 14 lekcji wideo, łącznie 4 godziny 10 minut — średnio ok. 18 minut na lekcję. Nagrane na ekranie, krok po kroku, na jednym projekcie od pierwszej do ostatniej lekcji.
📄 Tekstowa wersja pod każdą lekcją — te same kroki co na wideo, z tym, co git powinien odpowiedzieć. Nie przewijasz nagrania dziesiąty raz, żeby coś sobie przypomnieć.
🗺️ Plansze tłumaczące, co się dzieje w lekcji — 19 plansz: to, czego nie widać w terminalu, narysowane. Do obejrzenia pod lekcją i do wydruku w PDF.
⚡ Skrót na końcu każdej lekcji — wszystko, co w niej padło, zebrane w jednym miejscu. Wracasz do niego, zamiast do filmu.
📎 Załączniki do pobrania, w jednym ZIP-ie — ściągawka na dwie strony A4 ułożona według zadań, plansze w PDF, gotowe .gitignore dla CubeIDE i CMake oraz 🤖 instrukcja pracy z gitem dla agenta AI: wrzucasz ją do swojego repozytorium, a asystent kodujący trzyma się tych samych zasad co Ty.

💬 Co mówią pierwsi kursanci?

„Największym plusem jest dla mnie to, że kurs skupia się na praktycznych zagadnieniach, które faktycznie przydają się w codziennej pracy z systemami embedded. Kiedyś przerobiłem już jeden z popularnych polskich kursów Gita, który omawiał temat od A do Z, ale dopiero po kilku lekcjach tego kursu udało mi się zauważalnie usprawnić swój workflow. […] Najważniejsza jest merytoryka, a ta jak na razie zasługuje na solidne 5+!”

— Damian, hobbysta

„Kurs pokazał mechanikę działania GIT w sposób pozwalający na zrozumienie i rozpoczęcie korzystania z narzędzia. Przygotowany przykład rozwijanego projektu pokazał, jak to wygląda w rzeczywistym zastosowaniu. Każda lekcja nawiązuje do wcześniejszego materiału, nic nie jest oderwane od rzeczywistości.”

— Tomasz M., hobbysta

⏳ Jak długo będziesz mieć dostęp do kursu?

Dożywotnio. Kupujesz raz i wracasz do kursu, kiedy chcesz — przed pierwszą rozmową o pracę, przed pierwszym pull requestem w nowym zespole albo wtedy, gdy git znowu wypisze coś na czerwono.

To jeden weekend nauki albo tydzień wieczorów po godzinie. A git to jedna z niewielu rzeczy w tym zawodzie, które się nie starzeją: mikrokontrolery się zmieniają, IDE się zmieniają — git, którego nauczysz się teraz, pójdzie z Tobą do każdego zespołu i każdego projektu.

📦 Co otrzymasz, kupując kurs?

✔️ 14 lekcji wideo, 4 godziny 10 minut
✔️ dostęp dożywotni, od razu po zakupie
✔️ tekstową wersję każdej lekcji, plansze i skrót na końcu
✔️ ściągawkę na dwie strony A4, plansze w PDF, gotowe .gitignore dla CubeIDE i CMake
✔️ instrukcję pracy z gitem dla agenta AI
✔️ fakturę VAT

Jak dostajesz kurs: zaraz po opłaceniu zamówienia dostęp trafia na adres e-mail z zamówienia. Jeśli masz już konto na platformie kursowej, kurs dopisze się do niego.

Kurs jest treścią cyfrową dostępną w całości od razu po zakupie. Dlatego składając zamówienie, zgadzasz się na natychmiastowy dostęp i rezygnujesz z prawa do odstąpienia od umowy w ciągu 14 dni — kurs nie podlega zwrotowi.

❓ Najczęściej zadawane pytania (FAQ)

Nie. Zaczynamy od instalacji gita. Przyda się podstawowa obsługa komputera i jakikolwiek projekt, na którym będziesz ćwiczyć.

Od razu po opłaceniu zamówienia — dostęp trafia na adres e-mail z zamówienia. Jeśli masz już konto na platformie kursowej, kurs dopisze się do niego.

Nie. To kurs gita, nie STM32. W kursie pracuję na projekcie z CubeMX, ale Ty możesz ćwiczyć na dowolnym swoim projekcie.

Gita w terminalu na Windowsie, jego narzędzi graficznych i zwykłego edytora tekstu. Projekt pochodzi z STM32CubeIDE, ale samego IDE w kursie nie uruchamiamy — wszystko, co robimy, zadziała z każdym środowiskiem.

Tak, dokładnie to samo. Inaczej wygląda tylko instalacja i uruchamianie gita.

Wiem, że materiałów o gicie jest mnóstwo. Ten kurs to wiedza praktyczna, której nauczyłem się w pracy zawodowej — w korporacji, w międzynarodowym zespole — przekazana tak, jak prowadzę wszystkie swoje szkolenia: konkretnie i w skondensowanej formie, bez odpływania od tematu, prosto do brzegu. Sporo osób mówi mi, że lubi właśnie to, jak tłumaczę. Zamiast pojedynczych komend na przykładach z weba dostajesz całą drogę — od pustego katalogu do release’u — na projekcie, który wygląda jak Twój.

AI zna gita wyśmienicie i w całości — i chętnie zrobi wokół niego bardzo dużo rzeczy. Wiele z nich będzie nadmiarowych i niepotrzebnych, a przede wszystkim mogą się różnić od zasad, które obowiązują w Twoim projekcie. Znając podstawy, możesz mu wskazać, co ma się dziać w Twoim repozytorium — dokładnie według Twoich zasad albo tych, które ustalił Twój zespół. W kursie dostajesz do tego gotową instrukcję pracy z gitem dla agenta AI.

Git to jedna z pierwszych rzeczy, których używasz w zespole — i jedna z ostatnich, których ktoś Cię uczy. Kurs pokazuje sposób pracy, który zastaniesz w zespole programistycznym: branche, code review, pull requesty i release’y.

14 lekcji wideo, łącznie 4 godziny 10 minut — średnio ok. 18 minut na lekcję. Pod każdą lekcją jest jej tekstowa wersja, plansze i skrót tego, co w niej padło.

Dożywotnio.

Nie. Kurs jest treścią cyfrową dostępną w całości od razu po zakupie — składając zamówienie, zgadzasz się na natychmiastowy dostęp i rezygnujesz z prawa do odstąpienia od umowy w ciągu 14 dni.

Tak. Prowadzę legalnie działającą firmę i jestem płatnikiem VAT. Fakturę dostaniesz w ciągu kilku dni od opłacenia zamówienia.

Napisz na mateusz@msalamon.pl. Odpowiadam na każdego maila.

Wysyłka w dniu zamówienia

Złożyłeś zamówienie? Machina ruszyła! Czekamy na zaksięgowanie płatności, a później… Pakujemy, adresujemy i wysyłamy.

Wysyłka 24h

Jeśli zapłacisz do godziny 14:00, przesyłka zostanie dostarczona w przeciągu 24 H (w dni robocze). Przesyłka zamówiona po godzinie 14:00 zostanie wysłana w kolejnym dniu roboczym.

Do czasu wysyłki należy doliczyć czas doręczenia deklarowany przez wybranego przewoźnika.

Program darmowej dostawy!

Wiemy, że koszt wysyłki zawsze boli… Dlatego wprowadziliśmy program Darmowej Dostawy dla Paczkomatów do zamówień przedpłaconych. Darmowa Dostawa w sklepie msalamon dzieli się na dwie kategorie:

Kategoria 1

Darmowa Dostawa Paczkomatem dla wszystkich klientów w przypadku dokonania zakupów o wartości produktów fizycznych (bez Kursów Online) powyżej 400 zł.

Kategoria 2

Program Darmowej Dostawy dla stałych klientów. Aby skorzystać z programu Darmowej Dostawy dla stałych klientów należy spełnić poniższe warunki:

1️⃣Posiadać aktywne konto w sklepie. Założyć możesz np. tutaj: w https://sklep.msalamon.pl/moje-konto

2️⃣Dołączyć do newslettera sklepowego z nowościami i promocjami. Wysyłka regularnie co poniedziałek. https://sklep.msalamon.pl/newsletter

3️⃣Każdorazowo posiadać w koszyku produkty fizyczne (bez Kursów Online) o łącznej wartości co najmniej 100 zł.

Metody dostaw objęte promocją

Paczkomaty Inpost (przedpłata)
Żabka (przedpłata)
Orlen Paczka (przedpłata)

Pamiętaj, aby potwierdzić zapis do newslettera

*Promocja ważna jest od 15.02.2024 do odwołania

Ważne – poczekaj na potwierdzenie

Przyznanie darmowej wysyłki zawsze potwierdzone jest mailem. Poczekaj kilka minut, aby nasze systemy zdążyły się porozumieć i przyznać Ci obniżony próg Darmowej Dostawy.
Zwykle trwa to chwilę, maksymalnie 30 minut.