Learn the Basics of Git in Under 10 Minutes

by Gowtham Venkatesan

Tak, tytuł jest clickbaitem. Nie ma możliwości, abyś zrozumiał podstawy technologii git w zaledwie 10 minut. Ale możesz zbliżyć się całkiem blisko w około 25 minut. I to jest właśnie cel tego artykułu.

Jeśli chcesz rozpocząć naukę o technologii Git, trafiłeś we właściwe miejsce. Jest to kompleksowy przewodnik dla początkujących po Gicie. Istnieje wiele klientów dla Gita. Technologia jest taka sama bez względu na klienta. Ale w tym przewodniku będziemy używać GitHub’a aby zrozumieć Git’a.

Zacznijmy!

Co to jest Kontrola Wersji?

Kontrola wersji to system, który rejestruje zmiany w pliku lub zestawie plików w czasie tak, że można przywołać konkretne wersje później. Idealnie więc, możemy umieścić dowolny plik w komputerze na kontroli wersji.

Umm… Okay… But Why Tho?

Oto dlaczego:

System Kontroli Wersji (VCS) pozwala na przywrócenie plików do poprzedniego stanu, przywrócenie całego projektu do poprzedniego stanu, przeglądanie zmian dokonanych w czasie, sprawdzenie kto ostatnio zmodyfikował coś co może być przyczyną problemu, kto i kiedy wprowadził problem i wiele więcej. Używanie VCS oznacza również, że jeśli coś spieprzysz lub stracisz pliki, możesz to łatwo odzyskać. A czasami po prostu chcesz wiedzieć „kto napisał to gówno”, i posiadanie dostępu do tych informacji jest warte zachodu.

Co to jest Git?

Git jest systemem kontroli wersji do śledzenia zmian w plikach komputerowych i koordynowania pracy nad tymi plikami wśród wielu osób. Git jest rozproszonym systemem kontroli wersji. Tak więc Git nie musi polegać na centralnym serwerze do przechowywania wszystkich wersji plików projektu. Zamiast tego, każdy użytkownik „klonuje” kopię repozytorium (zbiór plików) i ma pełną historię projektu na własnym dysku twardym. Ten klon posiada wszystkie metadane oryginału, podczas gdy sam oryginał jest przechowywany na własnym serwerze lub w zewnętrznym serwisie hostingowym, takim jak GitHub.

Git pomaga śledzić zmiany, które wprowadzasz w swoim kodzie. Jest to w zasadzie zakładka historii dla twojego edytora kodu (bez trybu incognito?). Jeśli w dowolnym momencie podczas kodowania trafisz na fatalny błąd i nie wiesz co jest jego przyczyną, zawsze możesz powrócić do stanu stabilnego. Jest to więc bardzo pomocne przy debugowaniu. Możesz też po prostu zobaczyć jakie zmiany wprowadziłeś do swojego kodu w czasie.

W powyższym przykładzie wszystkie trzy karty reprezentują różne wersje tego samego pliku. Możemy wybrać, z której wersji pliku chcemy korzystać w danym momencie. Mogę więc przeskakiwać do i z dowolnej wersji pliku w kontinuum czasowym git.

Git pomaga również synchronizować kod pomiędzy wieloma osobami. Więc wyobraź sobie, że ty i twój przyjaciel współpracujecie nad projektem. Oboje pracujecie nad tymi samymi plikami projektu. Teraz Git bierze te zmiany, które Ty i Twój znajomy wprowadziliście niezależnie i łączy je w jedno repozytorium „Master”. Tak więc używając Gita możesz mieć pewność, że obaj pracujecie nad najnowszą wersją repozytorium. Nie musisz się więc martwić o wysyłanie plików do siebie nawzajem i pracę ze śmieszną liczbą kopii oryginalnego pliku. A współpraca na odległość staje się tak prosta jak HTML ?.

Git Workflow:

Zanim zaczniemy pracować z komendami Git, konieczne jest, abyś zrozumiał, co on reprezentuje.

Co to jest repozytorium ?

Repozytorium a.k.a. repo to nic innego jak zbiór kodu źródłowego.

W Git Workflow występują cztery podstawowe elementy.

Katalog roboczy, obszar staging, lokalne repozytorium i zdalne repozytorium.

Jeśli weźmiemy pod uwagę plik w Katalogu Roboczym, może on być w trzech możliwych stanach.

