Kontynuujemy serię artykułów o GIT, dzisiaj zajmiemy się przeglądem narzędzi przydatnych podczas korzystania z GITa.
Narzędzia bardzo ułatwiają pracę, a częstokroć pozwalają zapobiec tragedii poprzez zobrazowanie „układu projektu” przed wykonaniem ryzykownej operacji.
Kolejny z serii artykułów o GIT. Dzisiaj sporo wiedzy o liniowej historii zmian w GIT. Często pracując nad projektem chcemy mieć czystą historię zmian, niezaśmieconą merge comitami i niepoprzeplataną mieszaniną commitów naszych i innych programistów. Możemy to zrealizować na kilka sposobów. Omówimy je w tym artykule.
Drugi artykuł w mini cyklu o GIT. W dzisiejszym odcinku powiemy o podstawach, właściwie to o najbardziej podstawowej funkcji GITa, czyli łączeniu zmian z różnych gałęzi.
Nie będziemy zajmować się trywialnymi zagadnieniami w stylu „jak to zrobić”, przyjrzymy się natomiast dwóm kwestią: fast-forward i merge-commit. Co to właściwie jest i w jakich sytuacjach wystarczy przesunięcie głowy, a jakich jest konieczne wykonanie dedykowanego commitu łączącego zmiany z dwóch gałęzi. Dobre zrozumienie tej podstawy jest konieczne aby pojąć co dzieje się „pod maską” polecenia Rebase.
W ostatnim czasie prowadziłem kilka szkoleń i konsultacji dla programistów. Wszyscy – bez wyjątku – używają GITa, większość programistów „mniej więcej” wie jak działa GIT, opisują to tak: „gdy dodajemy nową funkcję to tworzymy branch, pracujemy robiąc często commity, gdy skończymy to robimy merge do mastera, wtedy mogą być konflikty, a jak je rozwiążemy to wypychamy pullem zmiany do publicznego repo„.
Fajnie i nawet działa, ale przy większych projektach konieczne może się okazać bardziej dogłębne zaznajomienie z GITem, przydaj się to szczególnie w niestandardowych sytuacjach lub gdy chcemy wykorzystać możliwości drzemiące w GIT celem osiągnięcia bardziej wyrafinowanych celów.
Podczas rozmów rekrutayjnych zdarzało mi się zadać nast. pytania osobom, które zaznaczają 5/5 w pozycji GIT w CV:
W jakiej sytuacji możemy znaleźć się w pozycji z odłączonym HEAD? Co to znaczy, że HEAD jest odłączony?
Co to jest merge-commit, co to jest fast-forward?
Czy wykorzystywałeś kiedyś REBASE? W jakim celu?
Czy można zmienić kolejność commitów w GIT i edytować komentarze umieszczone kilka commitów temu? W jaki sposób zmodyfikować commit wykonany „4 commity temu„?
Po co używać squash?
Czy rebase można zastąpić kilkoma cherry-pickami?
Czy można wykonać „git add” i „git commit” w jednej komendzie? Jak zrobić to najprościej? Co to są aliasy GITa?
Czy commit może mieć 2 rodziców? Co to jest merge-commit?
A Ty znasz odpowiedzi? 🙂 Zapraszam do dalszej lektury serii artykułów o GIT.
W dzisiejszym odcinku przyjrzymy się głowie, czyli podstawie do dalszych rozważań!
Nasz ekosystem złożony z Raspberry Pi i innych usług rozrasta się. Przydałby się jakiś mechanizm monitorowania. Skorzystajmy z profesjonalnego i bardzo popularnego Nagiosa. W tym artykule przedstawię jak uruchomić Nagiosa na Dockerze i monitorować zdalne środowiska.
Natknąłem się na ciekawy, dobrze wydany i zawierający sporo skondensowanej, użytecznej treści Przewodnik po Platformie Azure dla Developerów. Jego zaletą jest to, że w przeciwieństwie do innych darmowych wydań Microsoftu jest dostępny na urządzenia typu Kindle (tzn. dostępna jest wersja EPUB i MOBI).
Tytuł jest nieco na wyrost, ponieważ do profesjonalnej macierzy naszej konstrukcji jeszcze daleko, jednak mamy bardzo ciekawą opcję zapoznania się jak działa rozdystrybuowany system plików oraz jakie zasady są istotne podczas tworzenia macierzy, a przy okazji skonstruujemy nieźle działający system serwerowy w cenie kilkuset złotych. Zaczynajmy! 🙂
Tworzenie wolumenu GlusterFS w Raspberry Pi na potrzeby klastra Docker Swarm.