advanced git commands
W tym samouczku omówiono przydatne polecenia Git, takie jak Git Stash, Git Reset, Git Cherry Pick, Git Bisect i wyjaśniono, jak zintegrować GitHub z Jira:
W naszych poprzednich samouczkach z tej serii widzieliśmy większość funkcji GitHub.
W tym samouczku przyjrzymy się następującym:
- Tworzenie wersji
- Integracja z Atlassian Jira
- Najczęściej używane polecenia Git dla programistów
- Git Stash
- Git Cherry Pick
- Reset Git
- Git Bisect
=> Spójrz na przewodnik GitHub tutaj.
pytania do wywiadu soapui i odpowiedzi dla doświadczonych
Czego się nauczysz:
- Tworzenie wersji
- Integracja GitHub z Jira
- Zaawansowane polecenia Git dla programistów
- Wniosek
- rekomendowane lektury
Tworzenie wersji
Wydania w GitHub są używane do łączenia oprogramowania, dodawania informacji o wydaniu i plików binarnych (pliki WAR, EAR, JAR), aby klienci i ludzie mogli z nich korzystać.
Aby utworzyć wydanie, przejdź do strony głównej repozytorium i kliknij plik Wydania karta pod Zarządzaj tematami.
Kliknij Utwórz nowe wydanie.
Podaj tag i tytuł wydania. Pliki binarne są również dodawane do wydania. Po zakończeniu kliknij Opublikuj wydanie.
Wydanie jest teraz gotowe z kodem źródłowym i plikami binarnymi.
Integracja GitHub z Jira
Jednym z ważnych aspektów identyfikowalności jest odniesienie się do problemu Jira z zatwierdzeniami w GitHub. GitHub można zintegrować z Jira nie tylko w celu odniesienia się do problemu, ale także w celu ułatwienia tworzenia oddziałów i pull request z poziomu Jira.
Tak więc zazwyczaj, gdy programista zacznie pracować nad zadaniem lub błędami, tworzy gałąź. Opublikuj rozwój lub napraw błędy, a żądanie ściągnięcia można utworzyć z Jira w celu scalenia z plikiem głównym mistrz gałąź. Oddział utworzony przez programistę można następnie usunąć.
Aby skonfigurować integrację, użyliśmy wtyczki Integracja z Git dla Jira. To jest komercyjna wtyczka. Wtyczkę można pobrać z tutaj
Zainstaluj wtyczkę w Jira z Administrator -> Dodatki.
Po zainstalowaniu wtyczki przejdź do Aplikacja -> Repozytoria Git i połącz się z GitHubem.
Wprowadź nazwę użytkownika i hasło GitHub. Kliknij Połączyć .
Zostaną wyświetlone repozytoria wymienione dla konta użytkownika. Kliknij Importuj repozytoria aby zakończyć konfigurację integracji.
GitHub Commit With Jira Issue
Jako część komunikatu o zatwierdzeniu wprowadź, jak pokazano poniżej. Kliknij Zatwierdź zmiany .
Przykład 1: Poniżej znajduje się przykład Smart Commit co umożliwia programistom wykonywanie działań dotyczących problemów Jira z komunikatu zatwierdzenia. Jednym z takich poleceń jest #komentarz wraz z kluczem problemu, który dodaje komentarz do problemu w Jira, jak pokazano poniżej.
Zaktualizowano sekcję komentarzy.
Przykład 2: Przypisz do użytkownika i zaktualizuj czas spędzony jako 4 godziny.
Użyj #przydzielać i #czas polecenie smart commit w komunikacie zatwierdzenia.
Obie czynności zostały zakończone.
Przykład 3: Zmień stan problemu na W trakcie .
Utwórz gałąź
Ponieważ zadania i błędy są przydzielane programistom, muszą rozpocząć pracę nad rozwojem. W tym celu tworzą gałąź dla problemu, nad którym pracują, wykonują czynności programistyczne i wysyłają żądanie ściągnięcia w celu scalenia z gałęzią główną.
W wydaniu Jira na dole kliknij Utwórz gałąź.
Kliknij Utwórz gałąź.
W GitHub dokonaj zmiany w pliku w powyższej gałęzi i zatwierdź to samo.
Po zakończeniu opracowywania użytkownik może następnie zgłosić żądanie ściągnięcia z Jira.
U dołu numeru kliknij Utwórz żądanie ściągnięcia.
Kliknij Stwórz. Żądanie ściągnięcia zostanie wyświetlone jako otwarte.
Następnym krokiem jest scalenie żądania ściągnięcia w GitHub.
Status jest odpowiednio aktualizowany w Jira.
Zaawansowane polecenia Git dla programistów
W tej ostatniej sekcji przyjrzymy się niektórym z powszechnie używanych poleceń Git dla programistów. Nie ma to nic wspólnego z GitHubem, ale pomoże programistom przed wprowadzeniem zmian do GitHub.
Git Stash
W większości scenariuszy projektu, gdy pracujesz nad nową funkcją lub ulepszeniem, nagle pojawiłaby się potrzeba pracy nad pilną usterką, która została zgłoszona i która zatrzymuje pokaz. Ponieważ jesteś w połowie swojej nowej pracy i jej nie ukończyłeś, nie ma sensu wprowadzać zmian, które są już w połowie wykonane.
Dlatego lepiej tymczasowo zawiesić lub zapisać w połowie wykonaną pracę, popracować nad błędem i wrócić do pracy nad nową funkcją lub ulepszeniem. Git stash zapewnia rozwiązanie tego problemu. Możesz łatwo i szybko zmienić kontekst wprowadzania zmian.
Przykład 1 :Załóżmy, że pracujesz nad przydzielonym ci zadaniem, a kiedy patrzysz na status, widać, że jest ono obecnie nieśledzone.
Nagle pojawia się błąd o wysokim priorytecie. Dlatego musimy tymczasowo zapisać lub schować pracę, nad którą obecnie pracujemy.
Uruchom następujące polecenie.
git stash save „Wiadomość”
W tej chwili katalog roboczy jest czysty. Można dokonać wszelkich nowych zatwierdzeń, a jeśli są błędy, możesz przełączyć gałąź, aby nad nią pracować itp.
Jeśli chcesz ponownie zastosować zmiany w miejscu, w którym zostawiłeś, użyj polecenia.
git stash pop
Powyższe polecenie usunie skrytkę z listy i zastosuje ostatni zapisany stan.
Możesz także użyć:
git stash Apply
Powyższe polecenie zachowa zmiany w skrytce i nie usunie ich.
Teraz zmiany zostaną ponownie zastosowane i możesz je zatwierdzić.
Przykład 2: Ukryj zmiany, zmień gałąź i scal zmiany.
Wprowadź zmianę w pliku HTML w mistrz zmiany gałęzi i skrytki.
Następnie przejdź do pluskwa rozgałęzienia, wprowadzaj zmiany i zatwierdzaj zmiany.
git checkout -b błąd
Wprowadź zmiany w pliku HTML.
git commit -a -m „Naprawiono problem z wiadomościami e-mail”
Wróć do mistrz gałąź i ponownie zastosuj zmiany ze skrytki.
Teraz scal z pluskwa gałąź do mistrz gałąź. Zatwierdź zmiany po scaleniu.
Przykład 3: Praca z wieloma skrytkami.
W lokalnym repozytorium znajdują się 2 pliki HTML. Jest więc możliwe, że wielu programistów będzie pracować nad wieloma plikami i przechowywać zmiany w razie potrzeby, aby pracować nad pilnymi żądaniami, które nadejdą, aby naprawić zmiany.
Deweloper 1 pracuje na hello.html, a Deweloper 2 na index.html.
Deweloper 1
Lista skrytek zawiera teraz 1 wpis.
Deweloper 2
Lista skrytki zawiera teraz 2 wpisy. Najnowsza skrytka jest pierwsza w stosie, czyli stash @ {0}. Teraz obaj programiści mogą pilnie wykonać inne zatwierdzenia lub pracować nad inną gałęzią, a następnie wrócić do mistrz gałąź i zastosuj zmiany w skrytce.
Aby zastosować najnowszą skrytkę, możesz po prostu biegać
git stash pop
Aby zastosować konkretną skrytkę w stosie, uruchom następujące polecenie.
git stash pop stash @ {1}
Zastosujmy drugą skrytkę, czyli stash @ {1}
Podobnie można zastosować drugą skrytkę.
Git Cherry Pick
Obecnie programiści pracują nad wieloma gałęziami, takimi jak funkcje, ulepszenia, błędy itp.
Są sytuacje, w których wystarczy wybrać tylko kilka konkretnych zatwierdzeń i nie należy łączyć całej gałęzi z inną. Nazywa się to Cherry Pick. Ten proces pozwala na dowolne wybranie dowolnego zatwierdzenia Git z innych gałęzi i dołączenie go do bieżącego HEAD drzewa roboczego.
Przykład 1:
W lokalnym repozytorium git mamy następujących 6 plików.
Jeden plik jest usuwany, na przykład plik5.txt.
Zatwierdź zmiany.
Spójrz teraz na dziennik. Plik5.txt zostanie usunięty.
Więc chcemy, aby Cherry-Wybierz zatwierdzenie, w którym dodaliśmy plik5.txt. Musimy znaleźć identyfikator zatwierdzenia pliku5.tx i uruchomić polecenie.
git cherry-pick
W tym przypadku identyfikator zatwierdzenia miejsca dodania pliku5.txt to a2f0124
Plik5.txt został przywrócony. My Cherry-wybraliśmy zobowiązanie.
Przykład 2:
Po prostu zmodyfikujmy plik6.txt i zatwierdź zmiany w mistrz gałąź.
Spójrz na drugą linię plik6.txt gdzie adres e-mail nie jest poprawnie określony.
Utwórz gałąź błędów i napraw problem. W tym samym czasie zmodyfikuj również plik5.txt tak, abyśmy mieli wiele zatwierdzeń wykonanych w gałęzi błędów, ale Cherry-Pick będzie tylko zatwierdzeniem wykonanym w pliku6.txt.
Plik6 zmodyfikowany w pluskwa gałąź.
Więc ogólnie wprowadziliśmy zmiany w file5 i file6 w oddziale Bug.
Wróćmy teraz do mistrz gałąź i Cherry-Wybierz zatwierdzenie wykonane tylko dla pliku6.txt.
Jak widać, zamiast scalać pluskwa rozgałęzić się do mistrz branch, mamy właśnie Cherry-Picked tylko konkretny commit i zastosowany w gałęzi master.
Reset Git
Reset Git to potężne polecenie cofania lokalnych zmian. Tak więc, aby cofnąć etap, wszystkie pliki przemieszczane są używane przez to polecenie.
Przykład
Zmodyfikuj plik i dodaj go do przemieszczania. Zresetuj za pomocą polecenia, jak pokazano, gdy etapowe zmiany są niestacjonarne.
Parametry reset git Komenda.
-miękki: Ten parametr wskaże HEAD na inne zatwierdzenie. Wszystkie pliki zostaną zmienione między oryginalnym HEAD a zatwierdzeniem zostaną umieszczone w poczekalni. Katalog roboczy jest nienaruszony.
Spójrz na bieżącą lokalizację HEAD.
Cofnijmy się o 5 zatwierdzeń w historii.
Potwierdź zmiany.
-mieszany: Ta opcja jest podobna do parametru miękkiego. Zwykle, gdy są jakieś złe zmiany, usuwasz je, naprawiasz później i ponownie zatwierdzasz. Zasadniczo musimy dodać do indeksu przy użyciu git add i wtedy git commit. Zmiany pozostają w drzewie roboczym.
Cofnijmy się o 2 zatwierdzenia w historii i zobaczmy, że pliki nie są śledzone.
Teraz dodaj pliki do przemieszczania i zatwierdź zmiany.
-ciężko: Ten parametr pozostanie do punktu, w którym istniał określony plik. Zmiany nie będą dostępne w drzewie roboczym.
Patrząc na powyższy log, wróćmy do punktu, w którym zatwierdzony został tylko plik 1, czyli ostatni wpis.
Za pomocą git reset - hard
Git Bisect
Znajdź dokładny commit, który złamał kod (w końcu wszyscy jesteśmy ludźmi). Często podczas testowania aplikacji słyszymy od naszych testerów, że jest błąd lub funkcja jest zepsuta, a Ty jako deweloper powiesz, że działała w zeszłym tygodniu. Więc co się stało i dlaczego pojawił się ten błąd?
Czasami zmiana w innym kodzie mogła mieć wpływ na twoją funkcję. Musisz poświęcić czas na przeglądanie historii, w której jest wiele zatwierdzeń, które są czasochłonne i trudne do śledzenia, która zmiana spowodowała uszkodzenie kodu.
Git Bisect jest poleceniem do znalezienia dokładnego zatwierdzenia, kiedy pojawił się błąd. Z Git bisect musisz wybrać dwa zatwierdzenia, jeden dobry i jeden zły. Mniej więcej w połowie między oboma zatwierdzeniami zostanie sprawdzona. Sprawdzasz każde zatwierdzenie jako złe lub dobre, dopóki nie zostanie znalezione zatwierdzenie, które spowodowało uszkodzenie błędu lub kodu.
Przykład:
- Utwórz nowe lokalne repozytorium git i utwórz plik o nazwie index.html
- Początkowa zawartość pliku, jak pokazano.
- Dodaj do przemieszczania i zatwierdź w repozytorium.
- Utwórz historię zatwierdzeń, jak pokazano, abyśmy mogli wybierać między dobrymi a złymi zatwierdzeniami. Teraz, gdy wstępne zatwierdzenie jest zakończone, wykonaj pozostałe zmiany, jak pokazano, i zatwierdź to samo. W sumie wykonamy 7 zatwierdzeń.
Druga zmiana
Trzecia zmiana
Czwarta zmiana
Piąta zmiana
Szósta zmiana
Siódma zmiana
Zatrzymajmy się tutaj. Mamy więc siedem zatwierdzeń.
Jeśli spojrzysz na stronę Html, wiersze po „Wszystkie 4 zdarzenia…” są błędne, a zatem dokumentacja nie jest poprawna. Musimy więc znaleźć zatwierdzenie, w którym błąd został wprowadzony, abyśmy mogli odpocząć GŁOWĄ na tym zatwierdzeniu.
Spójrzmy na dziennik i dowiedzmy się, że zły i dobre zaangażowanie.
Ostatnie zatwierdzenie jest nieprawidłowe, więc może to być złe zatwierdzenie. Zatwierdzenie zostało wprowadzone po trzecim zatwierdzeniu, więc możemy mieć rozszerzenie Trzecia zmiana jako dobre zobowiązanie.
Proces dzielenia na dwie rozpoczyna się od git bisect start i kończy się na git bisect reset.
git bisect źle // Ponieważ ostatnie zatwierdzenie jest złe. Nie ma potrzeby podawania identyfikatora zatwierdzenia.
git pół dobrze
Teraz możesz zobaczyć, że HEAD jest teraz pomiędzy połową złego i dobrego zaangażowania.
Spójrz na zawartość index.html i zobacz, czy jest dobry commit. Jeśli nie, błąd nadal nie jest wykrywany.
Nie do końca, że błąd nadal istnieje. Ostatnia linia jest błędna. Więc uciekamy git bisect bad ”. Nadal istnieje złe zatwierdzenie, a obecna treść jest nie do przyjęcia.
Powyższa treść jest poprawna i akceptowalna.
Uruchom „git log –oneline” i „git bisect good”.
Tak więc Piąta zmiana był pierwszym złym popełnieniem i naprawdę tak. Błąd został zidentyfikowany.
Bieżąca treść powinna znajdować się w ostatecznej dokumentacji.
Po zidentyfikowaniu złego zatwierdzenia możesz poinformować programistę, aby poprawił zmiany, które mogą polegać na zresetowaniu głowicy do czwartej zmiany, która była ostatnią dobrą zmianą.
Biegać ' git bisect reset ”Aby zakończyć proces.
Wniosek
W tym praktycznym poradniku GitHub staraliśmy się omówić wszystko, nad czym musiałby pracować programista, tj. Z punktu widzenia kontroli wersji i śledzenia.
W pierwszych trzech samouczkach z serii GitHub dowiedzieliśmy się o działaniach kontroli wersji, tworzeniu repozytoriów, żądaniach ściągnięcia, gałęziach, recenzjach kodu, organizacjach i zespołach, rozwidleniu repozytorium, etykietach, kamieniach milowych, problemach, tablicach projektów, wiki, wydaniach, integracji z Jira i kilkoma często używanymi poleceniami Git dla programistów.
Mamy nadzieję, że wszyscy programiści uznają to praktyczne podejście do GitHub i poleceń Git za przydatne w ich projektach.
=> Przeczytaj serię szkoleń Easy GitHub.
rekomendowane lektury
- Samouczek dotyczący integracji GitLab Jira
- Polecenia systemu Unix: podstawowe i zaawansowane polecenia systemu Unix z przykładami
- Integracja selenu z GitHub przy użyciu Eclipse
- Samouczek integracji JIRA i SVN
- Git kontra GitHub: poznaj różnice z przykładami
- Cucumber Selenium Tutorial: Cucumber Java Selenium Integracja WebDriver
- Samouczek GitHub dla programistów | Jak korzystać z GitHub
- Samouczek potoków w systemie Unix: Potoki w programowaniu w systemie Unix