W naszych poprzednich samouczkach dotyczących oprogramowania do kontroli wersji git nauczyliśmy się podstawowych poleceń dotyczących używania git, jako a także jak pracować z Github.com, aby założyć repozytorium i przesłać nasz kod projektu na stronę internetową.
Teraz nadszedł czas, aby rozpocząć rzeczywistą pracę z GitHubem (i gitem) w sposób, w jaki mają być używany: wprowadzanie zmian w projekcie bezpiecznie z jednej strony i łączenie ich z powrotem z oryginalnym projektem, gdy okażą się poprawne. A przynajmniej nie katastrofalne.
Teraz już wiesz, że git zapisuje każdą wersję twojego projektu jako migawkę kodu dokładnie tak, jak była w momencie, gdy go zatwierdziłeś. Zasadniczo tworzenie osi czasu wersji projektu w miarę jego postępów, dzięki czemu można przywrócić wcześniejszą wersję w razie wystąpienia katastrofy.
Sposób, w jaki git i GitHub zarządzają tą osią czasu – zwłaszcza gdy więcej niż jedna osoba pracuje w projekcie i wprowadza zmiany – to za pomocą oddziałów. Gałąź to w istocie unikalny zestaw zmian w kodzie o unikalnej nazwie. Każde repozytorium może mieć jedną lub więcej gałęzi. Gałąź główna – ta, w której wszystkie zmiany są ostatecznie scalane z powrotem i nazywana jest główną. To jest oficjalna działająca wersja twojego projektu i ta, którą widzisz, kiedy odwiedzasz repozytorium projektu pod adresem github.com/yourname/projectname.
Nie zadzieraj z mistrzem. Jeśli wprowadzisz zmiany w głównej gałęzi projektu grupowego, podczas gdy inni ludzie również nad nim pracują, zmiany w locie będą wpływać na wszystkich innych i bardzo szybko pojawią się konflikty scalania, płacz, rozdzieranie odzieży, i plagi szarańczy. To takie poważne.
Dlaczego mistrz jest tak ważny, aby z nim nie zadzierać? Jednym słowem: główna gałąź jest możliwa do wdrożenia. To Twój kod produkcyjny, gotowy do wprowadzenia na świat. Gałąź główna ma być stabilna, a umowa społeczna oprogramowania typu open source polega na tym, aby nigdy, przenigdy nie przesyłać do mastera niczego, co nie zostało przetestowane lub które zepsuje kompilację. Głównym powodem, dla którego działa GitHub, jest to, że zawsze można bezpiecznie pracować z poziomu głównego.
Rozgałęzienie
Zamiast tego wszyscy używają gałęzi utworzonych od mastera do eksperymentowania, wprowadzania edycji, uzupełnień i zmian , przed ostatecznym wprowadzeniem tej gałęzi z powrotem do mastera, po zatwierdzeniu i potwierdzeniu, że działają. Następnie Master jest aktualizowany, aby zawierał wszystkie nowe rzeczy.
Aby rozpocząć pracę nad czymkolwiek nowym w projekcie lub zmienić istniejące rzeczy, tworzysz gałąź ze stabilnej gałęzi głównej. Kontynuujmy pracę z przykładowym projektem utworzonym na potrzeby naszego poprzedniego samouczka, good ol ’studious_octo_carnival. Otwórz teraz swoją wersję na swoim komputerze i przejdź do katalogu.
Krok 1: Zrób inwentaryzację.
Przed utworzeniem nowych oddziałów, chcemy sprawdzić inne istniejące gałęzie . Wiemy o mistrzu, ale kto wie, co mogą robić nasi współpracownicy projektu, te złośliwe małpy? Więc możemy wyświetlić wszystkie istniejące gałęzie, wpisując „git branch -a” w terminalu, co mówi gitowi, że chcemy zobaczyć WSZYSTKIE gałęzie w tym projekcie, nawet te, których nie ma w naszym lokalnym obszarze roboczym.
Zwraca to dane wyjściowe widoczne w poniższym przykładzie kodu. Jego wygląd może się nieco różnić w zależności od systemu operacyjnego i aplikacji terminala, ale ostatecznie informacje są takie same. Gwiazdka obok słowa „master” w pierwszym wierszu danych wyjściowych wskazuje, że jesteśmy obecnie w tej branży. Druga linia mówi nam, że na naszym zdalnym, nazwanym źródle, znajduje się pojedyncza gałąź, zwana także master. (Pamiętaj, że nasz pilot jest repozytorium GitHub dla tego projektu).
Krok 2: Utwórz nową gałąź
Teraz, gdy wiemy, jak wyświetlać gałęzie, zróbmy jedną! Pamiętajmy, że mamy naszą główną gałąź, nasz oryginalny projekt. Teraz mamy zamiar stworzyć nową wersję projektu, gałąź, aby bawić się i wprowadzać zmiany lokalnie na naszym komputerze – podczas gdy oryginalna wersja projektu, master, pozostanie bezpiecznie niezakłócona na GitHubie. Nadajemy nowej gałęzi nazwę opisową, aby przypomnieć nam, co zamierzamy robić podczas pracy w niej. W tym przypadku będzie to prosta rzecz „Hello World”, więc nazwijmy to hello_octo.
Aby utworzyć nową gałąź, wpisz „git checkout -b nazwa_gałęzi tutaj” (więc w naszym przypadku „git checkout -b hello_octo”).
Zakładając, że nikt inny nie utworzył już gałęzi o nazwie „hello_octo”, git zwraca „Przełączono na nową gałąź 'hello_octo'.” (W przypadku, gdy gałąź o tej nazwie już istnieje, git powie nam zamiast tego „fatal: gałąź o nazwie 'hello_octo' już istnieje.” Nic wielkiego, po prostu zrób ponownie git checkout -b z nową odmianą nazwy). / p>
Możemy również użyć polecenia git checkout do przełączania się między naszymi dwoma gałęziami. Wpisz „git checkout nazwa oddziału”, aby przełączyć się do tej gałęzi.Tak więc „git checkout master” prowadzi do mastera, a „git checkout hello_octo” przenosi z powrotem do gałęzi hello_octo.
Jeśli spróbujesz przełączyć się na gałąź, która nie istnieje, na przykład „git checkout hello_kitty”, git poinformuje Cię, że to nie jest możliwe:
Skąd git wie, na której gałęzi aktualnie się znajdujesz? Git zawsze obserwuje to, co robisz i utrzymuje specjalny wskaźnik zwany HEAD. Podobnie jak igła na kompasie zawsze wskazuje północ, HEAD zawsze wskazuje lokalny oddział, w którym aktualnie się znajdujesz.
(Mogliśmy również utworzyć naszą gałąź za pomocą polecenia git „git branch branchNameHere”, a następnie przełączyć się na niego za pomocą git checkout. Jednak zgrabny mały skrót z „-b” w „git checkout -b nazwa_gałęzi tutaj” tworzy gałąź ORAZ przełącza się do niej. Nie mogę powiedzieć, ilu nowych programistów git generuje komunikaty o błędach i frustrację, ponieważ po prostu nie pamiętali o zmianie na nową gałąź po utworzeniu i t. Dlatego trzymamy się git checkout -b, mmmkay?)
Wprowadzanie zmian w naszej gałęzi roboczej
Teraz, gdy mamy wiele gałęzi – naszą gałąź roboczą do wprowadzania zmian i nasza główna gałąź bezpiecznie pozostaje nienaruszona – możemy zabrać się do pracy. W naszym scenariuszu zamierzamy użyć gałęzi „hello_octo” do wprowadzania i testowania naszych zmian, a następnie przesłać je z powrotem do gałęzi głównej w GitHubie.
Pamiętaj, aby upewnić się, że jesteś na swoim działająca gałąź, a nie główna, z dobrą starą gałęzią git -a.
Krok 3. Utwórz nowy pusty plik o nazwie „hello_octo_world”:
(Ten pusty plik służy tylko do celów demonstracyjnych, więc nie martw się, że nie ma nazwy / typu rozszerzenia pliku).
Ponieważ jest zupełnie nowy, prawda teraz ten plik jest tylko w twojej gałęzi. Użyj polecenia „ls”, aby go wyświetlić:
Pamiętaj jednak, że jesteśmy w naszej gałęzi roboczej, hello_octo, gdzie stworzyliśmy tę nową rzecz. Mistrz nie wie nic o hello_octo, ponieważ jest bezpiecznie odizolowany od wszelkich zmian, które chcąc nie chcąc dokonujemy tutaj na gałęzi roboczej. Jest to nadal ten sam spokojnie niezmieniony mistrz, z którym zaczęliśmy:
Krok 4: Przygotuj i zatwierdź nasz nowy plik w gałęzi roboczej.
Teraz jest czas do etapu (dodawania) i zatwierdzania naszego nowego pliku w gałęzi roboczej. (Brzmi znajomo?). Spowoduje to dołączenie tej nowej jednostki do gałęzi roboczej w celu przygotowania do ewentualnego przeniesienia jej do gałęzi głównej. Ten plik istnieje teraz w gałęzi hello_octo; jak widzieliśmy powyżej, obecnie nie istnieje w gałęzi głównej.
W tym momencie właśnie wykonałeś migawka zmian w gałęzi. W rzeczywistym projekcie prawdopodobnie jest więcej zmian i pracy do zrobienia. Teraz możesz to zrobić, wykonując po drodze zatwierdzenia w logicznych punktach. Pamiętaj, że na GitHubie zmiany reprezentują Twoje kolejne zapisy. Z każdym zatwierdzeniem powiązany jest komunikat o zatwierdzeniu, który jest opisem wyjaśniającym dokładnie, co tam zrobiłeś i dlaczego. Komunikaty o zatwierdzeniach zawierają historię zmian, dzięki czemu w przyszłości Ty i inni współtwórcy projektu będziecie mogli zrozumieć, co zrobiłeś i dlaczego.
Łączenie kodu między gałęziami
Gdy już są w końcu skończone ze wszystkimi zmianami i dodatkami – i wszystko działa * – czas na scalenie. Interesująca część pojawia się po przełączeniu się z powrotem do naszej gałęzi głównej (którą – powiedz to ze mną! – robimy z „git checkout master”). Brakuje „Hello_octo_world”, ale tak nie jest – obecnie istnieje w naszej pracy Oddział i jesteśmy na naszej głównej gałęzi. Pokazuję to ponownie, ponieważ jest to sedno zrozumienia gałęzi w git:
Teraz: w tym ćwiczeniu „hello_octo_world” oznacza każdą zmianę w dowolnym pliku (lub dodanie zupełnie nowego pliku), która przeszła wszystkie testy w naszej gałęzi programistycznej i jest gotowa do produkcji. Proces przenoszenia kodu między gałęziami (często z etapu programowania do produkcja) jest znane jako łączenie.
Bardzo ważne: podczas łączenia musimy znajdować się w gałęzi, z którą chcemy się scalić. Zasadniczo będziemy mówić gitowi: „Widzisz tę nową rzecz? Teraz możesz go tutaj przenieść. ”
Krok 5: Scal zmiany gałęzi roboczej
W tym przypadku, ponieważ chcemy scalić z naszej gałęzi roboczej, gdzie„ hello_octo_world ” plik istnieje, do naszej gałęzi master musimy być w gałęzi master.
Po wejściu do gałęzi master, wszystko, co musimy zrobić, to uruchomić polecenie merge. Najlepszym sposobem na to jest wpisanie ” git merge –no-ff ”- dodatkowe„ –no-ff ”mówi gitowi, że chcemy zachować wszystkie komunikaty zmian przed scaleniem. Ułatwi to śledzenie zmian w przyszłości:
Powrót do GitHub
Ostatnią rzeczą, którą musimy teraz zrobić, jest poinformowanie GitHub o tym, że robiliśmy to opanować tutaj w naszym lokalnym środowisku programistycznym.
Innymi słowy, czas na git push. Masz to!
Dane wyjściowe git potwierdzają, że połączenie z gałęzi deweloperskiej do gałęzi głównej w środowisku lokalnym, został teraz skopiowany na zdalny serwer: „master → master”.
I to wszystko! Pomyślnie utworzyliśmy działającą gałąź oddzielną od master. Wprowadziliśmy w niej zmiany. Wprowadziliśmy i zatwierdziliśmy te zmiany. Następnie scaliliśmy je z powrotem do mastera w naszym lokalnym środowisku roboczym. Na koniec przenieśliśmy wszystko do GitHub, aby wszystkie wersje naszego projektu były wszędzie takie same!
Ostatnia uwaga
Trochę porządków jest teraz w porządku: ponieważ pomyślnie połączyliśmy naszą gałąź hello_octo, już jej nie potrzebujemy. Aby usunąć scaloną gałąź, po prostu wpisz „git branch -d nazwa_gałęzi”:
Nie martw się: jeśli przypadkowo spróbujesz usunąć gałąź, która nie została jeszcze scalona, git zgłosi błąd.
A więc! Do tej pory korzystaliśmy z niezwykle uproszczonego przykładowego projektu, ponieważ w tym momencie najważniejsze jest zrozumienie i przyswojenie przepływu pracy gita. Scalanie wiąże się o wiele więcej niż w rzeczywistym świecie – na przykład, co się stanie, jeśli otrzymasz komunikaty o błędach, ponieważ podczas scalania występują konflikty? Bez obaw, nowy git-ster, dotrzemy do celu.
Twoja praca domowa: utwórz („dotknij”) więcej nowych plików w przykładowym projekcie i przećwicz wprowadzanie zmian, przygotowywanie, zatwierdzanie i ostatecznie łączenie Uważaj, aby zrozumieć, gdzie wskazuje twoja HEAD – tj. jaka jest twoja aktualna gałąź. Wprowadzaj zmiany tylko w gałęzi roboczej.
Ponieważ pamiętaj: nie zadzieraj z. Master .