W dzisiejszym odcinku omówimy reminders (przypominajki):
– przypomnieć sobie o wiadomości którą dostaliśmy
– przypomnienia dzienne, godzinowe, cykliczne
– przypomnienia dla innych osób
– tworzenie przypomnień
– lista przypomnień
Współprowadzący: Dariusz Sibik
Pierwszy oficjalny odcinek podcastu. Próbujemy nowe formaty 🙂
– jak wygląda proces wrzucania nowej funkcjonalności na PRODa?
– jakie są kroki żeby funkcjonalność trafiła na PRODa?
– czy od razu działa dla wszystkich klientów?
– jak wygląda to w kodzie?
– jak długo później feature flag żyje?
– jak można testować feature flag?
Feature flag jest używane zamiennie z feature toggle
Rozmowę przeprowadził Darek Sibik.
– wyłączenie/włączanie powiadomien
– follow/unfollow i wpływ na zakładkę threads/wątki
– „Mark as unread” oraz „remind in 20 minutes” (wyjścia na obiad)
– podsumowanie w wątku oraz „Also send to channel”
– share do innego kanału
Współprowadzący: Dariusz Sibik
– prosta dyskucja o przeniesieniu spotkania
– deploy i problemy z deployem
– od kiedy korzystamy ze Slacka
– w jaki sposób korzystamy ze slacka (na poziomie firmy, projektu)
– przykłady kanałów
– priorytety i foldery
– komunikacja w kanałach (używanie @here)
– topic
– pinezki (pinned)
– szukanie w kanale (find)
– połączenie audio i video (call)
Dzisiaj podcast w 3 częściach nagranych podczas jednej dłuższej rozmowy, które powstały z pytań Darka w jego nowym projekcie.
Pierwsza:
Druga:
Trzecia:
Linki:
[GIT] Screencast: Synchronizacja własnej pracy ze zdalnym repozytorium
[Screencast] GIT – Rozwiązywanie konfliktów
The seven rules of a great Git commit message
Gość: Dariusz Sibik.
Rozwiązywanie konfliktów to bardzo istotny temat opisany kiedyś w formie pisemnej Git rozwiązywanie konfliktów wraca w formie screencasta. Pokaże podejście korzystając z mergetoola KDiff3.
Repozytorium, na którym można potrenować: Conflict line training
Jeśli czujesz że potrzebujesz się bardziej dokształcić zapraszam na gitwarsztaty.pl
Ustawienie w .gitconfig, które sprawi że podczas rozwiązywania konfliktów nie stworzą się pliki tymczasowe typu _BACKUP_12591.txt.
| [mergetool] | |
| keepBackup = false |
Kolega z Pragmatic Coders: Dariusz Sibik
Wprowadzenie jak korzystać z aliasów oraz jak je dodawać.
Aliasy, które utrzymuję https://gist.github.com/kmorcinek/5747081
Aliasy które użyto w tym filmie:
| [alias] | |
| st = status -s | |
| cam = commit -am | |
| diff = diff –word-diff |
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:
| [alias] | |
| ls = log –pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cgreen\\ [%an]" –decorate | |
| lst = log –pretty=format:%C(yellow)%h%Cred%d\\ %Creset%s%Cgreen\\ [%an] –decorate -10 | |
| lds = log –pretty=format:"%C(yellow)%h\\ %ad%Cred%d\\ %Creset%s%Cgreen\\ [%an]" –decorate –date=short | |
| ll = log –pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cgreen\\ [%an]" –decorate –numstat | |
| lol = log –graph –decorate –pretty=oneline –abbrev-commit –all | |
| cp = cherry-pick | |
| st = status -s | |
| ci = commit | |
| co = checkout | |
| br = branch | |
| diff = diff –word-diff | |
| wdiff = diff –word-diff=plain | |
| dc = diff –cached | |
| r = reset | |
| r1 = reset HEAD^ | |
| rh = reset –hard | |
| rh1 = reset HEAD^ –hard | |
| rh2 = reset HEAD^^ –hard | |
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
