Podręcznik Git: Jak zachować spokój w zespole

Git jest trudny, zepsucie jest łatwe. Jest wiele rzeczy, które powinieneś wiedzieć, jak skutecznie używać git z zespołem. Na szczęście tu jesteś, pokażę ci instrukcję obsługi, która pomoże ci pracować w zespole.

Co to jest git?

Git to darmowy i rozproszony system kontroli wersji Open Source (DVCS) do śledzenia zmian w kodzie źródłowym podczas tworzenia oprogramowania. Git jest zaprojektowany do obsługi wszystkiego - od małych do bardzo dużych projektów - z szybkością i wydajnością.

Podstawowe polecenia

Pokażę ci kilka podstawowych poleceń git, które pomogą ci wnieść wkład w swój zespół.

git init

Jeśli chcesz utworzyć nowe lokalne repozytorium, możesz wykonać:

git init

Następnie masz świeże i zupełnie nowe repozytorium. Stamtąd możesz rozpocząć pracę z kodem w nowym repozytorium.

klon gita

Jesteś w zespole programistów, a projekt jest już wykonany przez kierownika zespołu w GitHub lub GitLab. Teraz chcesz wnieść swój wkład do swojego komputera. Możesz po prostu użyć git clone, aby sklonować repozytorium w plikach lokalnych:

klon gita 

oddział git

Po sklonowaniu repozytorium online w repozytorium lokalnym nie można od razu rozpocząć kodowania. Musisz stworzyć swój własny oddział, aby nie zepsuł się produkt końcowy repozytorium. W git branch istnieje kilka opcji:

oddział git

Wyświetl wszystkie gałęzie w swoim repozytorium. Jest to równoznaczne z listą gałęzi git.

oddział git 

Utwórz nowy oddział o nazwie . To nie sprawdza nowego oddziału.

gałąź git -d 

Usuń określoną gałąź. Jest to „bezpieczna” operacja, ponieważ Git uniemożliwia usunięcie gałęzi, jeśli wprowadzono nie scalone zmiany.

gałąź git -D 

Wymuś usunięcie określonej gałęzi, nawet jeśli ma ona nie scalone zmiany. To polecenie, którego należy użyć, jeśli chcesz na stałe wyrzucić wszystkie zatwierdzenia związane z określoną linią rozwoju.

gałąź git -m 

Zmień nazwę bieżącej gałęzi na .

gałąź git -a

Wyświetl wszystkie zdalne gałęzie.

Git Checkout

Po utworzeniu własnego oddziału. Chcesz nawigować z bieżącej gałęzi (domyślnie jest to master) do swojej gałęzi za pomocą polecenia git checkout. Wyewidencjonowanie oddziału aktualizuje pliki w katalogu roboczym, aby pasowało do wersji zapisanej w tym oddziale, i mówi Gitowi, aby zapisał wszystkie nowe zatwierdzenia w tym oddziale. Pomyśl o tym jako o sposobie wyboru linii rozwoju, nad którą pracujesz.

Przełączanie gałęzi jest prostą operacją. Wykonanie poniższych czynności wskaże HEAD na koniec .

Git Checkout 

Podczas współpracy z zespołem powszechne jest korzystanie ze zdalnych repozytoriów. Te repozytoria mogą być hostowane i udostępniane lub mogą być lokalną kopią innego kolegi. Każde zdalne repozytorium będzie zawierać własny zestaw rozgałęzień. Aby wyewidencjonować zdalną gałąź, musisz najpierw pobrać jej zawartość.

git fetch --all

W nowoczesnych wersjach Git można następnie pobierać zdalne oddziały jak oddział lokalny.

Git Checkout 

Dodatkowo możesz pobrać nowy oddział lokalny i zresetować go do ostatniego zatwierdzenia oddziałów zdalnych.

git checkout -b git reset - twarde pochodzenie /

zdalnie

Po prostu powiedz, że chcesz sklonować swój projekt zespołowy we własnym repozytorium online. Po utworzeniu własnego repozytorium na GitHub lub GitLab chcesz wypchnąć lokalne repozytorium projektu zespołu do własnego repozytorium online. Aby sprawdzić swoje połączenie, możesz użyć następujących poleceń:

zdalnie

Wymień zdalne połączenia z innymi repozytoriami.

git zdalny -v

To samo co powyższe polecenie, ale zawiera adres URL każdego połączenia.

Teraz chcesz połączyć lokalne repozytorium z własnym repozytorium online za pomocą następujących poleceń:

zdalne dodawanie git 

