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/

SRP – Zasada Pojedynczej Odpowiedzialności w praktyce – screencast

Kolejne spotkanie z Adrianem. Na dzisiaj przyniósł kod, który napisał kiedyś na zadaniu rekrutacyjnym. Jedna przykładowa klasa nie stosuje się do Single Responsibility Principle (obiecany ostatnio temat). Przechodzimy przez kilka refactoringów i dyskusję kiedy warto wydzielać osobne serwisy i co w praktyce znaczy SRP – czyli, że klasa ma jeden powód do zmiany.

Kiedy tworzyć abstrakcje bo coś się zmieni (źródło pobierania danych do zdeserializowania), a kiedy nie tworzyć dodatkowych abstrakcji (Deserializacja XML’a do obiektów .NETowych).

Montaż: Adrian Wasielewski.

[StyleCop] od jakiego zestawu reguł wystartować

Korzystam ze StyleCopa od ładnych kilku lat. Zapewnia statyczną analizę kodu pod względem stylu (nie do końca tylko stylu ale to jest aspekt, na którym się skupiam). Jest to niezbędne narzędzie gdy stosuje się Code Review. Po prostu szkoda czasu i ludzkiej cierpliwości, żeby ręcznie wytykać komuś coś, co może wychwycić narzędzie. Preferowany sposób korzystania to poprzez StyleCop.Analyzers

Dzisiaj chciałbym podzielić się zestawem reguł, który w różnych projektach stosuję od lat. Pod to stworzyłem repozytorium https://github.com/kmorcinek/dotnet-tools-settings i plik StyleCopDefault.ruleset

example stylecop ruleset

Każda ignorowana reguła jest opisana, przykłady:

SA1611 - ElementParametersMustBeDocumented (no required documentation)
  • jeśli ktoś uważa, że przyda się komentarz to może dodać, ale nie można tego wymuszać, bo większość byłaby trywialnymi komentarzami, które nic nie wniosą.
SA1202 - ElementsMustBeOrderedByAccess, similar to SA1204 (assume couple of public methods in class, I want to have private methods used by a public method just below this public method, not below all other public methods)
  • zbyt na siłę, tak jak opisałem – nie sprawdza się.
SA1309 - FieldNamesMustNotBeginWithUnderscore (private fields should begin with underscore)
  • akurat w C# jest konwencja, żeby tak rozpoczynać od podkreślenia (a przynajmniej ja wolę to niż zaczynać prywatne pola od this)

Zostaję z dwoma pytaniami:
* czy wszystkie „Warning” przerobić na „Error” – zwracam się ku temu, ale na razie zostaje jak jest.
* czy dodać do pliku wszystkie, wszystkie reguły i ustawić na „Warning” („Error”) – będzie to może łatwiejsze w utrzymywaniu/zmienianiu w przyszłości i łatwiej będzie się włączało/wyłączało pojedyncze reguły.

Nie wszystko jest włączone z defaultu

Dotychczas myślałem (gdzieś przeczytałem) że wszystko co nie pojawia się w pliku konfiguracyjnym jest „włączone”, okazało się że nie wszystko, a prawie wszystko: StyleCopAnalyzers Status

To nie jest ostateczna wersja

Nie wszystkie te ustawienia są dla mnie ostatecznym wyznacznikiem co i jak robić. Pewnie w jeszcze innym projekcie coś włączę, coś wyłączę i to samo dotyczy Ciebie czytelniku. Jest to pierwsze miejsce gdzie się tym dzielę, więc zapraszam do podrzucania własnych ustawień i przemyśleń. A jeśli jeszcze nie masz wyrobionego stylu to znalazłeś gotowca:), daj mu szansę przez jakiś czas.

PS w kolejnych postach opiszę jak wprowadzać to w istniejący projekt, oraz jak ignorować czasem niektóre reguły.

[GIT] Screencast: Synchronizacja własnej pracy ze zdalnym repozytorium

Spotkałem się dzisiaj z Adrianem, aby nagrać screencast o tym jak dobrze synchronizować się ze zdalnym trunkiem/masterem/developem.

Nie powiemy o wszystkim co się dzieje w trakcie takiej pracy (bo za dużo jest ciekawych rzeczy jak na krótki odcinek). Skupimy się na porównaniu „rebase VS merge„.

Montaż: Adrian Wasielewski.

Na początku zarysujemy problem, potem pokazuję jedno podejście (rebase), następnie drugie podejście (merge) i na koniec podsumowujemy i wyciągamy wnioski.

Obrazek podsumowujący:

rebase vs merge final screencast

W kolejnych odcinkach opowiemy min o podejściu do rozwiązywania konfliktow, a także zaczniemy omawiać zasady SOLID.

Git commit jako ktoś inny

W Git można dodać autora commitu jakiego się chce. Domyślnie jest to brane z pliku konfiguracyjnego i będzie to nasza kombinacja username/email. Można to jednak prosto nadpisać:

git commit --author="Konrad Dzwinel <kdzwinel@gmail.com>" -m "Commited as the Konrad for fun."

Na GitHubie w naszym commit pojawi się nawet odpowiednia twarz osoby, którą sobie losowo wzięliśmy z GitHuba.

Git, Commited as somebody else
Po prostu się pod kogoś podszyłem

W git osoba która wykonała push do repozytorium, a osoba która jest jako author commita to moga być różne osoby i warto o tym pamiętać. Nie jest to jakieś złe (takie commity nie pojawia się u Konrada w „latest commits”), w ten sposób możemy zaznaczyć że tę dobrą robotę wykonał ktoś inny i dla niego zarezerwowane sa credits.