Praca z git z IDE czy z terminala?

Odpowiednie narzędzie do odpowiedniego celu.

Jeśli integracja z gitem w IDE (IntelliJ, Rider czy Visual Studio) ma odpowiednie funkcje (commit, push, pull, cherry-pick) to można użyć tej z IDE. Jeśli jakiś feature nie jest wspierany, np w IntelliJ niestety nadal nie da się zrobić git rebase --exec to nie ma innego wyjścia i trzeba odpalić z command line'a.

Możesz też po prostu używać tego co Ci się podoba.

Riddle napisał(a):

Odpowiednie narzędzie do odpowiedniego celu.

Jeśli integracja z gitem w IDE (IntelliJ, Rider czy Visual Studio) ma odpowiednie funkcje (commit, push, pull, cherry-pick) to można użyć tej z IDE. Jeśli jakiś feature nie jest wspierany, np git rebase --exec to nie ma innego wyjścia i trzeba odpalić z command line'a.

Dzięki :)

Michał Jasiński napisał(a):

Uczę się właśnie Git-a, a właściwie Bash-a. Wszystko fajnie tylko zacząłem mieć wątpliwości, czy w pracy również korzystacie z Bash-a, czy raczej bazujecie na wtyczce

Wróć, bo coś pokręciłeś.

Przez Bash chyba na myśli CLI/terminal, a nie samego Basha?

Moje wątpliwości wynikają z samej idei pracy z Bash-em który najpierw przenosi pliki z repozytorium do katalogu roboczego i dopiero wówczas możemy uruchomić nasz projekt w VS. Wydaje mi się to trochę działaniem dookoła

A tutaj już nie bardzo rozumiem, co masz na myśli? Czy chodzi ci o git clone? git pull? O to, że są remote'y i trzeba mieć z tyłu głowy, że tutaj mamy lokalne repo, a tu remote?

I w jaki sposób masz inny(lepszy?) workflow za pomocą wtyczki?

z repozytorium

Ale wiesz, że repozytorium to zarówno to, co masz na serwerze, jak i twoja lokalna kopia repozytorium? Tak działa Git (w przeciwieństwie do niektórych innych systemów kontroli wersji - SVN zdaje się inaczej działa, jeśli ktoś z niego jeszcze korzysta)

bezpośrednio łączymy się z repozytorium, a proces pobierania do przestrzeni roboczej odbywa się można powiedzieć w tle w sposób automatyczny.

Co to znaczy "bezpośrednio łączymy się z repozytorium"? Przecież w linii komend też się bezpośrednio łączysz ze zdalnym repo. I też proces pobierania odbywa się w sposób automatyczny. Robisz git pull i się pobierają dane.

przestrzeni roboczej

Co masz na myśli przez przestrzeń roboczą?

Albo ja nie rozumiem, co masz na myśli (być może dlatego, że nie korzystam z VS), albo ty nie rozumiesz do końca, jak działa Git i masz jakieś dziwne wyobrażenia. model mentalny).

Czemu nie dwa na raz, z konsoli wiele rzeczy szybciej, ale np merge już nie. Ja mieszam.

Ja robię większość z poziomu IDE (VS Code oraz Visual Studio). Jak czegoś nie da się zrobić w IDE lub łatwiej to zrobić z poziomu CLI to robię to przez CLI. Wielu programistów z którymi pracowałem robi w ten sposób.

U mnie: 80% - konsola. 20% UI (glownie przegladanie historii, robienie diffow itp.). Konsola daje wieksza kontrole + mam porobione aliasy wiec po prostu przewaznie jest szybciej. Zwlaszcza jesli pracuje na Linuxie, gdzie konsole mam pod klawiszem jak w Quake.