Utwórz nowe połączenie ze zdalnym repozytorium. Po dodaniu pilota będziesz mógł używać jako wygodny skrót do w innych poleceniach Git.

git remote rm 

Usuń połączenie ze zdalnym repozytorium o nazwie .

zdalna zmiana nazwy git 

Zmień nazwę połączenia zdalnego z do .

git pull

Jeśli istnieje aktualizacja repozytorium online w oddziale, nad którym aktualnie pracujesz, możesz zaktualizować lokalne repozytorium, po prostu używając polecenia git pull. Mój domyślny sposób na pobranie z repozytorium online to użycie git pull ale w poleceniu git pull jest kilka opcji:

git pull

Pobierz kopię bieżącego oddziału podanego pilota i natychmiast połącz ją z kopią lokalną. To jest to samo co git fetch a następnie git merge origin / .

git pull --no-commit

Podobnie jak w przypadku domyślnego wywołania, pobiera zdalną zawartość, ale nie tworzy nowego zatwierdzenia scalania.

git pull --rebase

Taki sam jak poprzedni pull Zamiast używać git merge do integracji gałęzi zdalnej z lokalną, użyj git rebase.

git pull --verbose

Daje pełny wynik podczas ściągania, który wyświetla pobieraną zawartość i szczegóły scalania.

git push

Po wprowadzeniu zmian w lokalnym repozytorium bez względu na niewielki wpływ na pliki. Użyj git push, aby „wypchnąć” zmiany z lokalnego repozytorium do repozytorium online. Mój domyślny sposób przekazywania do repozytorium online to używanie git push ale w poleceniu git push istnieje kilka opcji:

git push

Wciśnij określoną gałąź do , wraz ze wszystkimi niezbędnymi zmianami i obiektami wewnętrznymi. Spowoduje to utworzenie lokalnego oddziału w docelowym repozytorium. Aby zapobiec nadpisywaniu zatwierdzeń, Git nie pozwala na wypychanie, gdy powoduje to nie-szybkie przewijanie do przodu w docelowym repozytorium.

git push --force

To samo co powyższe polecenie, ale wymusza push, nawet jeśli spowoduje to scalenie nie do przodu. Nie używaj flagi --force, chyba że masz absolutną pewność, że wiesz, co robisz.

git push --all

Wciśnij wszystkie lokalne oddziały do ​​określonego pilota.

git push --tags

Tagi nie są automatycznie wypychane, gdy wypychasz gałąź lub korzystasz z opcji --all. Flaga --tags wysyła wszystkie tagi lokalne do zdalnego repozytorium.

Git Merge

Po przekazaniu pracy do oddziału repozytorium online. Teraz powiedz, że chcesz scalić zmianę z produktem końcowym, powiedzmy w gałęzi głównej, ale sama gałąź główna już została zaktualizowana, ponieważ inni programiści w twoim zespole połączyli jej gałąź z gałęzią główną.

Jeśli nie zmieniają kodu w tych samych wierszach co twoja praca, możesz po prostu scalić swoją gałąź bez wywoływania konfliktu za pomocą polecenia scalania

git checkout master git merge gałąź git -d

Najlepszą praktyką po połączeniu oddziału jest bezpieczne usunięcie go.

W innym przypadku, jeśli ich kod znajduje się w tych samych wierszach co kod, a kody są inne, napotkasz konflikt scalania. Musisz najpierw rozwiązać konflikt, zanim ponownie połączysz swój oddział.

git rebase

Alternatywnie do scalania możesz zmienić bazę gałęzi funkcji na gałąź główną, używając następujących poleceń:

git checkout feature git rebase master

Powoduje to przesunięcie całej gałęzi funkcji na początek gałęzi głównej, efektywnie włączając wszystkie nowe zatwierdzenia w master. Jednak zamiast używać zatwierdzenia scalania, ponowne udostępnianie ponownie zapisuje historię projektu, tworząc zupełnie nowe zatwierdzenia dla każdego zatwierdzenia w oryginalnej gałęzi.

Podczas scalania utwórz nowy zatwierdzenie scalania w gałęzi funkcji w następujący sposób:

Rebase przenosi wszystkie zatwierdzenia w gałęzi funkcji do najnowszego zatwierdzenia w gałęzi głównej jako nowe zatwierdzenia

Główną zaletą bazowania jest to, że masz znacznie czystszą historię projektu. Po pierwsze, eliminuje niepotrzebne zatwierdzenia scalania wymagane przez git merge. Po drugie, jak widać na powyższym diagramie, zmiana bazy powoduje również idealnie liniową historię projektu - możesz podążać za wierzchołkiem funkcji aż do początku projektu bez żadnych widelców.

