10 najlepszych podstawowych poleceń git

Git stał się kwintesencją systemu kontroli wersji. Wzrost popularności Git można przypisać jej szybkości, zwinności i wszechstronności. Niezależnie od tego, czy jesteś freelancingiem, czy projektantem oprogramowania dla aplikacji na poziomie przedsiębiorstw, możesz skorzystać z korzystania z git. Pomaga śledzić swoje pliki poprzez systematyczne wersje. GIT ułatwia przewracanie się do starszych wersji kodu lub tworzenie nowych gałęzi do eksperymentowania na bieżącej bazie kodu. Ponadto GIT to rozproszony system kontroli wersji, co oznacza, że ​​nie musisz zawsze łączyć się z centralnym serwerem, aby wykonać swoją pracę.Poniżej znajdują się niezbędne polecenia GIT, które pomogą w codziennych zadaniach. Proste przykłady dają zrozumienie poleceń, dzięki czemu możesz łatwo zapamiętać składnię, gdy będziesz musiał z nich korzystać.

1. Git dodaj

Polecenie Git Add pozwala zacząć śledzić pliki i foldery dla repozytorium GIT i przenosi je do obszaru inscenizacji. Będziesz musiał użyć polecenia GIT Commit, aby uczynić je na stałe w swoich historycznych migawkach.

Korzystanie z polecenia jest łatwe. Możesz dodać pliki i foldery indywidualnie lub użyć operatora globu typu Linux typu (*), aby dodać je w grupach.

Weźmy poniższy przykład:

Załóżmy, że w powyższym przypadku dodaliśmy już Readme.tekst. Ale reszta plików nie została dodana.

Sprawdźmy status:

Status $ git
Na mistrzu oddziału
Twoja gałąź jest aktualna z „Origin/Master”.
Untracked Files:
(Użyj „git dodaj…”, aby uwzględnić w tym, co zostanie popełnione)
plik 1.tekst
plik2.tekst
folder1/

Pliki i foldery są na czerwono, co oznacza, że ​​nie są śledzone. Możemy je dodać za pomocą:

$ git dodaj plik 1.plik txt2.folder txt1/*

Jeśli teraz sprawdzimy status:

Status $ git
Na mistrzu oddziału
Twoja gałąź jest aktualna z „Origin/Master”.
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Nowy plik: plik 1.tekst
Nowy plik: File2.tekst
nowy plik: folder1/file3.tekst
Nowy plik: folder1/file4.tekst

Polecenie GIT Add dodało pliki do obszaru oceny. Pliki są przechowywane w obszarze inscenizacji, zanim uczynią je na stałe w procesie zatwierdzenia.

2. GIT Branch

Na git rozgałęzienie jest łatwe. W innych systemach kontroli wersji była to droga operacja. Ale algorytmy GIT są zoptymalizowane do rozgałęzienia. Więc możesz użyć polecenia GIT Branch, gdy chcesz stworzyć osobną linię rozwoju bez obawy o wydajność.

Spójrzmy na poniższy przykład.

Status $ git
Na mistrzu oddziału
Twoja gałąź jest aktualna z „Origin/Master”.
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Nowy plik: plik 1.tekst
Nowy plik: File2.tekst
nowy plik: folder1/file3.tekst
Nowy plik: folder1/file4.tekst

Zauważ, że jesteśmy „na mistrzu oddziału”. Kiedy utworzysz nowy projekt, skończysz w Branch Master. Możesz także użyć polecenia git gałęzi, aby dowiedzieć się, na której gałęzi jesteś:

$ git oddział -a
* gospodarz

Powyższe mówi ci, że jest tylko jedna gałąź o nazwie „Master”, a gwiazdka (*) oznacza, że ​​jesteś na tej gałęzi.

Utwórzmy nową gałąź o nazwie „Testowanie”:

Testy oddziału $ git

Teraz możemy ponownie sprawdzić gałęzie:

$ git oddział -a
* gospodarz
Testowanie

Mimo że wciąż jesteśmy w gałęzi „głównej”, możemy również zobaczyć nową gałęznę „testowania”, która została utworzona. Oddział „testowania” jest repliką oddziału „Master”.

3. Git Checkout

Komenda git kasy zabiera cię do gałęzi, dzięki czemu możesz pracować nad zasobami. Możesz myśleć o gałęziach jak rzekach i strumieniach. Z gałęzią tworzysz nowy strumień. Za pomocą polecenia kasy wprowadzasz się do tego strumienia.

Sprawdźmy oddział „testowania” z poprzedniego przykładu:

Testy kasy git git
Przełączono na „testowanie” gałęzi

Teraz sprawdźmy status i gałęzie ponownie:

Status $ git
Podczas testowania gałęzi
Nic do popełnienia, działający katalog czysty
$ git oddział -a
gospodarz
* Testowanie

Możesz zobaczyć z komendy git gałąź.

4. Git Clone

Polecenie Git Clone pozwala na wykonanie kopii dowolnego repozytorium GIT. Jak tylko sklonujesz repozytorium, nowy sklonowany folder zacznie śledzić zmiany lokalnie. Ponieważ git jest rozpowszechniany, klon jest w pełni autonomicznym repozytorium GIT.

Aby pokazać, jak działa klonowanie, utwórzmy nowe repozytorium:

$ mkdir dir1
$ CD DIR1
$ mkdir myProject
$ cd myProject/
$ git init
Zainicjowane puste repozytorium git w/dir1/myProject/.git/
$ Touch Readme.tekst
$ git commit -m 'zainicjuj moje repozytorium'
[Master (root-commit) 5a0bd75] zainicjuj moje repozytorium
1 Zmieniony plik, 0 wstawek (+), 0 delecji (-)
Utwórz tryb 100644 README.tekst

W powyższym przykładzie stworzyliśmy repozytorium GIT o nazwie folder „MyProject”. Załóżmy, że jest to nasze główne repozytorium. Teraz chcemy zrobić jego kopię i pracować gdzie indziej.

Utwórzmy katalog o nazwie „Dir2” i klonuj repozytorium „MyProject”. Używamy klonu git do klonowania „myProject”:

$ mkdir dir2
$ cd Dir2
$ git clone/dir1/myProject/
Klonowanie w „myProject”…
zrobione.
$ ls
mój projekt

Komenda Git Clone również działa z adresem URL.

$ git clone https: // github.com/test/test.git

Możesz także zmienić nazwę klonu, określając go po adresie repozytorium GIT:

$ git clone https: // github.com/test/test.Git myTest

5. git zatwierdzić

Polecenie GIT Commit jest uruchamiane po poleceniu GIT Dodaj. W naszym przykładzie dodawania GIT dodaliśmy pliki do śledzenia, ale nie oddaliśmy ich do repozytorium GIT. Śledzenie pozostaje lokalne, dopóki nie zostanie dokonane zatwierdzenie. Kiedy popełnisz zmiany, stają się częścią stałego zapisu.

Poniżej uruchamiamy polecenie git commit -m:

$ git commit -m „Zobowiązanie moich plików i folderów”
[Master 3EF57B3] Zobowiązanie moich plików i folderów
4 pliki zmienione, 0 wstawek (+), 0 delecji (-)
Utwórz tryb 100644 File1.tekst
Utwórz tryb 100644 File2.tekst
Utwórz tryb 100644 Folder1/File3.tekst
Utwórz tryb 100644 Folder1/File4.tekst

Jeśli nie użyjesz opcji -m, aby umieścić komentarz, Git otworzy domyślny edytor tekstu i poprosi o to. Komentarze są uważane za dobrą praktykę kontroli wersji. Więc zawsze umieszczaj znaczące komentarze w swoim zatwierdzeniu.

6. Git Config

Polecenie GIT Config umożliwia konfigurowanie różnych opcji repozytorium GIT. Na przykład możesz użyć polecenia git config -global, aby uzyskać i ustawić użytkownika.nazwa i użytkownik.e-mail.

Oto jak możesz ustawić wartości:

$ git config -global użytkownik.Nazwa „Zak H”
$ git config -global użytkownik.e -mail za przykł[email protected]

Oto jak możesz sprawdzić wartości:

$ git config -global użytkownik.nazwa
Zak h
$ git config -global użytkownik.e-mail
Zakh@przykład.com

7. git diff

Polecenie Git Dift pomaga zobaczyć różnice między plikami i folderami. Jeśli wprowadzasz zmiany w pliku, jest to przydatne narzędzie do szybkiej oceny wprowadzonych zmian.

Załóżmy, że rozpoczniemy naszą pracę od readme.plik txt z dwoma wierszami. Następnie pozbywamy się drugiej linii i dodajemy trzecią linię.

Teraz, jeśli uruchomimy polecenie diff, pokaże różnice między zaangażowaną wersją a lokalną wersją zmienioną w obszarze inscenizacji. Oto, jak to będzie wyglądać:

$ git diff
diff -git a/readme.txt b/readme.tekst
indeks 9475ddc… 1804904 100644
--- A/README.tekst
+++ b/readme.tekst
@@ -1,2 +1,2 @@
Linia 1: Moja pierwsza linia
-Linia 2: Moja druga linia
+Linia 3: Moja trzecia linia

Linia 1 jest niezmieniona (biała), linia 2 usunięta (czerwona) i linia 3 dodana (zielony).
Możesz użyć polecenia diff, aby również znaleźć różnice między poszczególnymi zobowiązaniami.

8. Git Fetch

Polecenie Git Fetch otrzymuje najnowsze zasoby z określonego pochodzenia.

Spójrzmy na przykład. Przypuszczał, że masz następujący warunek:

Dir1/MyProject
Dir2/MyProject (sklonowany)

Folder „Dir2/MyProject” jest sklonowany z „Dir1/MyProject”. Teraz, jeśli ktoś popełnił zmiany w „Dir1/MyProject”, możesz uzyskać takie zmiany od wewnątrz „Dir2/MyProject”:

$ git fetch pochodzenie
Pilot: Liczenie obiektów: 2, gotowe.
Zdalne: kompresujące obiekty: 100% (2/2), gotowe.
Remote: ogółem 2 (Delta 0), ponownie użyty 0 (Delta 0)
Obiekty rozpakowywania: 100% (2/2), gotowe.
Z /dir2 /… /dir1 /myProject
5A0BD75… 1713734 Master -> Origin/Master

Ważne jest, aby pamiętać, że polecenie git fetch nie łączy zmian. Do automatycznego pobierania i scalania użyj polecenia GIT Pull. Wtedy możesz zastanawiać się, dlaczego użyć tego polecenia. Mogą istnieć zaawansowane opcje git, w których otrzymujesz wszystkie zmiany z serwera pochodzenia, a następnie zastosuj zmiany tylko selektywnie do niektórych plików. Polecenie Git Fetch pozwala to osiągnąć. Jest to jednak zaawansowany temat, który można znaleźć w dokumentacji Git Fetch.

9. Git Grep

Polecenie GIT GREP umożliwia wyszukiwanie informacji GIT w poszukiwaniu informacji. Oto przykład wyszukiwania słowa „linia” w naszym repozytorium GIT. Opcja -n lub -line -numer pokazuje numery linii, w których Git znajduje dopasowanie:

$ git grep -n linia
Readme.TXT: 1: Linia 1: moja pierwsza linia
Readme.TXT: 2: Linia 3: Moja trzecia linia

Możesz przeprowadzić podobne wyszukiwanie liczby razy, gdy dopasowanie jest dostępne z opcją -c lub -zwolenni:

Linia git grep -c
Readme.TXT: 2

Powodem użycia GIT GREP nad Linux Grep jest to, że Git Grep jest szybszy dla repozytoriów GIT.

10. Git Log

Polecenie Git Log pokazuje historię zatwierdzenia.

$ git log
zatwierdzić 171373479FC309846EF605FBE650933767AFD0FB
Autor: Zak H
Data: śr. 21 listopada 20:26:32 2018 -0800
Dodano nowe pliki
zatwierdzić 5A0BD759506D20B2B989873258BF60D003AA3D36
Autor: Zak H
Data: śr. 21 listopada 18:48:35 2018 -0800
Zainicjuj moje repozytorium

Możesz także skorzystać z opcji -lineely, aby zobaczyć wersję skróconą. Skrócona wersja jest łatwiejsza do śledzenia.

$ git log -linia
1713734 Dodano nowe pliki
5A0BD75 Zainicjuj moje repozytorium

11. Git Scal

Komenda git scer łączy gałęzie.

Utwórzmy nowe repozytorium z „Main”, a następnie utwórz oddział „test”.

$ mkdir myProject
$ CD MyProject
$ git init
Zainicjowane puste repozytorium GIT w/git_essentials/myProject/.git/
$ Touch Readme.tekst
$ git add -a
$ git commit -m „początkowe zatwierdzenie”
[Master (root-commit) B31d4e1] Początkowe zatwierdzenie
1 Zmieniony plik, 0 wstawek (+), 0 delecji (-)
Utwórz tryb 100644 README.tekst
Test oddziału $ git
$ git oddział -a
* gospodarz
test
test kasy git
Przełączony na „test” oddziału

W gałęzi „testu” dokonajmy pewnych zmian:

$ Touch File1.plik txt2.tekst
$ Ls
Plik 1.plik txt2.TXT README.tekst
$ git add -a
$ git commit -m 'dodał dwa nowe pliki'
[TEST 7E11910] Dodano dwa nowe pliki
2 pliki zmienione, 0 wstawek (+), 0 delecji (-)
Utwórz tryb 100644 File1.tekst
Utwórz tryb 100644 File2.tekst

Do testu dodaliśmy dwa pliki.

$ git oddział -a
gospodarz
* Test
$ ls
Plik 1.plik txt2.TXT README.tekst
$ git kectout Master
Przełączony na „mistrz” oddziału
$ git oddział -a
* gospodarz
test
$ ls
Readme.tekst

Widzimy z powyższego pliku1.TXT i File2.TXT istnieje w gałęzi „testowej”, ale nie w „mistrzu”.

Połączmy się teraz.

$ git scal Test
Aktualizacja B31D4E1… 7E11910
Szybkie do przodu
Plik 1.txt | 0
Plik2.txt | 0
2 pliki zmienione, 0 wstawek (+), 0 delecji (-)
Utwórz tryb 100644 File1.tekst
Utwórz tryb 100644 File2.tekst
$ ls
Plik 1.plik txt2.TXT README.tekst
$ git oddział -a
* gospodarz
test

Teraz mamy „plik 1.txt 'and' plik2.txt „w gałęzi„ mistrz ”.

Uwaga: Pomyśl o połączeniu się jako operacji ciągnięcia. Musisz być w gałęzi, w którą chcesz się połączyć. W takim przypadku jesteś w gałęzi „Master”, wyciągając zmiany z gałęzi „Test”.

12. git mv

GIT MV to polecenie skrótu do uruchamiania poleceń dodawania i git rm. Można go użyć do zmiany nazwy plików.

Oto przykład:

$ git mv readme.TXT README.MD
Status $ git
Na mistrzu oddziału
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Zmiana nazwy: Readme.txt -> readme.MD

13. git ciągnie

Komenda git pull jest bardzo podobna do git git.

Oto przykład uruchamiania pochodzenia gita, takiego jak Git Fetch One (uruchamiamy żądanie Pull z klonu, aby uzyskać zmiany z oryginalnego repozytorium GIT):

$ Git Pull Origin
Remot: Liczenie obiektów: 3, gotowe.
Zdalne: kompresujące obiekty: 100% (2/2), gotowe.
Remote: ogółem 3 (Delta 0), ponownie używany 0 (Delta 0)
Obiekty rozpakowywania: 100% (3/3), gotowe.
Od/uczenia sięgit/git_essentials/myProject
7E11910… E67F932 Master -> Origin/Master
Aktualizacja 7e11910… E67F932
Szybkie do przodu
Plik 1.txt | 1 +
Plik2.txt | 1 +
Plik3.txt | 1 +
Readme.txt => readme.MD | 0
4 pliki zmienione, 3 wstawki (+)
Utwórz tryb 100644 File3.tekst
Zmień nazwę Readme.txt => readme.MD (100%)

Możesz zobaczyć, że zmiany zostały pobrane z pochodzenia i połączone w klon.

14. Git Push

Polecenie Git Push służy do przesuwania zmian w zdalnych repozytoriach. Oto przykład uruchamiania polecenia push:

$ git push pochodzenie mistrz
Liczenie obiektów: 2, gotowe.
Kompresja delta za pomocą maksymalnie 4 wątków.
Kompresujące obiekty: 100% (2/2), gotowe.
Pisanie obiektów: 100% (2/2), 242 bajtów | 0 bajtów/s, gotowe.
Razem 2 (Delta 1), ponownie użyty 0 (Delta 0)
Do/uczyć sięgit/git_essentials/myProject
E67F932… 90DC546 Master -> Master

Komenda główna GIT Push Origin wysyła zmiany do gałęzi „Master” Origin (repozytorium GIT, który sklonowałeś) z gałęzi „Master” sklonowanego repozytorium. Wizualnie pchnięcie wygląda tak:

klonowane/master -> pochodzenie/master

15. Git Rebase

Polecenie Git Rebase pomaga zmienić podstawę gałęzi. W ogólnym połączeniu dzieje się coś takiego:

Oddział testowy został połączony w oddział „główny”, aby stworzyć nowe zatwierdzenie.

W rebazie tak się dzieje:

Zmiany z E i F Changelist są ponownie obliczone i zatrzasane na końcu oddziału głównego. Odrodzenie pomaga uprościć gałęzie.

Załóżmy, że mamy taką sytuację w gałęzi „Master”:

$ git log -linia
7f573d8 Commit C: Dodano C.tekst
795DA3C COMMAL B: Dodano B.tekst
0f4Ed5b Commit a: Dodano.tekst

I oddział funkcji:

$ git log -linia
8ED0C4E commit f: zmodyfikowany b.tekst
6e12b57 commit e: zmodyfikowany a.tekst
795DA3C COMMAL B: Dodano B.tekst
0f4Ed5b Commit a: Dodano.tekst

Jeśli Rebase, otrzymujemy Git Rebase Master:

Funkcja kasy $ git
Przełączono na „funkcję gałęzi”
$ git rebase master

Po pierwsze, przewijanie głowy, aby odtworzyć swoją pracę na górze…

Zastosowanie: commit e: zmodyfikowany a.tekst
Zastosowanie: commit f: zmodyfikowany b.tekst
Następnie połącz „funkcję” w „Master”.
$ git kectout Master
Przełączony na „mistrz” oddziału
Funkcja $ git scal
Aktualizacja 7F573D8… 9EFA1A3
Szybkie do przodu
A.txt | 1 +
B.txt | 1 +
2 pliki zmienione, 2 wstawki (+)

Teraz, jeśli przejdziesz zarówno do gałęzi „Master”, jak i „funkcji”, zobaczysz te same dzienniki:

$ git log -linia
9efa1a3 zatwierdzenie f: zmodyfikowany b.tekst
8710174 commit e: zmodyfikowany a.tekst
7f573d8 Commit C: Dodano C.tekst
795DA3C COMMAL B: Dodano B.tekst
0f4Ed5b Commit a: Dodano.tekst

Odranie się ze sobą zgniło.

Uwaga: Nigdy nie używaj ponownych repozytoriów, ponieważ programiści napotkają poważne problemy z scalaniem.

git pilot

Polecenie GIT zdalne umożliwia ustawienie zdalnego serwera dla repozytorium. W sytuacji klonowania repozytorium źródłowe automatycznie staje się pilotem.

Na przykład:

$ pwd
/Learngit/git_essentials/test
$ git pilot -v
Origin/Learngit/git_essentials/MyProject (Fetch)
Origin/Learngit/git_essentials/MyProject (push)

Powyższe pokazuje, że zdalny serwer „Test” to kolejny folder o nazwie „MyProject”. Powodem jest to, że „test” został sklonowany do mojego projektu.

Ale zdalny serwer nie musi być lokalny. Możesz mieć coś takiego z adresem URL:

$ git pilot -v
pochodzenie https: // github.com/zaProject/MyProject (Fetch)
pochodzenie https: // github.com/Zakh/MyProject (push)

Możesz skonfigurować zdalne repozytorium GIT za pomocą Polecenie GIT Remote Add:

$ git zdalny dodaj pochodzenie https: // github.com/zaProject/MyProject

To połączy Twoje repozytor.

17. Git Reset

Reset git umożliwia niestosowanie dodanych plików.

Załóżmy, że dodałeś test plik „test.txt 'do twojego repozytorium:

$ Touch Test.tekst
$ git add -a
Status $ git
Na mistrzu oddziału
Twoja gałąź jest aktualna z „Origin/Master”.
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Nowy plik: test.tekst

Jednak zdecydujesz, że nie chcesz śledzić testu.TXT 'już. Możesz użyć polecenia GIT Reset Head, aby zablokować plik:

$ git resetować test głowy.tekst

Jeśli sprawdzisz status, plik ponownie nie jest w stanie nietreacyjny:

Status $ git
Na mistrzu oddziału
Twoja gałąź jest aktualna z „Origin/Master”.
Untracked Files:
(Użyj „git dodaj…”, aby uwzględnić w tym, co zostanie popełnione)
test.tekst

Test pliku.txt 'nie jest już śledzony.

18. Git Revert

Polecenie Git Revert pozwala odwrócić zmiany za pomocą numeru skrótu zatwierdzenia.

$ echo „test 1” >> myfile.tekst
$ git add -a
$ git commit -m „Dodano zmianę 1”
[Master 78A8277] Dodano zmianę 1
2 pliki zmienione, 1 wstawienie (+)
Utwórz tryb 100644 myfile.tekst
Utwórz TRYB 100644 Test.tekst
$ cat myfile.tekst
Test 1
$ echo „test 2” >> myfile.tekst
$ git add -a
$ git commit -m „Dodano zmianę 2”
[Master A976E9C] Dodano zmianę 2
1 Zmieniony plik, 1 wstawienie (+)
$ cat myfile.tekst
Test 1
Test 2
$ git log -linia
A976E9C Dodano zmianę 2
78A8277 Dodano zmianę 1
90DC546 Dodano plik
E67F932 dodał nowe pliki
7e11910 dodał dwa nowe pliki
B31D4E1 Początkowe zatwierdzenie

Stworzyliśmy „myfile.txt 'i popełnił dwie zmiany, więc plik ma wiersze „test 1” i „test 2”. Ale zdecydowaliśmy, że nie chcemy drugiego zatwierdzenia. Znaleźliśmy więc Hash Commit (A976E9C). Możemy użyć GIT powrót, aby pozbyć się zatwierdzenia:

$ git revert a976e9c
[Master 4F270E7] Wróć „Dodano zmianę 2”
1 Zmieniony plik, 1 usunięcie (-)
$ git log -linia
4F270E7 Revert „Dodano zmianę 2”
A976E9C Dodano zmianę 2
78A8277 Dodano zmianę 1
90DC546 Dodano plik
E67F932 dodał nowe pliki
7e11910 dodał dwa nowe pliki
B31D4E1 Początkowe zatwierdzenie
$ cat myfile.tekst
Test 1

Widzimy, że stworzył nowy hash zatwierdzenia, który powrócił do zatwierdzenia linii „test 2”. Plik ma teraz tylko wiersz „test 1”.

19. git rm

Polecenie GIT RM konfiguruje pliki do przyszłych usuwania. Umieszcza to, że pliki są usunięte w strefie inscenizacji.

$ git rm test.tekst
Test RM '.tekst'
Status $ git
Na mistrzu oddziału
Twój oddział wyprzedza „Origin/Master” o 3.
(Użyj „Git Push”, aby opublikować lokalne zatwierdzenia)
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Usunięte: test.tekst

Musisz popełnić zmiany, aby usunięcie mogło wejść.

20. Git Stash

Komenda Git Stash pozwala tymczasowo porzucić pracę, której nie jesteś jeszcze gotowy na popełnienie.
Załóżmy, że pracujesz w repozytorium z następującymi plikami:

$ ls
Jan.TXT Mary.tekst
Chcesz zmienić te pliki na bardziej oparte na projektach. Więc zaczynasz od:
$ git mv John.TXT ProjectFile1.tekst
$ ls
Mary.TXT ProjectFile1.tekst
Status $ git
Na mistrzu oddziału
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Zmiana nazwy: John.TXT -> ProjectFile1.tekst

W trakcie zmiany nazwy i aktualizacji „John.txt „to” ProjectFile1.txt ', otrzymujesz prośbę o zmianę czegoś w projekcie. Ale nie jesteś gotowy przesłać „ProjectFile1.tekst'. Więc to chronisz.

$ git Stash

Zapisany katalog roboczy i WIP stanu indeksu na Master: F0B5A01 Init John and Mary

Głowa jest teraz na F0B5A01 INIT JAN i MARY

$ ls
Jan.TXT Mary.tekst

Twoje lokalne środowisko pracy powraca do miejsca, w którym byłeś przed wprowadzeniem zmian opartych na projekcie. Po, uczestnicząc w przerwie, zamiast wracać do „Jana.txt ', decydujesz się pracować nad „Mary.plik txt 'teraz:

$ git mv Mary.TXT ProjectFile2.tekst
Status $ git
Na mistrzu oddziału
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Zmiana nazwy: Mary.TXT -> ProjectFile2.tekst
$ ls
Jan.TXT ProjectFile2.tekst

Ponownie przerwasz i schowujesz swoją nową pracę nad „Mary.tekst':

$ git Stash
Zapisany katalog roboczy i WIP stanu indeksu na Master: F0B5A01 Init John and Mary
Głowa jest teraz na F0B5A01 INIT JAN i MARY
$ ls
Jan.TXT Mary.tekst

Po zakończeniu pracy przerw, sprawdzasz listę Stash:

$ git Stash List
Stash@0: WIP na Master: F0B5A01 INIT JAND I MARY
Stash@1: WIP na Master: F0b5a01 init John and Mary

Masz dwa w toku (WIP) w skrytce. FIRS Time You Smeth, otrzymasz najnowszą „Mary.TXT „Zmiany:

$ git stash pop
Usunięcie Maryi.tekst
Na mistrzu oddziału
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Nowy plik: ProjectFile2.tekst
Zmiany nie zostały zainscenizowane w celu zatwierdzenia:
(Użyj „git add/rm…”, aby zaktualizować to, co zostanie popełnione)
(Użyj „Git Checkout -…”, aby odrzucić zmiany w katalogu roboczym)
Usunięto: Mary.tekst
Upuszczony refs/stash@0 (9B77A6B75E4E414FB64DE341668C812D3D35150C)

Po raz drugi popadasz w skrytkę, dostajesz „John.Zmiany związane z txt'em:

$ git stash pop
Usuwanie Johna.tekst
Na mistrzu oddziału
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Nowy plik: ProjectFile1.tekst
Nowy plik: ProjectFile2.tekst
Zmiany nie zostały zainscenizowane w celu zatwierdzenia:
(Użyj „git add/rm…”, aby zaktualizować to, co zostanie popełnione)
(Użyj „Git Checkout -…”, aby odrzucić zmiany w katalogu roboczym)
Usunięty: John.tekst
Usunięto: Mary.tekst
Upuszone refs/stash@0 (1E1968854FB5CA4D609E577822DC3280DBF928F6)
$ ls
ProjectFile1.TXT ProjectFile2.tekst

I masz swoją pracę w programie ProjectFile1.txt 'and' ProjectFile2.txt 'powrót.

Więc polecenie Git Stash pomaga schować swoją pracę, abyś mógł wrócić do niej później.

21. status git

Polecenie statusu GIT wyświetla różnicę między bieżącymi plikami a zatwierdzeniem głowy.

Oto przykład:

Status $ git
Na mistrzu oddziału
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Zmiana nazwy: File2.txt -> plik3.tekst
Zmiany nie zostały zainscenizowane w celu zatwierdzenia:
(Użyj „git dodaj…”, aby zaktualizować to, co zostanie popełnione)
(Użyj „Git Checkout -…”, aby odrzucić zmiany w katalogu roboczym)
Zmodyfikowany: File1.tekst

Pokazuje to „plik2.txt „jest przemianowany na„ plik ”.txt „, który jest gotowy do zatwierdzenia, ale modyfikacje w” pliku1.txt 'nie jest jeszcze w strefie inscenizacji.

Więc dodajemy wszystko:

$ git add -a

Teraz, kiedy sprawdzamy status:

Status $ git
Na mistrzu oddziału
Zmiany do popełnienia:
(Użyj „Git Resetuj głowę…” do zabezpieczenia)
Zmodyfikowany: File1.tekst
Zmiana nazwy: File2.txt -> plik3.tekst

Widzimy, że wszystkie zmiany są gotowe do zatwierdzenia.

22. Git Tag

Polecenie Git Tag pomaga tworzyć znaczniki dla ważnych punktów historycznych. Jest ogólnie używany do konfigurowania numerów wersji.

Polecenie GIT Tag pokaże bieżące dostępne tagi:

$ git tag
v1.0
v2.0

Możesz oznaczyć za pomocą tagu git formatu polecenia:

$ git tag v3.0

Aby zobaczyć, co jest w znaczniku, możesz użyć polecenia git show:

$ git show v1.0
commit 61e9e8AA1B98B2A657303E6822B291D2374314B5
Autor: Zak H
Data: Czw 22 listopada 01:06:42 2018 -0800
Pierwsze zatwierdzenie
diff -git a/1.TXT b/1.tekst
Nowy tryb pliku 100644
indeks 0000000… e69de29

Możesz także oznaczyć za pomocą skrótu zatwierdzenia i tagu formatu poleceń:

$ git log -linia
374EFE9 Zmodyfikowany plik
A621765 Dodaj
6D6ED84 Second Commit
61e9e8a Pierwsze zatwierdzenie
$ git tag v4.0 A621765
$ git show v4.0
zatwierdzić A6217650A2C7B2531ECB9C173BA94BD4B3BA7ABD
Autor: Zak H
Data: Czw 22 listopada 01:15:55 2018 -0800
Dodać
diff -git a/1.TXT b/1.tekst
indeks E69DE29… 587BE6B 100644
--- A/1.tekst
+++ B/1.tekst
@@ -0,0 +1 @@

Podsumowując

W przypadku dowolnego polecenia możesz użyć git -h, aby uzyskać więcej informacji.

Dalsze badanie

• https: // git-scm.COM/DOC