1. Może być etapowany. Co oznacza, że pliki z uaktualnionymi zmianami są oznaczone do wysłania do lokalnego repozytorium, ale jeszcze nie wysłane.
2. Może być zmodyfikowany. Co oznacza, że pliki z uaktualnionymi zmianami nie są jeszcze przechowywane w lokalnym repozytorium.
3. Może być popełniony. Co oznacza, że zmiany, które wprowadziłeś do swojego pliku są bezpiecznie przechowywane w lokalnym repozytorium.

• git add Jest to polecenie używane do dodania pliku, który znajduje się w katalogu roboczym do obszaru inscenizacji.
• git commit to polecenie używane do dodawania wszystkich plików, które są inscenizowane do lokalnego repozytorium.
• git push to polecenie używane do dodawania wszystkich popełnionych plików w lokalnym repozytorium do zdalnego repozytorium. Tak więc w zdalnym repozytorium, wszystkie pliki i zmiany będą widoczne dla każdego, kto ma dostęp do zdalnego repozytorium.
• git fetch jest poleceniem używanym do pobierania plików ze zdalnego repozytorium do lokalnego repozytorium, ale nie do katalogu roboczego.
• git merge to komenda służąca do pobierania plików z lokalnego repozytorium do katalogu roboczego.
• git pull to komenda służąca do pobierania plików ze zdalnego repozytorium bezpośrednio do katalogu roboczego. Jest ono odpowiednikiem polecenia git fetch oraz git merge .

Teraz, gdy wiemy już czym jest Git i jakie są jego podstawowe terminologie, zobaczmy jak możemy umieścić plik pod git. Zrobimy to we właściwy i trudny sposób. Bez żadnych aplikacji GUI.

Zakładam, że masz już plik, który chcesz umieścić pod kontrolą wersji. Jeśli nie, utwórz przykładowy folder o nazwie 'MuskCult' i umieść w nim kilka przykładowych plików z kodem.

Krok 0: Załóż konto GitHub. Duh.

Jeśli jeszcze go nie masz, możesz je założyć tutaj.

Krok 1: Upewnij się, że masz zainstalowanego Gita na swoim komputerze.

Jeśli jesteś na Macu, odpal terminal i wpisz następujące polecenie:

$ git --version

To spowoduje otwarcie instalatora, jeśli nie masz jeszcze Gita. Więc skonfiguruj go używając instalatora. Jeśli masz już git, to po prostu pokaże ci, którą wersję git masz zainstalowaną.

Jeśli używasz Linuksa(deb), wpisz następujące polecenie w terminalu:

$ sudo apt install git-all

Jeśli używasz Windowsa:

$ get a mac

Żartowałem… Spokojnie… Ilość ludzi, których wywołałem… Phew…
Przejdź do tego linku lub tego linku po więcej informacji, jak go zdobyć.

Krok 2: Powiedz Gitowi kim jesteś.

Przedstaw się. Wsuń się. Poważnie, wspomnij o swojej nazwie użytkownika Git i adresie e-mail, ponieważ każdy commit Git użyje tych informacji, aby zidentyfikować cię jako autora.

$ git config --global user.name "YOUR_USERNAME" 

$ git config --global user.email "[email protected]"

$ git config --global --list # To check the info you just provided

Krok 3: Wygeneruj/sprawdź, czy na twoim komputerze nie ma już kluczy SSH. (Opcjonalnie)

Dlaczego pytasz? Używając protokołu SSH, możesz łączyć się i uwierzytelniać ze zdalnymi serwerami i usługami. Dzięki kluczom SSH możesz połączyć się z GitHubem bez konieczności podawania nazwy użytkownika lub hasła przy każdej wizycie.

Przejdź za ten link, aby dowiedzieć się więcej o SSH.
Przejdź tutaj, aby sprawdzić, czy masz istniejący klucz SSH.
Przejdź tutaj, aby wygenerować klucz SSH.
Przejdź tutaj, aby dodać klucz SSH do konta GitHub.
I wreszcie przejdź tutaj, aby przetestować połączenie.

Jeśli skonfigurowałeś SSH, każde polecenie git, które ma link zastąpisz:

Instead of : https://github.com/username/reponame

You use : [email protected]/username/reponame.git

 Note : You can use both ways alternatively

W tym tutorialu będę używał protokołu SSH.

Krok 4: Let’s Git

Utwórz nowe repozytorium na GitHub. Podążaj za tym linkiem.
Teraz, zlokalizuj folder, który chcesz umieścić pod git w swoim terminalu.

$ cd Desktop/MuskCult

Initialize Git:

I aby umieścić go pod git, wpisz:

$ touch README.md # To create a README file for the repository$ git init # Initiates an empty git repository

Teraz przejdź do edycji pliku README.md, aby dostarczyć informacji o repozytorium.

Dodaj pliki do repozytorium git w celu popełnienia błędu:

Teraz dodajemy pliki do repozytorium git w celu popełnienia błędu:

$ git add . # Adds all the files in the local repository and stages them for commit

OR if you want to add a specific file

$ git add README.md # To add a specific file

Zanim popełnimy błąd, zobaczmy jakie pliki są wystawione:

$ git status # Lists all new or modified files to be committed

Commit Changes you made to your Git Repo:

Teraz do commitowania plików, które dodałeś do swojego git repo:

$ git commit -m "First commit"# The message in the " " is given so that the other users can read the message and see what changes you made

Uncommit Changes you just made to your Git Repo:

Teraz przypuśćmy, że właśnie popełniłeś jakiś błąd w swoim kodzie lub umieściłeś niechciany plik wewnątrz repozytorium, możesz unstage’ować pliki, które właśnie dodałeś używając:

$ git reset HEAD~1# Remove the most recent commit# Commit again!

Dodaj zdalny origin i Push:

Teraz za każdym razem, gdy dokonasz zmian w swoich plikach i zapiszesz go, nie będzie on automatycznie aktualizowany na GitHubie. Wszystkie zmiany, które wprowadziliśmy w pliku są aktualizowane w lokalnym repozytorium. Teraz, aby zaktualizować zmiany do mastera:

$ git remote add origin remote_repository_URL# sets the new remote

Komenda git remote pozwala tworzyć, przeglądać i usuwać połączenia z innymi repozytoriami.

$ git remote -v# List the remote connections you have to other repositories.

Komenda git remote -v wyświetla adresy URL zdalnych połączeń, które posiadasz z innymi repozytoriami.

$ git push -u origin master # pushes changes to origin

Teraz polecenie git push popycha zmiany w twoim lokalnym repozytorium do zdalnego repozytorium, które określiłeś jako źródło.

A teraz, jeśli pójdziemy i sprawdzimy stronę naszego repozytorium na GitHubie, powinna ona wyglądać tak jak poniżej:

I to by było na tyle. Właśnie dodałeś pliki do repozytorium, które właśnie utworzyłeś na GitHub.

Zobacz zmiany, które wprowadziłeś w swoim pliku:

Gdy zaczniesz wprowadzać zmiany na swoich plikach i je zapiszesz, plik nie będzie odpowiadał ostatniej wersji, która została popełniona w git. Aby zobaczyć zmiany, które właśnie wprowadziłeś:

$ git diff # To show the files changes not yet staged

Przywróć z powrotem do ostatniej wersji przekazanej do Git Repo:

Teraz możesz wybrać przywrócenie do ostatniej popełnionej wersji, wpisując:

$ git checkout .

OR for a specific file

$ git checkout -- <filename>

View Commit History:

Możesz użyć polecenia git log, aby zobaczyć historię commitów, których dokonałeś w swoich plikach:

$ git log

Za każdym razem, gdy dokonujesz zmian, które chcesz, aby zostały odzwierciedlone na GitHubie, poniżej znajdują się najczęściej wykonywane polecenia przepływu:

$ git add .$ git status # Lists all new or modified files to be committed$ git commit -m "Second commit"$ git push -u origin master

Teraz, jeśli pójdziemy i zobaczymy nasze repo, możemy zidentyfikować, czy commit zakończył się sukcesem, patrząc na komunikat commit dla każdego pliku.

Krok 5: To wszystko dobrze… Ale jak pobrać i pracować na innych repozytoriach na GitHubie?

Klonowanie Git Repo:

Znajdź katalog, do którego chcesz sklonować repo. Skopiuj link repozytorium, które chcesz i wprowadź następujące dane:

$ git clone remote_repository_URL

Nie krępuj się i sklonuj repo, które utworzyłem powyżej używając: https://github.com/Gothamv/MuskCult

Przesuwanie zmian do Git Repo:

Teraz możesz pracować nad plikami, które chcesz i popełniać zmiany lokalnie. Jeśli chcesz popchnąć zmiany do repozytorium, musisz albo zostać dodany jako współpracownik repozytorium, albo stworzyć coś znanego jako pull request. Idź i sprawdź jak to zrobić tutaj i daj mi pull request ze swoim kodem.

Współpraca:

Wyobraź sobie, że ty i twój przyjaciel współpracujecie nad projektem. Oboje pracujecie nad tymi samymi plikami projektu. Za każdym razem, gdy wprowadzasz jakieś zmiany i wrzucasz je do głównego repo, twój przyjaciel musi wyciągnąć zmiany, które wrzuciłeś do repo git. Oznacza to, że aby upewnić się, że pracujesz nad najnowszą wersją repo git za każdym razem, gdy zaczynasz pracę, polecenie git pull jest drogą do zrobienia.

Teraz poniżej znajduje się przykład projektu, nad którym współpracujemy z moim przyjacielem:

Więc, aby upewnić się, że te zmiany są odzwierciedlone na mojej lokalnej kopii repo:

$ git pull origin master

Oto dwie kolejne przydatne komendy git:

$ git fetch AND$ git merge

W najprostszych słowach, git fetch po którym następuje git merge equals a git pull. Ale w takim razie dlaczego one istnieją?

Gdy używasz git pull, Git próbuje automatycznie wykonać pracę za ciebie. Jest wrażliwy na kontekst, więc Git połączy wszystkie pociągnięte zobowiązania do gałęzi, w której aktualnie pracujesz. git pull Automatycznie scala zobowiązania, nie pozwalając ci ich najpierw przejrzeć.

Gdy git fetch, Git zbiera wszelkie zobowiązania z gałęzi docelowej, które nie istnieją w twojej bieżącej gałęzi i przechowuje je w twoim lokalnym repozytorium. Jednak nie łączy ich z twoją bieżącą gałęzią. Jest to szczególnie przydatne, jeśli musisz utrzymywać swoje repozytorium w stanie aktualnym, ale pracujesz nad czymś, co może się zepsuć, jeśli zaktualizujesz swoje pliki. Aby zintegrować commit’y z gałęzią główną, używasz git merge.

Jeszcze jedno:

.gitignore

Co to jest?

.gitignore Mówi gitowi, które pliki (lub wzorce) powinien zignorować. Zwykle używa się go, aby uniknąć popełniania przejściowych plików z katalogu roboczego, które nie są przydatne dla innych współpracowników, takich jak produkty kompilacji, pliki tymczasowe tworzone przez IDE itp.

W powyższym przykładzie, pliki takie jak __pycache__, .DS_Store są używane przez system do przechowywania informacji w celu szybszego dostępu. Nie jest to użyteczne dla innych współpracowników. Możemy więc powiedzieć gitowi, aby je ignorował, dodając plik .gitignore.

Użyj polecenia touch, aby utworzyć plik .gitignore:

$ touch .gitignore

I możesz dodać następujące wzorce, aby powiedzieć gitowi, aby ignorował takie pliki.

/*.cmake/*.DS_Store/.user/buildetc. depending upon the files you want git to untrack

I to by było na tyle jeśli chodzi o podstawy. Zostańcie z nami do części 2, w której skupimy się na Branch, Merge, Stash, Rebase itd.

Jeśli podobał Ci się artykuł, nie zapomnij wcisnąć przycisku Clap i upewnij się, że podążasz za mną do części 2.

Referencje :

Dodanie istniejącego projektu do GitHuba za pomocą wiersza poleceń – Dokumentacja użytkownika
Umieszczenie istniejącej pracy na GitHubie może pozwolić Ci na dzielenie się i współpracę na wiele wspaniałych sposobów. Jeśli migrujesz swoją…help.github.comJak cofnąć (prawie) wszystko w Gicie
Jedną z najbardziej użytecznych cech każdego systemu kontroli wersji jest możliwość „cofnięcia” swoich błędów. W Gicie, „cofnij”…blog.github.comGit w linii poleceń – Nie bój się popełnić 0.3 dokumentacja
Są inne sposoby instalacji Gita; możesz nawet uzyskać graficzną aplikację Git, która będzie zawierała linię poleceń…dont-be-afraid-to-commit.readthedocs.ioStart using Git on the command line | GitLab
Dokumentacja dla GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.docs.gitlab.comJaka jest różnica między 'git pull' a 'git fetch'?
Uwaga moderatora: Biorąc pod uwagę, że na to pytanie pojawiło się już sześćdziesiąt siedem odpowiedzi (niektóre z nich zostały usunięte)…stackoverflow.com