Czasami widzę w ogłoszeniach wymagania typu: oczekujemy znajomości Git.
Spoko. Zainstalowałem to u siebie i pobawiłem się.
Wiem już:
Czy mogę już wpisać do CV znajomość Git? O to chodzi autorowi ogłoszenia?
Znajomość GIT to chyba taka abyś umiał się poruszać w projekcie w różnych sytuacjach(nie tylko commit push) lub wiedział czego masz ewentualnie szukać, pytanie czy to co zrobiłeś powyżej na to wystarczy
Jak wiesz co to fetch, pull, commit, push, merge i czym się różni merge od rebase to śmiało możesz wpisać GIT do CV.
Pinek napisał(a):
Jak wiesz co to
fetch,pull,commit,push,mergei czym się różnimergeodrebaseto śmiało możesz wpisaćGITdo CV.
Mnie ostatnio spytali czym się różni fetch od pull i nie wiedziałem bo zawsze robie pull --rebase , ale już doczytałem. Taki wstyd XD
Jeszcze czasem o cherry-pick pytają
Jak przejdziesz https://learngitbranching.js.org to umiesz gita.
Poza tym gitem to się nie bawi tylko korzysta na co dzień, niezależnie od wielkości projektu czy tego czy to jakiś pet project czy komercyjny. Jeśli nie dostrzegasz tego to nie umiesz gita.
To co wyzej plus dodatkowo:
Dodatkowo takie juz troszke z "dzialki devopsa" troszke podchodzace pod "release management" ale mocno sie z gitem laczy wiec tez dopisze:
Ja miałem dziś na rozmowie pytanie o typowy git flow. Czyli (nie wiem czy dobrze teraz to wytłumaczę), ze masz dwie linie, jedna to main/master branch, druga to dev/staging branch. Od staging idą do zewnątrz features, które wracają z powrotem na staging, a jeszcze ze staging w strone main idą (tu się mogę pomylić, bo nie wiem jak to ująć) zmiany na testy i albo merge z masterem wtedy albo powrót na staging
Nie wiadomo, o co chodzi autorowi ogłoszenia. Trzeba by go zapytać. Podstawy gita można opanować w 15 minut, ale można się też z tego toola doktoryzować latami. Podejrzewam, że chodzi o podstawową znajomość pozwalającą na pracę w projekcie. Wg mnie znajomość gita, to byłoby przynajmniej: init, commit, push, pull, fetch, rebase, interactive rebase, cherry-pick, log, stash, reset, nawigacja po historii (~ i ^), konfiguracja (.gitconfig), wiedza co to jest staged/unstaged area oraz umiejętność korzystania z gita z poziomu samej konsoli bez tych wszystkich okienkowych programików, gdzie każdy działa inaczej i ma inne nazwy poleceń/opcji. Warto też znać i rozumieć wspomniany git flow oraz mieć świadomość dobrego opisu wiadomości w commitach.
ile razy w życiu ribejzowaliście? xD serio pytam. ja na 6 lat pracy chyba raz.
TerazOdpowiemNaKomcie napisał(a):
ile razy w życiu ribejzowaliście? xD serio pytam. ja na 6 lat pracy chyba raz.
średnio 5 razy w tygodniu
TerazOdpowiemNaKomcie napisał(a):
ile razy w życiu ribejzowaliście? xD serio pytam. ja na 6 lat pracy chyba raz.
Przed kazdym mergem do maina
TerazOdpowiemNaKomcie napisał(a):
ile razy w życiu ribejzowaliście? xD serio pytam. ja na 6 lat pracy chyba raz.
Przed zmianą pracy w sumie wcale. Aktualnie minimum raz dziennie. Deploye na prod mamy kilka razy dziennie, każdy task jak skończony to zaraz tam idzie.
Jak głosi stare ludowe chińskie powiedzenie, "Rebase w projektach gdzie jest więcej niż dwóch devów to zło".
jackson-mike napisał(a):
Jak głosi stare ludowe chińskie powiedzenie, "Rebase w projektach gdzie jest więcej niż dwóch devów to zło".
Przeciez Twoj branch jest prywatny, lol
Nikt nie mowi o rebase'owaniu maina.
Pracujecie w kilka osob na jednym branchu?
stivens napisał(a):
jackson-mike napisał(a):
Jak głosi stare ludowe chińskie powiedzenie, "Rebase w projektach gdzie jest więcej niż dwóch devów to zło".
Przeciez Twoj branch jest prywatny, lol
Nikt nie mowi o rebase'owaniu maina.Pracujecie w kilka osob na jednym branchu?
Widocznie w chinach na prowincji są niedobory branchy i pracują po kilku :D
To chyba coś źle robie, ale nadal działa, więc nie zmieniam :P
https://blog.carbonfive.com/always-squash-and-rebase-your-git-commits/
https://medium.com/swlh/squash-and-rebase-git-basics-5cb1be1e0dac
VS
Ktore wolicie? ;)
Przy czym sam squash jest opcjonalny*
stivens napisał(a):
Pracujecie w kilka osob na jednym branchu?
No u mnie czasem się zdarza, że ktoś zacznie taska, a kto inny go dokańcza. Jakiś problem?
Widzę, że dyskusja taby vs spacje się już przejdały więc nowy temat merge z rebesem czy bez xD.
Może doczepię się - z jakich ksiązek uczyliście się gita, albo raczej które są dobre - Znalazłem taką "Learn Git in a Month of Lunches" wydawnictwo Manning - czy będzie dobra? Niestety na podglądzie amazona jest tylko spis treści więc nie mogę się zapozna
Edycja: można spojrzeć na zawartość tej książki tu: https://www.manning.com/books/learn-git-in-a-month-of-lunches
Ja się uczyłem gita z oficjalnej dokumentacji. Nawet do głowy mi nie przyszło żeby kupować papierowe książki do tego :D
@KamilAdam: książka? Książka to jest nic. O gicie można całe kursy robić i klepać na nich fortunę https://kursgita.pl/
Ja bym brał, teraz jest promka, tylko 299 zł zamiast 599 zł.
Ja uczyłem się używając go, a jak nie umiałem czegoś zrobić, to szukałem informacji w instrukcji bądź w internecie.
Czysty kod napisał(a):
z jakich ksiązek uczyliście się gita
IMO jeśli przerobisz książkę do Gita a nie będziesz z niego korzystał, to nie ma większego sensu.
Czysty kod napisał(a):
z jakich ksiązek uczyliście się gita
To są takowe?! :)
Poważnie: gita używa się na co dzień (sprawdzając co potrzeba w świetnej dokumentacji -- https://git-scm.com/), nawet jak pracujesz (nie tylko "programujesz"!) sam, nawet jak tylko lokalnie (na jednej maszynie). Ja gituje wszystko co robię (różne commity zwykle kilka razy dziennie), nawet jeśli nie porządnie -- lepsza jakakolwiek historia roboty (i nie raz mi się przydała) niż żadna...
Ja byłbym za popularyzacją gita od najmłodszych lat -- bo dzieci zaczynają wcześnie tworzenie różnych rzeczy na komputerach, nie mówiąc o programowaniu od przedszkola... :)