[Screencast] Moje aliasy gitowe część 1

Git aliasy. Po co to robimy:
– przyspieszają wpisywanie komend
– aliasy pozwalają zmieścić komendy pod lepszymi nazwami, które normalnie wymagają zapamiętania czegoś
– aliasy pozwalają zrobić kilka operacji jedna po drugiej. Np przechodzić między branchami i robić cherry-pick ostatniego commita.

Aliasy, które utrzymuję https://gist.github.com/kmorcinek/5747081

Aliasy, które pojawiły się w tym filmie:

[Screencast] Klonowanie repozytorium poprzez SSH krok po kroku

Pokazujemy jak skonfigurować łączenie się ze zdalnym repozytorium korzystając z protokołu SSH. Będziemy się łączyć z serwisem gitlab.com.
Dzisiaj najprostszy przypadek, bez wgryzania się w szczegóły (to bardzo istotne), tak aby maksymalnie pomóc programistom, którzy tego nigdy nie robili.

GitLab and SSH keys – z tego korzystaliśmy w nagraniu

Dlaczego warto:
U Adriana w projekcie pracuje sie z wieloma repozytoriami hostowanymi na Azure DevOps. Polityka bezpieczeństwa wymaga aby za każdym razem uwierzetylniać się za pomocą AzureAD. Jeśli skorzystamy z protokołu SSH zamiast HTTPS to odpadnie tam to żmudne wpisywanie haseł. Warto też nadmienić że wygenerowany klucz może być również wykorzystywany do procesu CI/CD (odpada potrzeba zarządzania kontem serwisowym).

Jeżeli komuś podczas generowania wyskoczyło:

$ ssh-keygen -t rsa -b 4096 -C "email@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/lenovo.000/.ssh/id_rsa): /c/Users/lenovo.000/.ssh/id_rsa already exists.
Overwrite (y/n)?

to znaczy, że już klucz istnieje i można skoczyć do kolejnego kroku i klucz skopiować.

Podczas pierwszego połączenia do gitlaba zostaniemy zapytani o:
$ git clone git@gitlab.com:krzysztof.morcinek.432/testing-ssh.git
Cloning into 'testing-ssh'...
The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'gitlab.com,35.231.145.151' (ECDSA) to the list of known hosts.

Wpisujemy yes. Musimy to zaakceptować tylko raz, później już nie będziemy pytani o to więcej.

Merytoryczne sprawdzenie: Jakub Kozioł

Montaż: Adrian Wasielewski

[Screencast] Tworzenie publicznego repo na gitlabie wraz z pipeline’ami

Chcieliśmy pokazać jak proste jest stworzenie darmowego repozytorium wraz z Continuous Integration. Zrobiliśmy to używając GitLab CI/CD pipelines (GitHub też już ma dobre mechanizmy CI – GitHub Actions). GitLab jest po prostu bardziej rozpowszechoniony w firmach.

Pokazujemy również:

  • skorzystanie z gotowych zdefiniowanych template’ów CI dla popularnych języków
  • przykład Merge Request i merge do master‚a
  • przyklepanie Merge Requestu (Code Review).
  • wiele Merge Requestów jednocześnie i jak się gitlab zachowa
  • kilka ustawień usprawniających Merge Requesty (np Fast-forward only)

Odcinek był nagrywany na 2 sesje i niestety w połowie delikatnie ucina nam rodzielczość więc nie zobaczycie w całości górnej i lewej belki :/ ale poprawiła się jakość dźwięku 🙂

Montaż: Adrian Wasielewski

Git-tfs w praktyce – Screencast

Dzisiaj z Adrianem przejdziemy przez narzędzie GIT-TFS. Pozwala ono korzystać ze zdalnego serwera TFS, łącząc się do niego z pomocą GITa i lokalnie operować na repozytorium gitowym. Jest to wygodny krok przejściowy do przejścia w całości na gita. Pozwala bez presji czasu poznawać gita i nie wszyscy członkowie zespołu muszą to zrobić w tym samym momencie.

Analogicznie działa git-svn.

Problemy z clonowaniem zostały opisane w Instrukcja instalowania GIT-TFS

Repozytorium używane dzisiaj pod adresem https://dev.azure.com/adrianwasielewski0521

Jak wspomnieliśmy, w którymś z kolejnych odcinków zajmiemy się rozwiązywaniem konfliktów podczas pracy z GIT-TFS.