Git Cofnij

Cofanie anuluje zatwierdzenie poprzez utworzenie nowego zatwierdzenia. Jest to bezpieczny sposób na cofnięcie zmian, ponieważ nie ma szans na ponowne zapisanie historii zmian. W jednym z wielu przypadków, jeśli twoja funkcja zawiera błąd w produkcie końcowym (w gałęzi master), musisz natychmiast zrobić poprawkę. W tej sytuacji możesz użyć git revert.

Na przykład następujące polecenie obliczy zmiany zawarte w drugim do ostatniego zatwierdzenia, utworzy nowe zatwierdzenie cofając te zmiany i przypisze nowe zatwierdzenie do istniejącego projektu.

git checkout poprawka git revert HEAD ~ 2

Można to przedstawić następująco:

Polecenie git revert to operacja cofania, która oferuje bezpieczną metodę cofania zmian. Zamiast usuwać lub osierocać zatwierdzenia w historii zatwierdzeń, przywrócenie utworzy nowe zatwierdzenie, które odwraca określone zmiany. Git revert to bezpieczniejsza alternatywa dla git reset pod względem utraty pracy.

git skrytka

git stash tymczasowo odkłada (lub ukrywa) zmiany wprowadzone w kopii roboczej, aby móc pracować nad czymś innym, a następnie wrócić i ponownie zastosować je później. Ukrywanie jest przydatne, jeśli chcesz szybko zmienić kontekst i pracować nad czymś innym, ale jesteś w połowie zmiany kodu i nie jesteś jeszcze gotowy do zatwierdzenia.

Polecenie git stash pobiera niezatwierdzone zmiany (zarówno etapowe, jak i niestacjonarne), zapisuje je do późniejszego użycia, a następnie przywraca je z kopii roboczej. Na przykład:

$ git status On master master Zmiany, które należy zatwierdzić: nowy plik: style.css Zmiany nie zostały ustawione dla zatwierdzenia: zmodyfikowano: index.html $ git stash Zapisany katalog roboczy i stan indeksu WIP na master: 5002d47 nasza nowa strona główna HEAD jest teraz na 5002d47 nasza nowa strona główna $ git status Na gałęzi master nic do zatwierdzenia, działające drzewo czyste

W tym momencie możesz wprowadzać zmiany, tworzyć nowe zatwierdzenia, przełączać gałęzie i wykonywać wszelkie inne operacje Git; a potem wróć i ponownie zastosuj zapas, kiedy będziesz gotowy. Pamiętaj, że skrytka jest lokalna dla Twojego repozytorium Git; skrytki nie są przesyłane na serwer po naciśnięciu.

Możesz ponownie zastosować wcześniej ukryte zmiany za pomocą git stash pop:

$ git status Na głównym oddziale nic do zatwierdzenia, czyszczenie drzewa pracy $ git stash pop Na głównym oddziale Zmiany do zatwierdzenia:

 nowy plik: style.css

Zmiany, które nie zostały wprowadzone dla zatwierdzenia:

 zmodyfikowano: index.html

Dropped refs / stash @ {0} (32b3aa1d185dfe6d57b3c3cc3b32cbf3e380cc6a)

Usunięcie skrytki usuwa zmiany z skrytki i ponownie stosuje je w kopii roboczej.

Alternatywnie możesz ponownie zastosować zmiany w kopii roboczej i zachować je w skrytce za pomocą git stash:

Stosuje się $ git stash On master master Zmiany, które należy zatwierdzić:

 nowy plik: style.css

Zmiany, które nie zostały wprowadzone dla zatwierdzenia:

 zmodyfikowano: index.html

Jest to przydatne, jeśli chcesz zastosować te same zmiany ukryte w wielu gałęziach.

Teraz, gdy znasz podstawy ukrywania, istnieje jedno zastrzeżenie dotyczące ukrytego polecenia git, o którym musisz wiedzieć: domyślnie Git nie ukrywa zmian wprowadzonych w plikach nie śledzonych lub ignorowanych.

Zamknięcie

Mam nadzieję, że ten artykuł dał ci więcej wiedzy na temat zrozumienia Git i tego, jak poprawić pracę zespołową w projektach. Do zobaczenia w następnym artykule! Dziękuje za przeczytanie!

Dodatkowe zasoby

• Atlassian | Poradniki Git