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ń!
Zbuduj odporny na awarie klaster Docker Swarm z wykorzystaniem Raspberry Pi i GlusterFS. Poznaj zasady tworzenia rozdystrybuowanego systemu plików i naucz się efektywnie zarządzać współdzielonym magazynem danych w środowisku klastrowym, minimalizując ryzyko przestojów dzięki tej przystępnej i ekonomicznej konfiguracji.
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.
Montowanie dysku w systemach z rodziny Debiana na ogół przebiega automatycznie, szczególnie jeśli używamy ze środowisk graficznych.
Bywa jednak, szczególnie w systemach serwerowych lub w wersjach bez setek demonów czuwających w tle, że musimy zamontować dysk samodzielnie. Bywa, że są z tym problemy, poniżej przedstawiam przepis jak zrobić to szybko i pewnie! 🙂
Moja potrzeba była dość prosta – uruchomić Serwer słuchający na określonym porcie protokołu TCP w Linuxie, serwer napisany było oczywiście w .NET Core.
Microsoft dumnie obwieszcza wsparcie dla Linuxów, ja nie dawno powiedziałem sprawdzam i postanowiłem zweryfikować jak zadziała self-hostowany serwer TCP opublikowany na Ubuntu 18 Server.