A jeśli jesteście zainteresowani szkoleniem np z GITa to zapraszamy na GitWarsztaty

Instrukcja instalowania GIT-TFS

git-tfs_logo

git-tfs to narzędzie pozwalające korzystać ze zdalnego repozytorium TFS gdy lokalnie mamy GITa. Analogicznie do opisywanego już Git-SVN. Z TFSa należy uciekać jak najszybciej i git-tfs jest właśnie takim krokiem w dobrym kierunku!

Instalacja z pomocą Chocolatey

Najprostsza instalacja Git-TFS jest poprzez https://chocolatey.org/docs/installation. Gdy już mamy chocolatey to https://chocolatey.org/packages/gittfs, czyli komenda

C:\> choco install gittfs

(mi sfailował na próbie instalacji samego GITa, ponieważ już go mam zainstalowanego w inny sposób, pomimo tego git-tfs zainstalował się pomyślnie)

Następnie reopen konsoli (żeby zaczytało nowe ścieżki dodane do zmiennej środowiskowej PATH.

Problem z klonowaniem

Akutalnie jest bug (więc zaczniemy od niego, żeby zaoszczędzić problemów) i raczej już nie będzie naprawiany. Możemy dostać komunikat TFS repository can not be root and must start with „$/”..

Rozwiązanie z https://github.com/git-tfs/git-tfs/issues/845#issuecomment-135395001 działa i polega na wrzuceniu MSYS_NO_PATHCONV=1 przed właściwą komendą czyli np MSYS_NO_PATHCONV=1

Problem występuję w konsoli gitowej, jeśli odpalimy np z PowerShella to problemu nie będzie.

Właściwe klonowanie

(poniższe rzeczy przykładowe, używaj własnych/firmowych repozytoriów)
Url z projektem: https://dev.azure.com/adrianwasielewski0521/GitTfsExample

Komenda do listowania branchy:
git-tfs list-remote-branches https://dev.azure.com/adrianwasielewski0521

Komenda do klonowania:
git-tfs clone https://dev.azure.com/adrianwasielewski0521 $/GitTfsExample/mainline

Przykład na zamykanie rozproszonej funkcjonalności do właściwego typu – screencast

Kontynuujemy nagrywanie i montowanie screencastów. Dzisiaj odcinek nr 4. Nabieramy tempa i regularności 🙂

Rozwinęliśmy przykład z ostatniego odcinka (Jak tworzyć dedykowane wrappery do prostych typów) i w praktyce przenieśliśmy funkcjonalność ze statycznych Utilsów do właściwego typu EthereumAddress.
Przykładem jest address w Ethereum (zmienione na potrzeby przejrzystości;) który najpierw był trzymany jako string a później został upgrade’owany do EthereumAddress (jakby wrapper). Koronnym przykładem jest porównywanie adresów, które pozwala unikać pomyłek.

Zalety:
– Kod jest bardziej spójny
– Łatwiej dostać do potrzebnych funkcjonalności
– Mniej ryzyko poperłnienia buga

Montaż: Adrian Wasielewski.

Kod: https://github.com/show-me-the-code-screencasts/ethereum-address-example

Jak prowizorycznie próbujemy wyciszyć pogłos;) – początki zawsze trudne
screencast - studio od kuchni

Jak tworzyć dedykowane wrappery do prostych typów – screencast

Wrzucamy już 3 odcinek naszej serii. Mamy plany i pomysły na kolejne. Jeżeli Tobie nasuwa się jakiś pomysł, który chciałbyś abyśmy poruszyli – podziel się nim w komentarzu.

Inspiracją był kod który musiałem napisać w pracy. Ten problem nie dotyczy tylko mnie. Najpierw powstał kod gdzie było wiele stringów i doprowadziło to do bugów. Debugowanie było problematyczne, związane to jest z tym, że string wszystko przyjmie. Doprowadziło to do potrzeby stworzenia dedykowanych typów, które rozwiązywały wspomniane problemy.

Wiele osób ma opory przed tworzeniem wrapperów np na typ „string”. Pokazujemy przykład kiedy warto. Takie podejście eliminuje problemy związane ze znajomością kodu i domeny (kontrola typów w trakcie kompilacji).

Dzisiaj wyszło dłużej (13 minut) ze względu na dużą ilość kodowania.

Montaż: Adrian Wasielewski

https://github.com/show-me-the-code-screencasts/addresses-example/