Wyobraź sobie tłumaczenie git workflow komuś kto korzysta tylko z IDE. Zawsze rozpoczynam uczenie kogoś od pokazania mu podstawowych komend w konsoli bo pokazywanie komuś przycisku do kliknięcia mija się z celem. Nie zrobisz z nikogo inżyniera tłumacząc mu w ten sposób. Jeżeli już rozumiesz całe workflow robiąc wszystkie komendy z konsoli to sobie korzystaj z IDE, o ile uznasz, że to jest dla Ciebie bardziej efektywne. Ale zwykle nie jest. Ja na przykład wszystko robię z konsoli.

U mnie w pracy większość używa CLI. Wtyczki w IDE używają głównie juniorzy i dotnetowcy :)

Moje wątpliwości wynikają z samej idei pracy z Bash-em który najpierw przenosi pliki z repozytorium do katalogu roboczego i dopiero wówczas możemy uruchomić nasz projekt w VS. Wydaje mi się to trochę działaniem dookoła. Chyba szybciej i wygodniej jest skorzystać z wtyczki do VS dzięki której bezpośrednio łączymy się z repozytorium, a proces pobierania do przestrzeni roboczej odbywa się można powiedzieć w tle w sposób automatyczny

To co tutaj napisałeś ewidentnie wskazuje na to, że nie wiesz jak działa git. Polecam się douczyć, zaczynając od teorii, a potem przechodząc do CLI.

Dzięki Panowie, kilku z Was wyjaśniło mi w trzech żołnierskich słowach ideę korzystania z CLI vs IDE

Ja wykorzystuję Magit (98% Magit / 2% CLI) i sam nie wyobrażam sobie na co dzień odpalać komend głównie z konsoli.

Dzięki Magitowi nie tylko większość komend mam w zasięgu dwóch klawiszy (np. pusz to p p, pusz forse to p -f p, fecz to f a, rebase interaktywny to r i, utworzenie nowego worktree * b itd.), ale oferuje on również sporo rzeczy ciężko osiągalnych z poziomu samego CLI - przykładowo otwierając log commitów (l l):

... mogę strzałkami wybrać commit, po czym odpalam M-x magit-checkout i voilá jestem na commicie; z tego widoku mogę też zrobić r k (które wykonuje rebase usuwający wskazany commit), r w (rebase pozwalający na zmianę tytułu wskazanego commitu) albo r m (rebase zmieniający zawartość wskaznego commitu).

Nie są to oczywiście rzeczy, których nie da się zrobić inaczej, ale np. takie r w z konsoli wymagałoby odpalenia git log, skopiowania hasza commitu do schowka (z wykorzystaniem myszki, bleh), potem git rebase -i, namierzenia tego commitu na liście commitów do zrebase'owania i, ostatecznie, zmiany na reword; z poziomu Magita jest to prostsze.

Z innych fajnych bajerów - l l pokazuje log obecnego brancza, ale samo l odpala pomoc dla polecenia log:

Niby podobne do man git log, ale jednak ładniejsze - dodatkowo każda widoczna tutaj opcja jest możliwa do zapisania jako domyślna: np. jeśli ktoś nie chce mieć predefiniowanego -g, to można zrobić -g (które tę opcję odznaczy), po czym C-x C-s (które zapisze obecny widok jako domyślny); git config na sterydach, bez konieczności zapamiętywania rzeczy w stylu o kurczę jak nazywa się ta opcja, która robi pull rebase jako domyślny.

Magit jako wtyczka do Emacsa (a nie osobna aplikacja) oznacza też, że ma się za darmo diffy (w takiej samej skórce oraz kolorowaniu składni jak edytor) oraz możliwość skakania do plików bez konieczności kopiowania ścieżek między CLI a edytorem - otwieram sobie listę commitów, klikam enter i:

... gdzie przechodząc po diffie kliknięcie Enter otwiera dany plik w wersji z commita, a Ctrl + Enter w wersji z HEADa.

Istnieje też wtyczka do robienia code review prosto z Magita (wspierająca GitHuba i GitLaba), ale nie miałem jeszcze okazji potestować :-)

