6 komentarzy

  1. Tomek napisał(a):

    Hej, ja dorzucił bym od siebie narzędzie Tortiose Git (https://tortoisegit.org/), może trochę oldschoolowe, ale działam z nim na codzień dla projektów umieszczonych w repozytoriach Bitbucket Atlassiana. Dodaje to menu kontekstowe na plikach i folderach i włatwy sposób można zrobić praktycznie wszystko. Obsługuje wszystkie popularne skróty do działania z GITem. Do działania z GitHubem jest przyjazny GitHub Desktop (https://desktop.github.com/) na wszystkie platformy stworzony przez samego GitHuba.

  2. Tomasz napisał(a):

    Ja używam do większości rzeczy konsoli, do rozwiązywania konfliktów używam kdiff3. Visual Studio w ogóle nie używam do obsługi gita.

    Jak zaczynałem uczyć się gita to od razu chciałem się nauczyć poleceń i używać konsoli, chciałem wiedzieć jak ten Git działa od środka. Nie chciałem się uzależnić od jakiegoś klienta Gita.

    Do drobnej pomocy mam zainstalowany SourceTree, z którego czasami korzystam jak wiem, że tą rzecz akurat w SourceTree uda mi się szybciej zrobić.

    • Patryk napisał(a):

      Właśnie o to chodzi. Konsola i jakieś wspomagacze, od czasu do czasu. Wtedy praca jest szybka i bezproblemowa, po prostu „dzieje się”. Masz jakiś konkretny powód do używania kdiff3?

  3. Sylwekqaz napisał(a):

    Jeżeli chodzi o gita i programowanie to mam podejście commit driven development, zakładam co ma moja praca zmienić w kodzie (tak w myśl zasady SRP) i później staram się to tak zakomitować, oczywiście czasami wychodzi więcej zmian niż planowałem, dlatego na etapie stagowania wybieram dokładnie które zmiany mają trafić do danego komita, często staguje poszczególne chunki albo linijki kodu. Dodatkowo staram się aby historia w gicie była jak najbardziej przejrzysta, traktuje ją na równi z kodem, który też powinien być dobrze sformatowany, aby był czytelny.

    Do obsługi gita podchodzę hybrydowo, z jednej strony GUI do wizualizacji z drugiej konsola do bardziej zaawansowanych rzeczy.
    GUI do gita ma służyć głównie do wizualizacji. Łatwiej jest zapanować nad całym drzewkiem komitów i nie pozwolić aby to drzewko zaczęło się krzaczyć (łatwiej jest podjąć decyzję czy mergować z fast-forward czy merge komitem, albo rebase), do tego w git GUI łatwiej przeglądać zmiany w kodzie, i co najważniejszcze zmiany można stageować po linijce w bardzo łatwy i intuicyjny sposób, co jest trochę trudniejsze do osiągnięcia z konsoli. Do tego takie GUI oferuje na tyle funkcjonalności, że większość podstawowych operacji można z niego przeprowadzić.
    Konsola przydaje się do wklepania bardziej skomplikowanych poleceń, ewentualnie do wykonania podstawowych komend jeżeli GUI zamula, albo akurat mamy odpaloną konsolę.
    Jeżeli chodzi o narzędzie do rozwiązywania konfliktów u mnie sprawdza się Visual Studio, które jest w stanie w miarę sprawne rozwiązywać konflikty do tego pozwala na edycję kodu w trakcie rozwiązywania konfliktu, a do tego VS zawsze gdzieś mam odpalone. Alternatywnie korzystam z małego onlinowego narzędzia do rozwiązywania konfliktów http://www.mergely.com/editor , ale wtedy kiedy mi zależy na rozwiązaniu konfliktów opartych o różnicę w plikach. Przydaje się np. wtedy kiedy ktoś zmieni formatowanie kodu w pliku i zmianach widać że cały plik został zmieniony, zamiast kilku linijek.

    Co do plików binarnych to git pozwala na ustawienie dowolnego programu do porównywania plików (per rozszerzenie), więc nie jest tak źle. Część git gui też jest w stanie wyświetlić pliki graficzne. Kiedyś korzystałem z Pandoc do porównywania zmian w pliku .docx https://github.com/vigente/gerardus/wiki/Integrate-git-diffs-with-word-docx-files

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *