Systemy rozproszone kontrola wersji (DVCS) stopniowo zastępuje scentralizowaną. Jeśli jeszcze nie używasz jednego z nich, teraz jest czas, aby go wypróbować.
W tym artykule postaram się pokazać jak szybko można zacząć eksperymentować z git za pomocą strony github.com.
W tym artykule nie omówimy różnic między różnymi systemami DVCS. Również praca z git nie będzie szczegółowo omawiana, istnieje wiele dobrych źródeł na ten temat, które przytoczę na końcu artykułu.
Tak więc witryna github.com jest pozycjonowana jako usługa sieciowa do hostowania projektów przy użyciu systemu kontroli wersji git, a także sieć społeczna dla programistów. Użytkownicy mogą tworzyć nieograniczoną liczbę repozytoriów, z których każde zapewnia wiki, system śledzenia problemów, możliwe jest przeprowadzanie recenzji kodu i wiele więcej. GitHub włączony ten moment najpopularniejszą usługą tego typu, wyprzedzając Sourceforge i Google Code.
W przypadku projektów typu open source korzystanie ze strony jest bezpłatne. Jeśli potrzebujesz prywatnych repozytoriów, możesz przejść na płatny plan: 
Zacznijmy od rejestracji. Kliknij link github.com/signup/free i wprowadź swoje dane.
Po rejestracji przechodzimy do Panelu naszego konta: 
W tej chwili nie mamy ani jednego repozytorium i możemy albo utworzyć nowe repozytorium, albo rozgałęzić (fork) z już istniejącego repozytorium innej osoby i utrzymywać własną gałąź rozwojową. Następnie, jeśli chcesz, możesz zaoferować swoje zmiany autorowi oryginalnego repozytorium (Pull request).
Ale najpierw zainstalujmy git i skonfigurujmy go do pracy z witryną.
Jeśli korzystasz z systemu Windows, pobierz i zainstaluj msysgit . Jest to konsolowa wersja git dla systemu Windows (dalej historia będzie oparta na przykładzie tego systemu operacyjnego).
Instrukcje dla MacOS X (pol)
Instrukcja dla Linuksa (pol)
Nie powinno być żadnych problemów, po prostu kliknij Dalej wszędzie. Po instalacji wybierz menu kontekstowe Eksplorator Git Bash: 
Lub przez Git Bash.lnk w folderze z zainstalowanym programem: 
Zapisujemy nasze dane i ustawienia podziału linii w konsoli:
git config --global user.name „twoje imię”
git config --global user.email "twoja poczta"
git config --global core.autocrlf prawda
git config --global core.safecrlf prawda
Przy okazji polecam dobry interaktywny kurs korzystania z git z poziomu konsoli. Kurs trwa kilka godzin i zapewnia niezbędne podstawowe umiejętności.
Dla tych, którzy preferują gui, istnieje kilka takich narzędzi do pracy z git dla Windows. Dwa główne to SmartGit (międzyplatformowy) i TortoiseGit. Oba są dobre, a którego użyć, to kwestia gustu. Opiszę pracę z TortoiseGit.
W przypadku maków do wyboru jest również giu.
O gicie po rosyjsku:
„A good branching model for git” - tłumaczenie dobrego artykułu w języku angielskim
interaktywny kurs githowto.com dotyczący pracy z git z poziomu konsoli
"Dlaczego git" + dyskusja
„Git do migracji z SVN” + dyskusja
GitHub – co to jest? Ten zasób jest opartym na sieci Web wersjonowaniem i wspólna praca dla twórców oprogramowania. Dostarczany w modelu biznesowym „oprogramowanie jako usługa”, został uruchomiony w 2008 roku. Zasób jest oparty na Git, systemie zarządzania kodem źródłowym zaprojektowanym w celu przyspieszenia tworzenia oprogramowania.
GitHub to obecnie najpopularniejsza usługa hostingu kodu wśród programistów i programistów.
Git służy do przechowywania kod źródłowy projektuj i śledź pełną historię wszystkich zmian w kodzie. Dzięki temu programiści mogą efektywniej współpracować nad projektem, udostępniając narzędzia do zarządzania możliwymi sprzecznymi zmianami wprowadzonymi przez wielu programistów. Praca z GitHub pozwala na bezpłatne dostosowywanie i ulepszanie oprogramowanie z repozytoriów publicznych, ale pobiera opłaty za repozytoria prywatne z różnymi planami cenowymi. Każde publiczne lub prywatne repozytorium zawiera wszystkie pliki projektu, jak również historię zmian każdego pliku. Repozytoria mogą mieć wielu pracowników i mogą być publiczne lub prywatne.
Platforma ułatwia kodowanie społecznościowe, udostępniając interfejs sieciowy dla repozytorium kodu Git i narzędzi do zarządzania do współpracy. Ten projekt można uznać za poważny społeczny zasób sieciowy dla twórców oprogramowania.
Jak członkowie mogą wspólnie kodować, oceniać swoją pracę, otrzymywać aktualizacje dotyczące konkretnych projektów, komunikować się publicznie lub prywatnie.
Użytkownicy mogą dodawać innych członków do swojego projektu w celu współpracy.
Trzy ważne terminy używane przez programistów w środowisku GitHub.com to fork, pull request i merge.
Fork to repozytorium, z którego zostało skopiowane konto jednego członka na konto innego. To narzędzie pozwala programiście na wprowadzanie zmian bez uszkadzania kodu źródłowego.
Ponieważ GitHub jest intuicyjny i łatwy w użyciu, a jego narzędzia do kontroli wersji są przydatne do współpracy, zasób ten stał się popularny wśród specjalistów z różnych dziedzin, w tym osób niebędących programistami. W szczególności zaczęto go wykorzystywać do pracy nad dokumentami i opracowaniami multimedialnymi. Na przykład projekty dokumentacji, zasoby edukacyjne i inne rodzaje pracy, w których użytkownicy mogą wchodzić w interakcje online i współpracować. GitLab to otwarta alternatywa dla GitHub.com.
Oprócz dobrze znanego produktu GitHub.com, firma założycielska SaaS oferuje wersję lokalną. GitHub Enterprise obsługuje IDE, zintegrowany system narzędzi i wiele innych aplikacje osób trzecich I usług. Zasób oferuje ulepszone funkcje bezpieczeństwa i weryfikacji.
Inne produkty i funkcje aplikacji obejmują:
Większość z was prawdopodobnie słyszała o systemie kontroli wersji git. Dzisiaj przyjrzymy się całej ścieżce od instalacji git do wprowadzenia naszych zmian w zdalnym repozytorium na przykładzie biblioteki OsEngine Najpierw pobierz klienta git z linku i zainstaluj go. Nie pojawią się pytania
powinien, po prostu kliknij Dalej wszędzie. Dalsza interakcja z git zostanie rozważona na przykładzie pracy z klientem konsolowym Kolejnym krokiem jest rejestracja na stronie https://github.com/ . Teraz możemy przystąpić do prac nad OsEngine. W tym celu przejdź do repozytorium projektu i kliknij przycisk Fork w prawym górnym rogu.
Tym działaniem stworzyliśmy fork (innymi słowy branch), który jest przechowywany w repozytorium naszego konta i teraz możemy wprowadzać w nim zmiany bez obawy, że zepsujemy coś w głównym branchu projektu. Co więcej, to właśnie nasze repozytorium na githubie nazwiemy zdalnym repozytorium.
Teraz zacznijmy od samego git i pierwszą rzeczą, którą musimy zrobić, to utworzyć lokalną kopię zdalnego repozytorium na naszym komputerze. Aby to zrobić, przejdź do żądanego folderu, wybierz element Git Bash Here w menu kontekstowym, a konsola się otworzy.
$ git clone „wstaw tutaj niecytowany link”
Rozpocznie się proces kopiowania zdalnego repozytorium do lokalnego, a kopia robocza o nazwie OsEngine pojawi się w bieżącym folderze.
Zanim zaczniesz pracować z git, musisz go skonfigurować. Otwórz git bash, ustaw login i hasło za pomocą poleceń:
$ git config --global user.name "twoje imię"
$ git config --global user.email "twój e-mail"
Poniższe polecenie umożliwia przeglądanie pliku konfiguracyjnego:
$ git config --global --list
Gałęzie w git są takie same jak gałęzie na github. Aby utworzyć nową gałąź, uruchom polecenie w konsoli:
$ git branch żądana nazwa
Aby przełączyć się do tej gałęzi, uruchom polecenie:
$ git nazwa oddziału kasy
aby wrócić do głównej gałęzi, wpisz:
$ git mistrz kasy
zmień nazwę oddziału:
$ git branch -m nowa nazwa
zespół Gałąź $ git pozwala określić w jakim oddziale aktualnie się znajdujemy. Usuwa polecenie rozgałęzienia
$git branch –D nazwa gałęzi
Połączenie gałęzi z główną odbywa się za pomocą polecenia:
$ git merge nazwa gałęzi
Podczas łączenia gałęzi, które zostały zmodyfikowane na różne sposoby identyczne pliki, może dojść do konfliktu i połączenie nie nastąpi. Aby wyjść z tej sytuacji, musisz odpowiednio naprawić te pliki.
Cały sens używania git tkwi w zatwierdzeniach. Zatwierdzenie to tak zwana migawka stanu projektu na określonym etapie.
rozwój. Na przykład: mamy bibliotekę OsEngine, do której dodaliśmy
to nowy wskaźnik i zatwierdziłem, a następnie zdecydowałem się poprawić jakiś plik
silnik i po tym aplikacja się zawiesza lub nie chce działać poprawnie. Do
aby nie wykonywać dodatkowej pracy i nie poprawiać wszystkiego z powrotem, możemy po prostu
cofnięcie do poprzedniego zatwierdzenia, gdy aplikacja działała tak, jak powinna. Odpowiednio
cała praca z git obraca się wokół tworzenia, usuwania, edytowania, scalania
zatwierdzenia i rozgałęzienia.
Załóżmy, że dodaliśmy plik README do projektu, ale przed zatwierdzeniem musimy dodać zmienione pliki do
indeks, tzw. tymczasowe przechowywanie zmian. Odbywa się to w następujący sposób: jeśli chcesz zindeksować jeden plik, wykonujemy
$ git dodaj plik README
a plik README zostanie dodany do indeksu, jeśli chcesz zindeksować wszystkie zaktualizowane i nowe pliki, a następnie wykonaj
$ git dodaj .
Zauważ, że jest z kropką na końcu i spacją przed nią.
Jeśli przypadkowo zindeksowałeś niepotrzebny plik, to komenda git reset pomoże ci usunąć go z indeksu, na przykład usuń plik README z indeksu:
$git reset README
Jeśli zmienisz zdanie na temat zachowania zmian wprowadzonych w pliku, uruchom polecenie
$ git checkout -- nazwa pliku
i powróci do stanu, w jakim znajdował się w momencie ostatniego zatwierdzenia, pamiętaj tylko, że wszystkie zmiany w tym pliku znikną.
Teraz możesz zatwierdzić zmiany, odbywa się to za pomocą polecenia:
$ git commit –m „Tu powinien być cytowany komentarz”
Należy pamiętać, że obecność komentarza jest warunkiem wstępnym. Historię zmian można przeglądać za pomocą polecenia
$gitlog
pokaz $git pokaże tylko ostatnie zmiany. Naciśnij q, aby wyjść z trybu odtwarzania.
Git ma możliwość indeksowania wszystkich zmian i zatwierdzania jednym poleceniem:
$ git commit -a -m "komentarz w cudzysłowie"
A oznacza: dodaj wszystkie zmiany do indeksu przed zatwierdzeniem.
-m: komentarz.
Jeśli chcesz cofnąć ostatnie zatwierdzenie, użyj polecenia:
$ git przywraca GŁOWĘ
Zatwierdzenia liczone są od 0 począwszy od ostatniego, np. jeśli chcesz cofnąć trzecie zatwierdzenie, powinieneś uruchomić:
$ git przywraca HEAD~2
Zespół $ git reset --soft HEAD~3 usunie ostatnie 3 zatwierdzenia i przywróci projekt do stanu czwartego zatwierdzenia, zachowując wszystkie zmiany ostatnich trzech zatwierdzeń w indeksie.
$ git reset -- twardy HEAD~3
całkowicie usunie ostatnie trzy zatwierdzenia.
$ status git - główne polecenie monitorujące stan plików. Pokazuje, czy są zmiany w monitorowanych plikach lub czy istnieją pliki niemonitorowane. Śledzone pliki to te pliki, które znajdują się w poprzednim zatwierdzeniu. Jeśli dodaliśmy nowy plik do projektu, zostanie on uznany za nieśledzony.
Teraz, gdy niezbędne zmiany zostały wprowadzone w lokalnym repozytorium, można je przesłać do zdalnego repozytorium.
Odbywa się to poprzez uruchomienie polecenia:
$ git push mistrz pochodzenia
W takim przypadku będziesz musiał wprowadzić login i hasło z github. Pobieranie może jednak nie nastąpić. Przyczyną może być to, że w zdalnym repozytorium są zmiany, których nie ma w lokalnym. Aby wyjść z sytuacji, musisz podnieść te nowe
zmiany w lokalnym repozytorium za pomocą polecenia:
$git-pull
Aby pozbyć się konieczności każdorazowego wpisywania loginu i hasła podczas wysyłania zmian do zdalnego repozytorium, możesz skorzystać z kluczy SSH. Najpierw musisz wygenerować klucze, uruchamiając polecenie:
$ generator kluczy ssh
Następnie naciśnij enter 3 razy iw domyślnym katalogu C:\Użytkownicy\nazwa_użytkownika\.ssh pojawi się folder z kluczami. Trzeba otworzyć plik
id_rsa typu PUB w dowolnym edytorze tekstu i skopiuj jego zawartość. Następnie przejdź do github w ustawieniach konta
Następnie w kolumnie po lewej stronie wybierz pozycję: Klucze SSH i GPG i naciśnij zielony przycisk po prawej Nowy klucz SSH
ustaw Tytuł, w polu Klucz wklej dane skopiowane z klucza i kliknij 
Po wprowadzeniu wszystkich niezbędnych zmian w zdalnym repozytorium możesz przesłać pull request do głównego repozytorium projektu OsEngine. Po prostu kliknij przycisk Nowe żądanie ściągnięcia
i wtedy
W tym artykule omówiliśmy podstawowe polecenia git, wystarczą one, aby rozpocząć pracę nad projektem OsEngine z wykorzystaniem git i usługi github.
Szczęśliwych zobowiązań!
Szczegółowe wprowadzenie do pracy z Git
Git to rozproszony system kontroli wersji, który umożliwia zapisywanie wszystkich zmian dokonanych w plikach przechowywanych w repozytorium. Zmiany są przechowywane jako migawki, zwane zatwierdzeniami, które mogą być hostowane na wielu serwerach. Pomyśl o tym jak o standardowej chmurze zapasowej na sterydach - nie tylko możesz przywrócić kod w przypadku awarii, ale możesz także przywrócić kod do dowolnego z poprzednich zapisanych stanów. Możesz także łatwo wchodzić w interakcje z innymi programistami - znowu, w jaki sposób wiele osób może pracować nad tym samym plikiem w Dokumenty Google, a programiści mogą jednocześnie pracować na tym samym repozytorium i zapisywać zmiany.
Mimo wszystkich swoich zalet, Git jest niezbędnym narzędziem dla każdego, kto jest zaangażowany lub planuje się rozwijać. W tym artykule przyjrzymy się najbardziej przydatne komendy Git i kiedy ich używać. Pomoże ci również odświeżyć swoją wiedzę, jeśli znasz już Git.
W Git dostępnych jest wiele poleceń, więc warto podzielić je według tematu/powodu użycia. Najpierw przyjrzymy się pracy z Gitem na lokalnej maszynie, ponieważ tam odbywa się większość operacji, a następnie przejdziemy do formatu wielu użytkowników.
Możesz pracować z Gitem zarówno przez wiersz poleceń, jak i przez GUI jak GitHub Desktop. Chociaż wiersz poleceń może być zastraszający dla początkujących programistów, nadal warto się go nauczyć, ponieważ zapewnia więcej opcji niż wiele narzędzi front-endowych.
Zazwyczaj polecenia Git mają postać git<команда> <аргументы>, gdzie argumentem może być ścieżka do pliku. Polecenia mogą mieć również opcje, które są oznaczone jako --<опция>Lub -<однобуквенная опция>. Pozwalają bardziej szczegółowo dostosować działania polecenia. W tym artykule komendy zostaną przedstawione w sposób ogólny, czyli wszystko co jest w<>, będziesz musiał zastąpić je własnymi wartościami.
Jeśli nie wiesz, jak użyć polecenia, możesz otworzyć podręcznik za pomocą git help<команда>a jeśli potrzebujesz tylko przypomnienia, użyj git<команда>-h lub git<команда>--help (--help i -h są równoważne).
Użytkownicy systemu Windows mogą go pobrać stąd.
W systemie macOS (OS X) Git jest częścią narzędzi wiersza poleceń XCode, więc musisz je zainstalować. Aby sprawdzić, czy Git jest dostępny, otwórz terminal i wpisz git --version, aby sprawdzić wersję.
Jeśli używasz Linuksa, użyj polecenie Sudo apt install git-all (dystrybucje oparte na Debianie) lub sudo dnf install git-all (oparte na RPM).
Pierwszą rzeczą do zrobienia po zainstalowaniu Git jest skonfigurowanie nazwy użytkownika i adresu e-mail, ponieważ są one używane do identyfikacji i są przechowywane we wszystkich wykonanych zrzutach ekranu. Te ustawienia, wraz ze wszystkimi innymi, są przechowywane w pliku konfiguracyjnym.
Możesz edytować plik .gitconfig bezpośrednio za pomocą edytora tekstu lub za pomocą polecenia git config --global --edit lub możesz edytować poszczególne pola za pomocą polecenia git config --global<поле> <значение>- interesują nas pola user.name i user.email.
Możesz także skonfigurować edytor tekstu do pisania komunikatów zatwierdzenia przy użyciu pola core.editor. Początkowo używany jest domyślny edytor systemowy, taki jak vi dla systemu Linux/Mac. Pole commit.template pozwala określić szablon, który będzie używany przy każdym zatwierdzeniu.
Istnieje wiele innych pól, ale jednym z najbardziej użytecznych jest alias , który kojarzy polecenie z aliasem. Na przykład git config --global alias.st „status -s” pozwala na użycie git st zamiast git status -s
Polecenie git config --list wyświetli listę wszystkich pól i ich wartości z pliku konfiguracyjnego.
Aby zainicjować nowe repozytorium .git, możesz użyć polecenia git init lub, jeśli chcesz skopiować istniejące, git clone<адрес репозитория> .
Git przechowuje dane jako zestaw lekkich „migawek” znanych jako zatwierdzenia. Przechowują stan systemu plików w pewna chwila czas, a także wskaźnik do poprzedniego zatwierdzenia. Każde zatwierdzenie zawiera unikalną sumę kontrolną, identyfikator, którego Git używa w odniesieniu do zatwierdzenia. Aby śledzić historię, Git przechowuje wskaźnik HEAD, który wskazuje na pierwsze zatwierdzenie (podążamy za łańcuchem zatwierdzeń w Odwrotna kolejność aby przejść do poprzednich zatwierdzeń).
Możemy odnieść się do zatwierdzenia albo poprzez jego sumę kontrolną, albo jego pozycję względem HEAD, na przykład HEAD~4 odnosi się do zatwierdzenia, które ma 4 zatwierdzenia przed HEAD.
Git śledzi pliki w trzech głównych sekcjach:
Wszystkie podstawowe polecenia dotyczące plików sprowadzają się do zrozumienia, w jaki sposób Git zarządza tymi trzema sekcjami. Istnieje powszechne błędne przekonanie, że obszar plików etapowych przechowuje tylko zmiany. Lepiej jest myśleć o tych trzech sekcjach jako oddzielnych systemy plików, z których każdy zawiera własne kopie plików.
Polecenie git status wyświetla listę wszystkich plików, które różnią się między trzema partycjami. Pliki mają 4 stany:
Notatka Plik może być zarówno „zmodyfikowany”, jak i „przemieszczany”, jeśli wersja w katalogu roboczym jest nowsza niż w obszarze przemieszczania, który z kolei jest nowszy niż wersja w HEAD.
Możemy użyć opcji -s w poleceniu git status, aby uzyskać bardziej zwarte wyjście (jedna linia na plik). Jeśli plik nie jest śledzony, czy zostanie wyświetlony? ; jeśli został zmodyfikowany, jego nazwa będzie czerwona, a jeśli został przygotowany, będzie zielony.
Aby zobaczyć same zmiany, a nie zmienione pliki, możesz użyć następujących poleceń:
Jeśli użyjesz argumentu<файл/папка>, wtedy diff pokaże zmiany tylko dla określonych plików/folderów, np. git diff src/ .
polecenie git add<файл/папка>aktualizuje obszar przemieszczania wersjami plików/folderów z katalogu roboczego.
Polecenie git commit aktualizuje HEAD nowym zatwierdzeniem, które wykonuje migawki plików w obszarze pomostowym.
Działanie polecenia git reset<коммит>składa się z trzech potencjalnych kroków:
Domyślnie polecenie git reset wykonuje tylko kroki 1 i 2, ale jego zachowanie można zmienić za pomocą opcji --soft (tylko 1 krok) i --hard (wszystkie kroki).
Jeśli podasz ścieżkę do pliku/folderu, to polecenie zostanie wykonane tylko dla nich, na przykład git reset --soft HEAD~1 src/ .
polecenie git checkout HEAD<файл>daje taki sam wynik jak git zresetować — trudno GŁOWA<файл>- nadpisuje wersję pliku w obszarze przygotowanych plików oraz w katalogu roboczym wersją z HEAD, czyli cofa zmiany od ostatniego zatwierdzenia.
Z drugiej strony git checkout<файл>(już bez HEAD) nadpisuje wersję pliku w katalogu roboczym wersją w obszarze pomostowym, tj. cofa zmiany od ostatniej wersji pomostowej.
Wreszcie, git rm<файл>odśledzi plik i usunie go z katalogu roboczego, opcja --cached zachowa plik.
Często nie chcemy, aby Git śledził wszystkie pliki w repozytorium, ponieważ mogą one obejmować:
Plik .gitignore służy do ignorowania. Aby zaznaczyć pliki, które chcemy zignorować, możemy użyć wzorców wyszukiwania (potraktuj je jako uproszczone wyrażenia regularne):
Możemy nawet użyć wzorców wyszukiwania podczas określania pliku/folderu w innych poleceniach. Na przykład git add src/*.css doda wszystkie pliki .css w folderze src.
Ponieważ zatwierdzenia są podstawą historii wersji, warto dowiedzieć się o nich trochę więcej.
Polecenie git commit otworzy edytor tekstu do wprowadzenia komunikatu zatwierdzenia. To polecenie akceptuje również kilka typowych argumentów:
Kilka wskazówek, których należy przestrzegać:
Możesz użyć polecenia git log, aby wyświetlić historię poprzednich zatwierdzeń w odwrotnej kolejności chronologicznej. Można przekazać różne opcje:
Innym przydatnym poleceniem jest git obwinianie<файл>, który dla każdej linii w pliku pokazuje autora i sumę kontrolną ostatniego zatwierdzenia, które zmieniło tę linię. -L<начало>, <конец>pozwala ograniczyć to polecenie do podanych ciągów znaków. Można to wykorzystać na przykład, aby dowiedzieć się, które zatwierdzenie doprowadziło do określonego błędu (aby można było go wycofać).
Wreszcie istnieje polecenie git grep, które przeszukuje wszystkie pliki w historii zatwierdzeń (nie tylko katalog roboczy, jak robi to grep) dla danego Wyrażenie regularne. Opcja -n wyświetla odpowiedni numer wiersza w pliku dla każdego dopasowania, a opcja --count wyświetla liczbę dopasowań dla każdego pliku.
Uwaga Nie myl git grep z git log --grep ! Ten pierwszy przeszukuje pliki wśród zatwierdzeń, a drugi przegląda komunikaty dziennika.
Do tej pory omawialiśmy tylko używanie Git na komputerze lokalnym. Możemy jednak przechowywać historię zatwierdzeń zdalnych repozytoriów, które można śledzić i aktualizować (pomyśl o nich jako o zdalnych kopiach zapasowych w chmurze naszej historii zatwierdzeń).
Polecenie git remote -v wyświetla listę zdalnych repozytoriów, które monitorujemy, oraz nadane im nazwy.
Podczas korzystania z polecenia git clone
Najczęściej używane polecenia:
Następujące polecenia działają na zdalnych oddziałach:
W ten sposób kilka osób może żądać zmian z serwera, wprowadzać zmiany w lokalnych kopiach, a następnie przesyłać je na zdalny serwer, co pozwala im na wzajemną interakcję w ramach tego samego repozytorium.
Wszystko to jest dobre i wspaniałe, jeśli każdy programista pracuje nad projektem w innym czasie. Powyższe diagramy pokazywały tylko sytuacje, w których dokonano zmian w oryginalnym repozytorium lub lokalnej kopii, a nie pracę wielu osób.
To prowadzi nas do kluczowa cecha Git - rozgałęzianie, umiejętność pracy na różne wersje projekt. Oznacza to, że zamiast pojedynczej listy z uporządkowanymi zatwierdzeniami, historia będzie w pewnych punktach rozbieżna (co upodabnia ją do drzewa). Każda gałąź w Git zawiera lekki wskaźnik HEAD do ostatniego zatwierdzenia w tej gałęzi, dzięki czemu tworzenie wielu gałęzi jest opłacalne. Wskazówka: nazwij oddział zgodnie z rozwijaną w nim funkcjonalnością. Domyślna gałąź nazywa się master.
Mamy więc wspólny wskaźnik GŁOWA i HEAD dla każdej gałęzi. Tak więc przełączanie między gałęziami obejmuje tylko przemieszczanie GŁOWA na KIEROWNICY odpowiedniego oddziału.
Standardowe polecenia:
Zarówno nasze lokalne repozytorium, jak i nasze zdalne może mieć wiele gałęzi, więc kiedy śledzisz zdalne repozytorium, zdalna gałąź jest faktycznie śledzona (git clone łączy twoją gałąź główną z gałęzią Origin/master zdalnego repozytorium).
Łączenie ze zdalnym oddziałem:
Ogólnie rzecz biorąc, git checkout polega na zmianie miejsca, na które wskazuje HEAD gałęzi, co jest podobne do tego, jak git reset przesuwa współdzieloną HEAD.
Jest jedna subtelność - podczas przełączania gałęzi Git wymaga, aby stan roboczy był czysty, to znaczy wszystkie zmiany w śledzonych plikach muszą zostać zatwierdzone.
Notatka. tłumacz. To nie do końca prawda. W pewnych okolicznościach Git może automatycznie wypchnąć niezatwierdzoną zmianę do innej gałęzi.
Czasami jednak masz niedokończone zmiany, których nie można zatwierdzić. W takiej sytuacji można je zapisać i „ukryć” za pomocą polecenia git stash. Aby cofnąć zmiany, użyj git stash apply .
Zamiast tego możesz usunąć wszelkie wprowadzone zmiany. W takim przypadku użyj polecenia git clean. Opcja -d usunie również nieśledzone pliki. Porada: Dodaj opcję -n, aby zobaczyć, co się stanie, gdy uruchomisz git clean bez bezpośredniego użycia.
Po omówieniu, czym są gałęzie i jak się między nimi przełączać, nadszedł czas, aby porozmawiać o tym, jak można je łączyć po opracowaniu. Gałąź, w którą chcemy scalić zmiany, będzie nazywana gałęzią główną, a gałąź, z której będziemy je scalać, będzie gałęzią tematyczną. Istnieją dwa sposoby wprowadzania zmian z jednej gałęzi do drugiej: scalanie i przenoszenie.
Polega na utworzeniu nowego zatwierdzenia, które jest oparte na wspólnym przodku dwóch gałęzi i wskazuje oba HEAD jako poprzednie zatwierdzenia. Aby scalić, przechodzimy do głównej gałęzi i używamy polecenia git merge<тематическая ветка> .
Jeśli obie gałęzie zmienią tę samą część pliku, wówczas wystąpi konflikt scalania - sytuacja, w której Git nie wie, którą wersję pliku zachować, więc konflikt trzeba rozwiązać samodzielnie. Aby zobaczyć sprzeczne pliki, użyj git status .
Po otwarciu takich plików zobaczysz podobne znaczniki rozwiązywania konfliktów:
<<<<<<< HEAD:index.html Everything above the ==== is the version in master. ======= Everything below the ==== is the version in the test branch. >>>>>>>test:indeks.html
Zamień wszystko w tym bloku na wersję, którą chcesz zachować i przygotuj plik. Gdy wszystkie konflikty zostaną rozwiązane, git commit może zostać użyty do zakończenia scalania.
Zamiast scalać dwie gałęzie za pomocą zatwierdzenia łączenia, ruch odtwarza zatwierdzenia gałęzi tematu jako zestaw nowych zatwierdzeń gałęzi podstawowej, co skutkuje czystszą historią zatwierdzeń.
Aby przenieść, użyj polecenia git rebase<основная ветка> <тематическая ветка>, który odtwarza zmiany w gałęzi tematu w gałęzi głównej; Gałąź tematu HEAD wskazuje na ostatnio powtórzone zatwierdzenie.
Po scaleniu log z historią może wyglądać dość niechlujnie. Z drugiej strony przemieszczenie umożliwia napisanie historii od nowa w normalny, spójny sposób.
Po co więc scalać, skoro można cały czas używać przemieszczenia? Niestety przenoszenie nie jest panaceum na zagmatwane dzienniki, ponieważ przeniesione zatwierdzenia różnią się w rzeczywistości od oryginałów, mimo że mają tego samego autora, wiadomość i zmiany.
Wyobraź sobie scenariusz:
Oto wskazówka:
Wypychaj zmiany tylko w swoim prywatnym lokalnym oddziale - nie wypychaj zatwierdzeń, od których zależy ktoś inny.
Podobna debata na temat tego, którego lepiej użyć, pojawia się, gdy chcesz cofnąć zatwierdzenie. komenda git revert<коммит>tworzy nowe zatwierdzenie, które cofa zmiany, ale zachowuje historię, podczas gdy git reset<коммит>przesuwa wskaźnik HEAD, zapewniając czystszą historię (tak jakby zatwierdzenie nigdy się nie wydarzyło). Ważne jest, aby pamiętać, że oznacza to również, że nie będziesz już mógł powrócić do tych zmian, na przykład, jeśli zdecydujesz, że cofnięcie zatwierdzenia było niepotrzebne. Czyściej nie znaczy lepiej!
W tym momencie masz prawie wszystko, czego potrzebujesz, aby rozpocząć pracę z Gitem. Poniżej znajduje się kilka (opcjonalnie) zaawansowanych wskazówek dotyczących większej kontroli nad zatwierdzeniami i historią. Na marginesie poruszymy również GitHub, jedną z bardziej znanych platform Git, które mogą okazać się przydatne.
GitHub to platforma, która hostuje repozytoria Git na wielu serwerach. Jako użytkownik GitHub możesz przechowywać swoje zdalne repozytoria na ich serwerach, a także współtworzyć inne repozytoria typu open source. GitHub rozszerza korzystanie z Git o kilka nowych funkcji.
Na przykład możesz rozwidlić zdalne repozytorium, czyli utworzyć własną kopię repozytorium na północy GitHub. Jest to przydatne w przypadkach, gdy nie masz uprawnień do tworzenia gałęzi w oryginalnym repozytorium. Kiedy użyjesz polecenia git clone, twoje lokalne repozytorium będzie śledzić zdalne rozwidlenie jako źródło, a oryginalne repozytorium jako upstream.
Następnie może zaistnieć potrzeba scalenia gałęzi tematu zdalnego repozytorium z gałęzią główną oryginalnego repozytorium. Aby to zrobić, możesz utworzyć nowe żądanie ściągnięcia, w którym GitHub sprawdza konflikty przed zezwoleniem na scalenie. Często przed scaleniem przeprowadzane są inne kontrole, takie jak przeglądanie i zatwierdzanie kodu, a nawet przeprowadzanie testów. Możesz omówić kod w żądaniu, a wszelkie zatwierdzenia, które wypchniesz do zdalnej gałęzi tematu, zostaną automatycznie dodane do żądania, nawet jeśli zostało utworzone przed tymi zatwierdzeniami.
Możesz wygodnie zarządzać obszarem przejściowym (na przykład podczas zatwierdzania kilku małych zatwierdzeń zamiast jednego dużego) za pomocą interaktywnej konsoli, którą możesz uruchomić git add -i . Posiada 8 dostępnych poleceń:
* obok pliku oznacza, że polecenie zmieni swój status (przygotowane/nieprzygotowane w zależności od tego, czy jest aktualizowane, czy wycofywane). Jeśli naciśniesz Enter bez wprowadzania czegokolwiek w podmenu polecenia, wszystkie pliki przejdą w stan (nie)przygotowany.
Należy pamiętać, że tworzenie łatek (przygotowanie tylko części pliku) jest dostępne nie tylko w konsoli interaktywnej, ale także poprzez polecenie git add -p.
Aby uzyskać większą kontrolę nad historią zatwierdzania gałęzi lokalnej, możesz użyć polecenia git rebase -i HEAD~ N, co otworzy interaktywną konsolę do przeniesienia ostatniego zestawu N zatwierdzenia wymienione w kolejności od najstarszej do najnowszej (czyli w kolejności, w jakiej zostaną przeniesione). W ten sposób możesz „edytować historię”, ale pamiętaj, że oryginalnych zatwierdzeń nie można zmienić, a jedynie przenieść.
Możesz zmienić kolejność zatwierdzeń, zmieniając kolejność ich wyświetlania.
Polecenie edit służy do określenia zatwierdzenia, które chcesz zmienić. Następnie, gdy Git wykona ruch, zatrzyma się na tym zatwierdzeniu. Następnie możesz użyć git commit --amend, aby zmienić wiadomość lub przygotować zapomniane pliki. Jeśli chcesz podzielić zatwierdzenie, po zatrzymaniu wpisz git reset HEAD^ (spowoduje to cofnięcie polecenia HEAD o jedno zatwierdzenie, a wszystkie pliki zmienione w tym zatwierdzeniu przejdą w stan niestacjonarny). Następnie możesz zatwierdzić pliki w oddzielnych zatwierdzeniach w normalny sposób.
Po zakończeniu edycji wpisz git rebase --continue .
Czasami może być konieczne nadpisanie wielu zatwierdzeń - w takich przypadkach można użyć git filter-branch. Na przykład, aby usunąć przypadkowo zatwierdzony plik, możesz wpisać git filter-branch --tree-filter "git rm -f<имя файла>" HEAD . Należy jednak pamiętać, że porusza to całą historię.
Podczas pracy nad Nowa cecha w projekcie możesz stopniowo zatwierdzać nawet najmniejsze zmiany w gałęzi tematu. Jednak z tego powodu historia jest zaśmiecona takimi małymi zatwierdzeniami, które mogą być niezgodne z zasadami projektu. Można to naprawić, łącząc kilka zatwierdzeń w jedno duże. Aby to zrobić, najpierw użyj polecenia pick, aby wybrać pierwsze zatwierdzenie, a następnie squash dla kolejnych. Git zastosuje wszystkie zmiany w jednym zatwierdzeniu i poprosi o edycję wiadomości całego zatwierdzenia.
Poza łączeniem/przenoszeniem wszystkich zatwierdzeń w gałęzi tematu, możesz być zainteresowany tylko konkretnym zatwierdzeniem. Załóżmy, że masz lokalny dział redakcyjny, w którym pracujesz nad kilkoma potencjalnymi artykułami, ale chcesz opublikować tylko jeden z nich. Możesz do tego użyć polecenia git cherry-pick. Aby uzyskać konkretne zatwierdzenia, z których chcemy wybierać, możemy użyć git log<основная ветка>..<тематическая> .
Zauważ, że tworzy to nowe zatwierdzenie, które tylko powtarza różnicę wybranego zatwierdzenia (to znaczy różnicę między tym zatwierdzeniem a poprzednim), ale nie jego stan.
Omówiliśmy więc podstawowe koncepcje Gita. Możesz użyć tego artykułu jako szybkiego odniesienia lub przeczytać książkę Pro Git, która jest znacznie dłuższa (~450 stron) i bardziej szczegółowo omawia Git.
Chcesz zagłębić się w Git, ale jedna duża książka to za mało (lub dużo)? W takim razie powinieneś spojrzeć na nasze.
Tutaj opisana jest praktyczna część zagadnienia korzystania z Gita - jego instalacja i rejestracja na serwerze GitHub.com.
GitHub.com to usługa oferująca przechowywanie Twojego kodu i danych za pomocą systemu kontroli wersji. git. GitHub zapewnia bezpłatny plan przechowywania 300 MB danych w postaci zwykłego tekstu. Oznacza to, że każdy użytkownik Internetu może pobrać Twoje dane. Możesz hostować repozytoria zamknięte dla innych w GitHub za 7 USD miesięcznie. Na darmowym koncie GitHub domyślnie nikt nie może zmieniać Twoich danych (mogą tylko czytać). Ale możesz nalegać, którzy użytkownicy systemu GitHub mają dostęp do zapisu.
W artykule szczegółowo opisano, jak skonfigurować Git w systemach Windows i Linux.
Instalacja Gita w systemie Linux
Użytkownikom Linuksa chyba nie ma sensu tłumaczyć jak zainstalować Gita - każdy system robi to inaczej. W systemie Debian (który mam), aby zainstalować Git, możesz użyć polecenia:
apt-get zainstaluj git
Instalowanie Gita w systemie Windows
Przejdź do oficjalnej strony Git http://git-scm.com , kliknij Pobierać dla Windowsa . W oknie, które zostanie otwarte, kliknij na Pełny instalator oficjalnego Git. Uruchom wynikowy plik exe.
Podczas procesu instalacji zostanie zadane następujące pytanie:
Polecam wybranie „Uruchom Git z wiersza polecenia systemu Windows”. Wszystkie pozostałe opcje można pozostawić jako domyślne. Po zainstalowaniu Git musisz zrestartować lub wylogować się z sesji użytkownika i zalogować się ponownie, aby zmiany w PATH systemu zaczęły obowiązywać.
Jeśli otrzymamy informacje o wersji, oznacza to, że Git jest zainstalowany i działa. Jeśli otrzymamy informację, że program git nie został znaleziony, dochodzimy do tego, co zrobiliśmy źle.
Konfigurowanie kluczy SSH
Przed zarejestrowaniem się w GitHub musisz najpierw wygenerować klucz szyfrujący SSH. Ten klucz jest wymagany do szybkiego nawiązania połączenia z GitHub bez podawania hasła. Bez takiego klucza GitHub po prostu nie będzie działał.
Uwaga!
Podczas generowania klucza wymagane będzie podanie hasła. Jest to hasło dostępu do klucza prywatnego, który jest przechowywany tylko na Twoim komputerze i nigdzie indziej. To hasło jest ustawione dla maksymalnego bezpieczeństwa, chociaż możesz się bez niego obejść. Musisz wiedzieć, że ustawiając hasło do klucza prywatnego, będziesz musiał je wprowadzać przy każdym połączeniu z serwerem GitHub podane hasło. Tak więc podczas ustawiania hasła znika cała wygoda korzystania z kluczy szyfrujących.
Użytkownicy MyTetra: interfejs z wiersz poleceń, który jest używany do wywoływania git podczas synchronizacji, nie może działać na wprowadzaniu znaków. Dlatego jeśli ustawisz hasło, synchronizacja nie będzie działać.
Konfigurowanie kluczy SSH w systemie Linux
W system operacyjny Linux najpierw musi zajrzeć do katalogu ~/.ssh. Jeśli istnieją pliki id_rsa i id_rsa.pub, to są to klucze SSH. Jeśli nie ma takiego katalogu lub takich plików, to należy wygenerować klucze. Wydajemy polecenie:
Zamiast [e-mail chroniony] musisz podać swój e-mail. W trakcie generowania klucza zostaniesz zapytany, gdzie umieścić pliki, w odpowiedzi wystarczy nacisnąć Enter. Gdy pojawi się monit o hasło, po prostu naciśnij Enter. Po wygenerowaniu pliki id_rsa oraz id_rsa.pub powinny pojawić się w katalogu ~/.ssh, przydadzą się nam w przyszłości.
Konfigurowanie kluczy SSH w systemie Windows
Na sali operacyjnej systemu Windows Generator kluczy SSH jest dołączony do Git. Aby wygenerować klucze, musisz uruchomić plik C:\Program Files\Git\Git bash.vbs. Można go uruchomić jako zwykły plik exe. Program konsoli git zostanie otwarty. W nim musisz wydać polecenie:
ssh-keygen -t rsa -C" [e-mail chroniony]"
Uważaj, kopiowanie i wklejanie jest błędne w tej konsoli, łatwiej jest wprowadzić polecenie ręcznie. Podaj swój adres e-mail jako Skrzynka pocztowa. Na prośbę" Wprowadź plik, w którym chcesz zapisać klucz" po prostu naciśnij Enter. Po wyświetleniu monitu o podanie hasła "Wprowadź hasło" i "Ponownie wprowadź to samo hasło" po prostu naciśnij Enter. Podczas procesu generowania klucza w konsoli zostaną wyświetlone następujące informacje:
Generowanie pary kluczy rsa publiczny/prywatny.
Wprowadź plik, w którym chcesz zapisać klucz (/c/Documents and Settings/username/.ssh/id_rsa):
Wprowadź hasło (puste w przypadku braku hasła):
Wprowadź ponownie to samo hasło:
Twoja identyfikacja została zapisana w /c/Documents and Settings/username/.ssh/id_rsa.
Twój klucz publiczny został zapisany w /c/Documents and Settings/username/.ssh/id_rsa.pub.
Kluczowy odcisk palca to:
51:db:73:e9:31:9f:51:a6:7a:c5:3d:da:9c:35:8f:95 [e-mail chroniony]
Po wykonaniu tego programu w katalogu C:\Documents and Settings\nazwa użytkownika\.ssh pliki id_rsa i id_rsa.pub będą leżeć, przydadzą się nam w przyszłości.
Rejestracja na GitHub.com
Teraz wszystko jest gotowe do rejestracji. Chodźmy do Strona startowa GitHub.com. Interfejs jest nieco mylący, więc dam kilka zrzutów ekranu pokazujących, gdzie co nacisnąć. Projekt i układ można zmienić w dowolnym momencie, dlatego opisuję logikę działań w tej chwili.
W górnym menu znajdujemy pozycję „ Ceny i rejestracja"i kliknij na to:
Zostanie otwarta strona wyboru plan taryfowy. Wybierz darmowe konto Utwórz bezpłatne konto":
Konfigurowanie klucza SSH na GitHub
Zaraz po rejestracji musisz zarejestrować swój publiczny klucz szyfrujący (publiczny klucz SSH) w systemie GutHub. Aby dodać klucz, musisz kliknąć w prawym górnym rogu " Ustawienia konta":
W oknie, które zostanie otwarte, kliknij pozycję menu „ Klucze publiczne SSH" i naciśnij " Dodaj kolejny klucz publiczny". Pojawią się dwa pola - nazwa klucza ( Tytuł) i kluczowa treść ( klucz).
W polu Tytuł możesz wpisać nazwę komputera, na którym został wygenerowany klucz publiczny. Umiesz pisać po rosyjsku.
W polu klucz musisz wkleić zawartość pliku id_rsa.pub. Pamiętasz w jakim katalogu są? Przejdź do tego katalogu, otwórz dowolny Edytor tekstu plik id_rsa.pub (z rozszerzeniem .pub, nie myl go). Zaznacz cały tekst, skopiuj i wklej na stronie GitHub w polu klucz.
Po dodaniu klucza komputer powinien móc połączyć się z GitHubem przez program git i nie powinny wystąpić żadne błędy.
Tworzenie repozytorium na GitHub
Teraz nadszedł czas, aby utworzyć swoje pierwsze repozytorium GitHub. Repozytorium można traktować po prostu jako katalog, w którym będą znajdować się zsynchronizowane pliki i podkatalogi. Musisz utworzyć repozytorium w interfejsie internetowym GitHub i możesz wypełnić je plikami i pracować z nim za pomocą programu git na swoim komputerze.
Aby utworzyć repozytorium, musisz kliknąć w prawym górnym rogu „ panel". W oknie, które zostanie otwarte, zobaczysz element " Utwórz repozytorium":
Więc nie potrzebujemy tego przedmiotu! Ten element nie otwiera okna dialogowego tworzenia repozytorium, ale stronę pomocy. Zamiast klikać w ten element szukamy poniżej niepozornego linku na stronie " Utwórz repozytorium". Otworzy się okno dialogowe dodawania nowego repozytorium.
W oknie dialogowym dodawania nowego repozytorium musisz wypełnić co najmniej pole nazwy projektu " Nazwa Projektu". W nazwie projektu lepiej nie używać cyrylicy, ponieważ nazwa projektu jest w rzeczywistości nazwą katalogu. Aby uniknąć problemów, lepiej, aby nazwa projektu zawierała tylko litery łacińskie. Po naciśnięciu przycisku " Utwórz repozytorium", repozytorium zostanie utworzone.
Działające łącze do repozytorium w systemie GitHub tworzy się w następujący sposób. Jeśli zarejestrowałeś się jako nazwa użytkownika, a Twoje repozytorium nazywa się reponame , możesz skorzystać z poniższych linków, aby uzyskać dostęp do tego repozytorium:
W składni Gita:
[e-mail chroniony]:nazwa_użytkownika/nazwa_repo.git
W składni HTTPS:
https:// [e-mail chroniony]/nazwa_użytkownika/nazwa_repo.git
Praca z repozytorium na GitHub poprzez program Git
Od teraz tańce wokół interfejsu webowego GitHub można uznać za zakończone. Ponadto możesz pracować tylko przy użyciu programu git.
Najpierw musisz dokonać małej konfiguracji programu git: określ system lokalny git nazwa użytkownika i adres e-mail. Odbywa się to za pomocą następujących poleceń, które można wykonać z dowolnego katalogu:
git config --global user.name "TwojePełneNazwisko"
git config --global user.email [e-mail chroniony]
gdzie zamiast YourFullName musisz wpisać swoje imię i nazwisko, a zamiast [e-mail chroniony]- Twój email. Te wartości służą do logowania do GitHub. Dlatego zamiast YourFullName musisz podać swój login na GitHub i na miejscu [e-mail chroniony] musisz podać adres e-mail, który podałeś podczas generowania kluczy szyfrowania.
Po tych ustawieniach możesz przesłać swoje pliki do repozytorium. Przejdź do katalogu ze swoim projektem i wydaj polecenia:
git commit -a -m "pierwsze zatwierdzenie"
git zdalne dodawanie źródła [e-mail chroniony]:nazwa_użytkownika/nazwa_repo.git
git push -u master pochodzenia
Po tych poleceniach na serwerze GitHub powstają kopie plików katalogu, w którym te polecenia zostały wykonane. Wtedy możesz już robić commity, przesyłać zmiany na serwer GitHub, czytać zmiany z serwera. Ale to zupełnie inna historia.
