Cześć - krótko i na temat- używacie? Dlaczego tak, dlaczego nie?
Ja zawsze używałem konsoli, ale widzę, że u mnie w firmie większość pracuje na SourceTree -> Co oni w tym widzą? Warto się przesiadać? Bardziej skomplikowane rzeczy ST też ogarnie?
Git 
- Rejestracja:ponad 8 lat
- Ostatnio:ponad 5 lat
0
SourceTree ma bardzo przyjemny interfejs. Dostępny na Windows/Mac. Minusem dla mnie brak wersji na Linux. Konsola spoko ale dużo szybciej robi się proste rzeczy z gui. Obecnie testuję wtyczkę w Intellij. Natomiast mam też w zapasie GitKraken. Jest mniej intuicyjne od SourceTree ale ma też niektóre rzeczy rozwiązane dużo lepiej.
Minusem takich klientów jest skleroza do konsoli niestety...
- Rejestracja:prawie 14 lat
- Ostatnio:około godziny
- Postów:3171
0
Konsola + wtyczka w intellij + do ogladania duzych zmian bardzo lubie gitk
- Rejestracja:prawie 10 lat
- Ostatnio:ponad 4 lata
- Lokalizacja:Piwnica
- Postów:7697
0
przy SourceTree trzeba utworzyć (kolejne) konto, więc już wolę klasyczne gui+jakieś dodatki do edytora/ide
- Rejestracja:prawie 10 lat
- Ostatnio:około 2 lata
- Lokalizacja:Łódź
- Postów:48
1
Osobiście preferuję konsolę, ale gdy trzeba coś sprawdzić lub porównać (np. konflikt) to używam GitHub Desktop (stworzony przez GitHub). IMHO jest najbardziej intuicyjny, a ostatnio wyszła wersja 1.0.
edytowany 1x, ostatnio: Laran
- Rejestracja:około 17 lat
- Ostatnio:2 minuty
- Lokalizacja:Wrocław
1
GitExtensions, konsola jeśli trzeba.
Za to w pracy strasznie wkurzają mnie osoby korzystające wyłącznie z konsoli. Niby tacy profesjonalni, ale ani rebase ani squasha ani nawet fastforward nie umieją i każdy ich push jest z obowiązkowym merge commitem. :/
Zobacz pozostałe 10 komentarzy
Krolik
"Czasem dotarcie do poprzedniej wersji może być trudne w takim przypadku" W jaki niby sposób trudne? Poprzednia wersja jest przed punktem, gdzie nastąpił merge zmian z ficzer-brancha. Po to właśnie jest merge-commit. Natomiast jeśli merge commit nie był potrzebny, to historia jest liniowa i wtedy w ogóle nie ma problemu.
Kocica
@Krolik - może się źle wyraziłam - ale chodziło o sytuację - kilka temp commitów, potem poprawa literówki, potem kilka temp commitów potem działająca lokalnie wersja i znów kilka tem commitów. Dotrzyj wtedy do tej, która się kompilowała i działała w ramach tych commitów. Aha i zrób to szczególnie wtedy, kiedy ludzie nie piszą komentarzy bo nie mają czasu lub gdy jest to wymuszone wpisują "poprawki", "aaa" itp - sytuacje realne ale na mercurialu.
Krolik
No to problemem są bałaganiarskie commity i brak code-review, a nie nieumiejętność używania rebase. Jeśli jednak ktoś pilnuje ładnej organizacji commitów i przed każdym commitem odpala testy, to tak naprawdę nie ma potrzeby używania rebase.
Kocica
Co więc robić, gdy pracodawca nie inwestuje w komputery tzn. używane są stare niestabilne i potrzeba nie tylko commita ale i temp commita wypchnąć pushem na zewnątrz? Czy wtedy jest sens odpalać te testy? Zakładamy idealizm, a w polskich firmach daleko do niego.
somekind
Testy przed każdym commitem to jakaś utopia, bo nie zawsze nawet da się testy odpalić (no chyba, że ktoś pisze w dynamicznym języku), albo jeśli robi się jeden commit dziennie (albo tygodniowo) i commituje tylko zakończony i działający etap pracy. Dla mnie takie coś jest nie do pomyślenia, w ogóle zabija sens używania Gita, który traktuję dla siebie lokalnie jako undo/redo. A że historia feature branchy nie jest istotna, to zazwyczaj wolę je sqashować. Merge commit tylko jeśli branch był rozciągnięty w czasie albo zawierał skomplikowane zmiany.
0
IntelliJ do diffów i czasem konfliktów (raczej dłuższych, krótkie robię z palca), cała reszta z konsoli.
somekind napisał(a):
GitExtensions, konsola jeśli trzeba.
Za to w pracy strasznie wkurzają mnie osoby korzystające wyłącznie z konsoli. Niby tacy profesjonalni, ale ani rebase ani squasha ani nawet fastforward nie umieją i każdy ich push jest z obowiązkowym merge commitem. :/
No to raczej po prostu nie są kompetentni. Tak samo osoba która wam zarządza repozytoriami, brak merge commitów powinien być wymuszany automatycznie
Zobacz pozostałe 11 komentarzy
W końcu gdy przyjdzie wynik recenzji dla łatki z 4.8 i okaże się, że trzeba poprawić głupią literówkę, to w workflow z rebase musisz: zrobić rebase + fixup łatki w wersji 4.8, zresetować pozostałe ficzer-gałęzie dla łatki tj. cofnąć je do 5.0, 5.1 i master i następnie zrobić na nowo cały merge łatki z 4.8 do 5.0, do 5.1 i master. Przy większych zmianach to może być dzień roboty. A później recenzent musi zgadywać, co się zmieniło i de facto recenzować wszystko na nowo. W workflow z merge wrzucasz poprawkę literówki osobnym commitem + 3 szybkie merge forward. 5 minut roboty.
"Zamiast zrobić rebase swojego lokalnego mastera na originie wbija z merge commitem. Po co?" Odwrócę pytanie - a w czym to szkodzi? Jak masz w projekcie >100 devów i commity wchodzą do mastera dosłownie co chwilę, to może być ciężko wstrzelić się z fetch + rebase + push zanim ktoś nie zmieni czegoś na serwerze. A jak coś zmienił, to od początku. Strata czasu, bez żadnego celu. Dla odmiany zrobienie pusha z mergem to kliknięcie jednego zielonego guzika na GitHubie. Notabene, inny sposób pushowania niż przez kliknięcie zielonego guzika nie jest dozwolony.
Szkodzi w tym, że historia jest zasyfiona zbędnymi commitami, które niczego nie wnoszą. A programistów mamy kilku, więc problemu z wstrzeleniem się nie ma. Ja rozumiem, że Wy macie inne potrzeby, więc macie inne procesy i inaczej też używacie Gita, tylko to nie znaczy, że to jest jedyna słuszna droga.
Na pewno nie domagałbym się squashów i rebase gdybym musiał te same ficzery/fixy aplikować do wielu wersji produktu. Ale jeśli mój obecny produkt ma raptem dwie wersje, które na dodatek są ze sobą niekompatybilne zupełnie (w v2 usunęliśmy wszystkie wypaczenia v1), i to jest naprawdę prosta aplikacja, to nie ma powodu, aby nie starać się utrzymać czytelnej historii. No i w ogóle abstrahując od problemu czytelności i organizacji pracy - czy ktoś, kto nie wie z istnienia rebase, squash i fast-forward zna Gita? No chyba nie.
Nie zna całego Gita (mało kto zna), ale nie oznacza to, żeby go od razu wrzucać do jednego worka z SVNowcami. Rebase i squash są bardzo kontrowersyjnymi specyficznymi ficzerami gita. Inne rozproszone systemy wersji np. Mercurial ich celowo nie mają. Ale fakt, że przy kilku devach i dwóch wersjach to nie ma niebezpieczeństwa. Z drugiej strony nie sądzę, aby te merge-commity tak przeszkadzały. Po prostu trzeba się przestawić na myślenie o historii jako o grafie skierowanym, a nie o liście jak w SVN.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
1
U mnie 99% GUI - GitKraken - ze względu na to że działa wyśmienicie na Linux.
Konsola to jak mam jakąś roz...e.
Co innego SVN - 90% konsola, 10% GUI (TortoiseSVN) - do podglądania / filtrowania listy ostatnich zmian. Niestety nie znalazłem fajnego GUI dla Linuxa.
GitKraken to jedyne sensowne rozwiązanie niestety. Przejrzałem 4 inne i wszystko kulawe. Szkoda trochę, że brakuje klienta github na Linux - na Windows bardzo fajne narzędzie i nawet na MacOS dostępne...
- Rejestracja:prawie 8 lat
- Ostatnio:ponad 7 lat
- Postów:28
0
Dla przeciętnego zjadacza chleba do codziennych zadań i za darmo polecam w tym zakresie TortoiseGit dla gita, TortoiseSVN dla SVNa i TortoiseHg dla Mercuriala. W przypadku Hg - program wyświetla nawet wydawane polecenie Hg, więc można się szybko nauczyć korzystać też z linii komend.
- Rejestracja:ponad 10 lat
- Ostatnio:5 miesięcy
- Lokalizacja:Warszawa
- Postów:3573
0
Terminal Linuxowy do wszystkiego co nie jest porównywaniem zmian, a to w IntelliJ
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
1
@Krzywy Programista coś kręcisz bo integracja z gitem w IntelliJ jest od dawna i jest bardzo dobra, więc nawet AndroidStudio oparte o wersje o rok w tył powinno być dobre. W sumie nie widziałem nic lepszego niz to co oferuje IntelliJ.
edytowany 1x, ostatnio: Shalom