git
[GIT] Jak poradziś sobie ze znakami końca linii (.gitattributes)
Już kiedyś o tym pisałem tylko z tamtego wpisu muszę wywalić że autocrlf.true jest dobre: Rozwiązanie CRLF dla git (znaki końca linii w Windows)
Na różnych systemach znaki końca linii są inne (Windows – CRLF, Unix – LF, Mac – CR).
Więc podczas zapisywania historii plików potrzebna jest standard jak to zapisywać. Tym standardem jest LF. Podczas wyciągania takich plików z repo na dysk następują na Windowsie zmiana na CRLF a na Macu na CR. Podobnie w drugą stronę, pliki na Windowsie edytowane z CRLF podczas zapisu do repozytorium zostaną zamienione na LF.
Kiedyś, żebo to zrobić to ustawiało się opcję autocrlf.true globalnie dla systemu. Teraz już tak nie należy robić, trzeba to zrobić w repozytorium. Żeby to dobrze zrobić na dziś dzień korzysta się z plików .gitattributes.
Poniżej taki plik jako gist, którego sobie będę utrzymywał:
Chcę wrzucić commita na nie mój projekt na githubie
– Forkuję ten projekt.
– clonuję mojego forka.
– ustawiam nowy remote wskazujący na oryginalne repo (to tak bardziej na przyszłość) – nazywam go upstream
– tworzę brancha (konwencją dowolna, byle się nazywał podobnie jak Pull Request który zrobię)
– wrzucam moje zmiany
– robię Pull Request z mojego brancha na mastera w oryginalnym repo.
– gdy master oryginalny posuwa się do przodu to się z nim synchronizuję: ‘git checkout master; git reset –hard upstream/master’
!!! nie działa w C:\Work\GitHub\Tellurium\.git – nie wiem jak zrobić update do upstream/master
Materiały po Git szkoleniu
Tutorial i rzeczy, które fajnie rozwiązać żeby się więcej nauczyć:
https://learngitbranching.js.org
https://onlywei.github.io/explain-git-with-d3/
https://github.com/SkillsTemple/git-devWarsztaty-rebase
Ksiązka o gicie, jest też polska wersja:
https://git-scm.com/book/en/v2
http://files.zeroturnaround.com/pdf/zt_git_cheat_sheet.pdf
Pozostałe:
http://ohshitgit.com/
https://stackoverflow.com/questions/2596805/how-do-i-make-git-use-the-editor-of-my-choice-for-commits
najczęściej będzie to “git config –global core.editor notepad”
KDiff3:
https://krzysztofmorcinek.wordpress.com/2016/03/01/git-rozwiazywanie-konfliktow/
https://krzysztofmorcinek.wordpress.com/2016/02/16/git-i-poprawianie-commitow-z-poziomu-source-tree/
Bardzo ważne o tym jak nazywać commity:
https://chris.beams.io/posts/git-commit/
Sa różne flow, którymi można pracować w gicie. Dla potrzeb, które macie najlepiej sprawdza się https://trunkbaseddevelopment.com/
Aliasy i inne:
Jak sprawdzić jakie znaki końca linii (Line Endings) są w zdalnym repozytorium
Ustawić globalnie aby autoCrlf było takie że nic nie zmienia znaków końca linii (“core.autocrlf” is set to “false”).
Wywalić plik .gitattributes z repozytorium.
Sprawdzić co dostaniemy po git clone.
[GIT] Szybkie przechodzenie między repozytoriami w konsoli
Idziemy do katalogu z zainstalowanym GITem do folderu etc (C:\Program Files\Git\etc).
Jest tam plik bash.bashrc.
Plik edytujemy jako administrator i na końcu dodajemy aliasy:
To samo można uzyskać na wiele innych sposobów (ten akurat działa w mojej konfiguracji systemu). Ten tutaj sprawia, przy otwieraniu konsoli gitowej dodane zostaną do basha aliasy. Dzięki temu możemy wyjść poza to co można dodać w .gitconfig i możemy korzystać z łączenia z komendami konsolowymi takimi jak grep w przykładzie.
Niech commit sobie odczeka
Jako że korzystam z GITa mogę zrobić taki scenariusz:
– robię commit (kilka commitów)
– biorę się za nastepny task
– w międzyczasie pojawia się obiad
– wracam po obiedzie
– ściągam najnowszą histori i robię rebase moich commitów (‘git pull –rebase’, gdzie wystarcza ‘git pull’, bo opcja rebase mam defaultowo włączoną)
– przeglądam commity zanim je wpushuje !!! i tutaj dzieją się fajne rzeczy. Zauważam jakiś bug, zauważam czego zapomniałem, co mogę czytelniej napisać. I do publicznej historii trafia kod po prostu lepszy.
W tym przykładzie nieistotne jest czy pushuje bezpośrednio na brach “develop” czy tworzę branch pod PR i code review.
