Witam,
Jeśli znam gita i svna, ale jedynie w GUI to czy liczy się to jako znajomość gita i svna? Czy pracodawcom chodzi o konsolową znajomość gita jeśli piszą, że wymagają znajomości gita?
0
5
Pewnie każdemu o co innego :) Wystarczy wiedzieć co to branche i znać jakieś podstawowe pojęcia typu push, pull, commit, checkout, stash itp. Czy robisz to z gui czy z konsoli nie powinno mieć znaczenia, chyba że na jakiegoś devopsa
0
Jako, że ostatnio poszukiwałem nowej pracy i odbyłem chyba z 6 rozmów podpowiem, że raczej nie należy się tym przejmować. Na żadnej z nich mnie o to nie spytano. To jest 30 min szkolenia żeby zrozumieć i zobaczyć o co chodzi z tym "gitem".
0
No raczej pracodawcom chodzi o konsolową. Zreszta akurat ja lubie bardziej konsolową (poza diffami, to tego służy mój ukochany IntelliJ Idea)
1
Widziałem już "Senior Developerów", którzy konsolki gita nie tykają i tylko klikają po GUI oraz "Junior Developerów", którzy wymiatają w konsolce. Sam sobie teraz odpowiedz na to pytanie ;-). IMO ważne, żebyś rozumiał, co robisz, a to czy jest to GUI, czy konsolka, to raczej sprawa drugorzędna. Oczywiście, te wszystkie programiki do gita robią różne rzeczy pod spodem bez pytania i czasami nazewnictwo interfejsu GUI jest niespójne z komendami gita, co może wprowadzać w błąd. Z moich obserwacji wynika, że jeśli ktoś miał w pracy jakiś problem z gitem lub czegoś nie rozumiał, to był to najczęściej użytkownik apki w GUI lub początkujący użytkownik konsolki. W związku z tym, konsolka FTW.
3
Ogarniesz te parę komend z konsoli, mało czasu ci to zajmie, a to ci się w życiu przyda. Z GUI jest taki problem, że mając jakieś swoje ulubione GUI niekoniecznie będziesz miał do niego dostęp w pracy. Komendy w konsoli są uniwersalne.
Co do pytań to mnie np. pytali, czym się różni merge od rebase czyli bardziej koncepcyjnie mnie pytano, a nie o znajomość konkretnych komend.
0
Obecnie pracuje od pół roku i jeszcze nie spotkałem nikogo kto by korzystał z konsolowego gita. Może trafiłem akurat na takich ludzi. Zastanawia mnie tylko fakt czy wpisać do cv znajomość gita i svn skoro w obydwu przypadkach korzystałem z interfejsu GUI. Jeszcze rok temu ogarniałem gita w konsoli, ale przerzuciłem się na GUI i większość rzeczy się zapomniało. Jednak na pewno sporo wiedzy mi na temat konsolowego gita zostało.
4
Wesoły Młot napisał(a):
Obecnie pracuje od pół roku i jeszcze nie spotkałem nikogo kto by korzystał z konsolowego gita. Może trafiłem akurat na takich ludzi. Zastanawia mnie tylko fakt czy wpisać do cv znajomość gita i svn skoro w obydwu przypadkach korzystałem z interfejsu GUI. Jeszcze rok temu ogarniałem gita w konsoli, ale przerzuciłem się na GUI i większość rzeczy się zapomniało. Jednak na pewno sporo wiedzy mi na temat konsolowego gita zostało.
Obecnie pracuję 8 lat, i używam gita z konsoli (podobnie zresztą koledzy z pracy). Wpisywał bym znajomość gita w CV jeśli znałbym odpowiedzi na następujące pytania:
- Coś skopałem, skąd wezmę reflog, i jak się cofnę do jakiegoś w nim miejsca bez utraty zmian w plikach?
- Mam 4 branche, umiem połączyć je w jeden bez generowania nadmiernej ilości commitów?
- Zmiany z repo lokalnego i brancha lokalnego chcę sobie wysłać na repo zdalne inne niż origin i na inny branch zdalny (o innej nazwie), dam radę?
- Znam jakieś sposoby do przerzucenia samego commitu/zmian wybranego pliku pomiędzy branchami?
Wszystkie te rzeczy z konsoli robi się dość prosto, nie wiem jak z gui?
0
Świetny Kot napisał(a):
Jako, że ostatnio poszukiwałem nowej pracy i odbyłem chyba z 6 rozmów podpowiem, że raczej nie należy się tym przejmować. Na żadnej z nich mnie o to nie spytano. To jest 30 min szkolenia żeby zrozumieć i zobaczyć o co chodzi z tym "gitem".
A ja byłem ostatnio na rozmowie i byłem o to pytany ale w sensie czy robiłem to już z kimś w teamie.
1
Mam małe doświadczenie komercyjne (~3 lata) i momentami zastanawiam się czy jest sens wpisywać znajomość Git'a / SVN w CV, uważam to za coś tak podstawowego że nie powinno nawet być w wymaganiach jedynie jako informacja z czym będziemy mieć do czynienia w danej firmie :), potem rozmawaim z kimś i się okazuje że można mieć problem z płynną pracą z branchami mając kilka lat doświadczenia :D rozumiem jakieś "bardziej zaawansowane rzeczy" ale niektórym nawet nie przyjdzie do głowy ze można odpalić dokumentacje by znaleźć jak działa jakiś mniej popularny przełącznik do komendy.
Wracając do pytania uważam jak koledzy wyżej powinno znać się tyle by płynnie pracować z poziomu konsoli + ewentualnie znajomość "teorii" działania systemu kontroli wersji by wiedzieć co na szybko znaleźć w dokumentacji jak potrzeba coś zrobić bardziej zaawansowanego albo pomóc w czymś koledze, który coś skopał.
Nakładki GUI służą tylko wygodzie, ale w firmie każdy może korzystać z czegoś innego, wtedy powiedzmy że podchodzisz komuś pomóc, jakieś małe pair programming czy wskazanie czegoś w kodzie i okazuje się że kolega używa np. SourceTree, którego powiedzmy nie znasz bo korzysztasz z żółwika, więc nie powinnno być dla Ciebie problemu odpalić na szybko konsole i zrobić co potrzebujesz.
2
scibi92 napisał(a):
No raczej pracodawcom chodzi o konsolową. Zreszta akurat ja lubie bardziej konsolową (poza diffami, to tego służy mój ukochany IntelliJ Idea)
Bardzo wątpliwe, żeby pracodawcom chodziło o formę interfejsu użytkownika, bo to trochę tak, jakby narzucali skróty klawiaturowe w IDE. Raczej chodzi o wzorce pracy zespołowej przy użyciu Gita, branch per feature, pull requesty, GitHub, niestety często Git Flow, itp.
wiciu napisał(a):
Widziałem już "Senior Developerów", którzy konsolki gita nie tykają i tylko klikają po GUI oraz "Junior Developerów", którzy wymiatają w konsolce.
I tak powinno być. Wymiatający w konsoli seniorzy często mają tendencje do robienia merge conflictów sami ze sobą i pushowania do origina jednego brancha z czterema merge commitami.
Problem z konsolą jest taki, że słabo wizualizuje drzewo historii, więc ludzie jej używający często mają wywalone na to, jak ona wygląda, więc zbędne merge-commity czy jakieś inne zawijasy to dla nich nie jest problem, w końcu go nie widzą.
1
Nie zgodzę się ze słabą wizualizacją, większość osób z którymi pracuję ma aliasy, chociażby log --all --oneline --decorate --graph.
0
Myślę, że mają na myśli znajomość pojęć oraz umiejętność pracy w dowolnej formie (gui lub konsola).
Ja tam osobiście wolę pracę z konsolą z jednego prostego powodu - jak mam się zapytać kogoś o to jak coś zrobić to jednak wolę żeby mi przesłał jedno polecenie niż mówił coś w stylu:
- otwierasz żółwia
- wybierasz x
- po prawej masz y
- klikasz prawym przyciskiem komendę "z"
- ...
Przy czym podstawowe operacje oczywiście są wygodniejsze w IDEA niż konsoli.
0
Marny Jamnik napisał(a):
Nie zgodzę się ze słabą wizualizacją, większość osób z którymi pracuję ma aliasy, chociażby
log --all --oneline --decorate --graph.
Różnica jest taka, że jak odpalasz takie SourceTree to nie musisz nic dodatkowego robić tylko po prostu widzisz to drzewko cały czas. W konsoli musisz wpisać komendę żeby cokolwiek zobaczyć. Nie chodzi raczej o to, że jest brzydko czy mało czytelnie, tylko że nie widać tego na bieżąco.
1
Marny Jamnik napisał(a):
Nie zgodzę się ze słabą wizualizacją, większość osób z którymi pracuję ma aliasy, chociażby
log --all --oneline --decorate --graph.
Ja też lubię ASCII-Art, ale niekoniecznie w pracy, zwłaszcza z monitorem, który wyświetla więcej niż 256 kolorów.
n0name_l napisał(a):
Różnica jest taka, że jak odpalasz takie SourceTree to nie musisz nic dodatkowego robić tylko po prostu widzisz to drzewko cały czas. W konsoli musisz wpisać komendę żeby cokolwiek zobaczyć. Nie chodzi raczej o to, że jest brzydko czy mało czytelnie, tylko że nie widać tego na bieżąco.
A do tego jest koszmarnie brzydkie i nieczytelne.
0
Używanie gita, tylko z poziomu GUI typu SourceTree (bez jego znajomości) jest niczym pisanie w Javie, za pomocą inteliJ, nie znając samej Javy: możliwe i nawet produktywne dla większości standardowych przypadków. Jeden niestandardowy i od razu wiadomo co mamy potem (nic produktywnego).
2
Można być hakierem konsolowym i nigdy nie robić niczego poza commit/pull/push origin. Używanie tego, a nie innego narzędzia nie ma się nijak do znajomości ogólnych koncepcji i doświadczenia.
0
somekind napisał(a):
... commit/pull/push origin ...
Jeszcze add :)
1
Niezależnie od tego jak ludzie korzystają z gita dorzuciłbym jeszcze umiejętność rozwiązywania konfliktów i rozumienia skąd się biorą która zmiany (--ours vs --theirs w przypadku rebase i merge). Również świadomość że to że konfliktów nie było/zostały rozwiązane nie oznacza że kod działa.
3
Pracodawcom raczej chodzi o to, że jak będziesz musiał pracować z gitem, czyli odgałęziać się, robić merge, rebase, rozwiązywać konflikty, przełączać się między gałęziami, porównywać gałęzie itp itd to nie będziesz płakał i panikował tylko robił co do ciebie należy. Oczywiście można zawsze podeprzeć się Googlem czy StackOverflow co jakiś czas w celu uzupełnienia wiedzy. Nie ma sensu uczyć się na pamięć Git Flow czy innego konkretnego sposobu prowadzenia gałęzi, bo i tak zespół będzie miał wypracowany własny model zarządzania gałęziami, a w razie potrzeby zapytanie kolegi podczas robienia brancha lub wystawiania pull requesta do merge'a to maleńki ułamek czasu spędzonego nad zadaniem. W skrócie - masz efektywnie pracować z gitem z użyciem narzędzi dozwolonych w firmie (bo w zabetonowanej korpo nie zawsze da się używać wszystkiego).
Biorąc pod uwagę doświadczenie moje i moich kolegów z korpo mogę powiedzieć, że standardowy konsolowy klient Gita jest najpewniejszym wyborem, tzn nawet jeśli jakiś crapware na (przymusowego w korpo) Windowsa utrudnia pracę z Gitem to klient konsolowy daje radę i można sprawnie robić add, commit, push, pull, checkout, chmod, itp itd Z drugiej strony do wizualizacji używamy narzędzi graficznych (czyli integracji z Gitem dostępnej w IntelliJu), bo są po prostu mega wygodne (przynajmniej w porównaniu do konsolowych ASCII-artów). Zresztą nie tylko wizualizacji, bo jeśli komuś klient graficzny Gita dobrze działa to może używać go do wszystkiego i ominąć konsolę. Ogółem - chodzi o efektywność pracy. Jeśli ktoś jest efektywniejszy w danym zadaniu w konsoli to niech użyje konsoli, jeśli w graficznym narzędziu to niech użyje graficznego narzędzia.