Podsumowując, Magit (tudzież inne narzędzia GUI / GUI-like) nie umożliwia fundamentalnie więcej ¹ niż to, na co pozwala sam Git - ale takie narzędzia sprawiają, że robienie niektórych rzeczy jest dużo łatwiejsze. Na przykład przed Magitem niezbyt chciało mi się bawić w ad hoc rebase'owanie albo zmiany tytułów commitów, bo z CLI jest to niewygodne - a w Magicie raz, dwa i po bólu; niby 15 sekund w konsoli, a 5 sekund z poziomu Magita to niewielka różnica, ale mentalnie pozostawia to całkowicie inne wrażenie; teraz korzystając z konsolowego Gita czuję, jak gdybym poruszał się w smole :-P

Choć oczywiście osobom początkującym polecałbym zaczynanie od wersji terminalowej - zrozumienie modelu mentalnego Gita jest ważne i pozwala na uniknięcie niezręcznych sytuacji w przyszłości.

¹ znam tylko jeden przykład rzeczy, którą da się zrobić (tutaj akurat) z IntelliJ, a nie da (łatwo) z konsolowego Gita: jest to AST-based conflict resolution; tj. środowiska IntelliJ pozwalają na rozwiązywanie konfliktów w oparciu o AST, co pozwala na automatyczne rozwiązanie rzeczy w stylu use foo::{A, B}; + use foo::{B, C}; = use foo::{A, B, C}; (w Gicie jest to konfliktem, bo obydwa diffy ruszają tę samą linijkę, podczas gdy w AST jasno widać, że zmiany nie kolidują, bo jeden dodaje import na A, a drugi import na C); widać to na screenshocie tutaj (ta różdżka, Resolve Automatically, rozwiązuje konflikt na bazie AST właśnie); Magit tego nie wspiera i nie powiem, że trochę mi tego ficzera brakuje!

programuje juz 6 lat a nadal boje sie robic jakies merge/rebase w visual studio (ide) i robie wszystko w konsoli

Ja generalnie mieszam: przeglądam historię, robię commity,zarządzam branchami, rebase'uje swój branch z devem z poziomu intellij'a ale już np. cherry pick czy rebase intreractive na swoim branchu robie z terminala (robię to rzadko dlatego nie miałem na tyle samozaparcia aby poszukać tych ficzerów w IDE).

nikt nie bierze pod uwagę zewnętrznego (nie związanego z IDE) toola?

Merge conflicty tylko w GUI, wkurza mnie ta operacja na terminalu, cała reszta w CMD.

Rzeczy które ja robię z IDE:

• rebase on branch
• checkout na branch i commit hash
• pull (update + rebase on current)
• commit, commit --amend
• nowe branche i usuwanie branchy (w tym na remote)
• cherry-pick
• squash i fixup
• nowe tagi
• push, push force

Rzeczy które robię z CLI:

• rebase na commit hash
• checkout na commit hash
• git fetch
• git reset
• interactive rebase

Jeszcze jeden argument, Ze warto ogarniac z poziomu konsoli: czesto przy wszelkiego rodzaju automatyzacji CI, pipelinach na gitlabie, jobach Jenkinsowych itp. trzeba sobie zakodowac operacje na gicie w skrypcie (chociaz fakt, przewaznei to sa banalne rzeczy)

Z osobistego doświadczenia to polecam konsole. Najszybciej i jak sie nauczysz komend to wbrew pozorom jest najprościej. W dodatku wiesz co siepod kopułą dzieje a jak robisz coś przez IDE albo te programy do gita to nie wiesz.
Już nieraz się na takim sourcetree przejechałem.

90% konsola, ale TortoiseGit do rozwiązywania konfliktów.

Brakuje mi w Visual Studio opcji całkowitego wyłączenia integracji z Gitem. Z jakiegoś powodu nie radzi sobie z używanym w projekcie repo, wpada czasem w jakąś nieskończoną pętlę odpalając proces Gita w kółko i zamulając kompa. Muszę ręcznie kasować git.exe używany przez VS. Niestety aktualizacja VS przywraca ten plik i jak widzę że problem powrócił to muszę znowu git.exe kasować.

GitHub Desktop / Git Kraken? any1?

Na dłuższą metę myślę, że narzędzie nie ma większego znaczenia. Ja używam od ponad 10 lat Git Extensions + terminala i sobie chwalę:P
Z drugiej strony każdemu, kto nie czuje się pewnie w gicie (tzn. nie rozumie bardzo dobrze, co dzieje się na drzewie commitów przy poszczególnych operacjach, nie wie, co to index, stash itp.), zdecydowanie polecam czystą konsolę. Zwłaszcza że IDE często narzucają swoją nomenklaturę niespójną z gitem (jakieś check-iny, synci itd.), co utrudnia zrozumienie jego filozofii.

Hrypa napisał(a):

Zwłaszcza że IDE często narzucają swoją nomenklaturę niespójną z gitem (jakieś check-iny, synci itd.), co utrudnia zrozumienie jego filozofii.

Te które narzucają to narzucają. IDE od JetBrains tak nie robi i checkout to checkout, a cherry-pick to cherry-pick.

git w VSCode to chyba najczęściej
jak chce mieć szersze spojrzenie na repozytorium to GitKraken
jak robię przemeblowanie w folderze to TortoiseGit
jak nie ma gui to wszystko z konsoli

ja w VSCode korzystam tylko z tego, że mi robi diffy i pokazuje, które pliki są zmodyfikowane.

A ja lubię tortoise :D

twoj_stary_pijany napisał(a):

Wyobraź sobie tłumaczenie git workflow komuś kto korzysta tylko z IDE. Zawsze rozpoczynam uczenie kogoś od pokazania mu podstawowych komend w konsoli bo pokazywanie komuś przycisku do kliknięcia mija się z celem.

Czemu? Efekt działania komendy, jak i kliknięcia jest ten sam. Różnica taka, że w GUI natychmiastowo i czytelnie widać efekty.

Nie zrobisz z nikogo inżyniera tłumacząc mu w ten sposób. Jeżeli już rozumiesz całe workflow robiąc wszystkie komendy z konsoli to sobie korzystaj z IDE, o ile uznasz, że to jest dla Ciebie bardziej efektywne. Ale zwykle nie jest. Ja na przykład wszystko robię z konsoli.

Efektywność można zmierzyć liczbą ruchów palców bądź liczbą popełnionych błędów. GUI wygra, bo jednego i drugiego jest mniej.

W konsoli robię to, co szybciej, czyli aktualizowanie mastera będąc na feature branchu. (Co jest zdaje się czarną magią dla większości ekspertów od konsoli.)

1a2b3c4d5e napisał(a):

GitHub Desktop / Git Kraken? any1?

Nie mam pojęcia, które gorsze. Ale prawdopodobnie oba lepsze niż Tortoise.

ja tylko dodam, że po wielu próbach różnych klientów aktualnie od dłuższego czasu używam git extension - lekki (dużo lżejszy od krakena), wbudowana konsola GITa, czytelny i ma wszystko czego potrzebuję. BTW GH Desktop działa tylko z GH o ile dobrze kojarzę

Skorzystam z okazji by przypomnieć forumowiczom, że ten program nazywa się Git, i nie jest to od niczego skrótowiec, więc nie pisze się go GIT.

Również nie ma takiego programu jak SVN, tylko jest Subversion. Ale to 11 liter kontra 3 i nawet polecenie jest svn, więc można wybaczyć :)

Co innego wcześniejszy Concurrent Versions System (w skrócie CVS) i jeszcze wcześniejszy Revision Control System (w skrócie RCS).

git to nie skrót od github? przecież to tam się robi repo /s </joke>