Wprowadzenie do Git Origin Master
Podczas pracy z dowolnym projektem z Git niezbędna jest wiedza o jego pilocie. Zasadniczo, z git będziesz pracował na zdalnym repozytorium, które będzie zarządzane za pomocą wersji przez git. Zdalny w przeciwieństwie do tego terminu sugeruje dostępność kodu na serwerze, który może być lokalny lub podłączony przez Internet. Repozytoriom tym można przypisać kategorie dostępu do odczytu i zapisu w zależności od typu użytkowników, którzy uzyskują do nich dostęp. Dlatego współpracując z innymi przy opracowywaniu, musimy zarządzać tymi repozytoriami (w tym także tworzyć i usuwać repozytoria), a także przesyłać i pobierać do nich dane. W tym temacie dowiemy się o Git Origin Master.
Za pomocą polecenia Git Remote można dowiedzieć się, na którym zdalnym repozytorze pracujemy. To polecenie wyświetla ich krótkie nazwy, o których administrator lub twórca repozytorium mógł wspomnieć podczas jego tworzenia. Jeśli nazwa domyślnie nie jest podana, to krótka nazwa nadawana repozytorium, z którego mogliśmy sklonować. Na poniższym zrzucie ekranu możesz je zobaczyć. Sklonowałem repozytorium z GitHub i trzymałem w katalogu test_git_tools, który domyślnie dodaje repozytorium o nazwie origin. Aby zobaczyć więcej szczegółów repo, możemy dać git remote -v, jak pokazano poniżej, i wyświetli listę wszystkich pilotów wraz z ich krótkimi nazwami, na których pracuje programista. Tutaj jest tylko jeden.
Możemy dodać zdalne do repozytorium, które chcemy sklonować w prosty sposób, używając git remote add. Możesz zapoznać się z poniższym zrzutem ekranu, gdzie dodałem test_get remote do https://github.com/aliraju4280/test_git_tools.git i wymieniłem je z opcją git remote -v.
Widzieliśmy, że po sklonowaniu kod źródłowy jest domyślnie nadawaną mu krótką nazwą. Musimy więc pobrać polecenie git, którego można użyć do aktualizacji lokalnego repozytorium, w którym sklonowaliśmy. W rzeczywistości git fetch origin pobierze aktualizacje do katalogu roboczego. Pobiera tylko dane, ale nie łączy automatycznie swojego lokalnego repozytorium.
Musimy to wykonać ręcznie. Alternatywnie, możemy użyć polecenia git pull, które automatycznie wykona to połączone zadanie pobierania danych i scalania ich z master lub inną gałęzią śledzoną przez polecenie git clone podczas tworzenia naszego katalogu roboczego.
Możemy użyć git push, który będzie działał tylko wtedy, gdy użytkownik będzie miał prawo do zapisu, aby wysłać naszą pracę do źródła, z którego sklonowaliśmy, który będzie zdalny. Polecenie to git push
Gdzie źródłem jest zdalna krótka nazwa, jeśli nie było żadnej nazwy. będzie nazwą segmentu bitów lub gałęzi GitHub. Domyślnie, gdy utworzysz gałąź w repozytorium, będzie ona nazywała się gałęzią główną, a ta konkretna gałąź w korporacyjnym środowisku programistycznym będzie zsynchronizowana z produkcją i musimy być ostrożni, zanim zmienimy lub scalimy coś, aby opanować. Wszystko, co zrobi się mistrzowi, będzie śledzone i od czasu do czasu kontrolowane. Więc kiedy musimy pracować nad kodem źródłowym, tworzymy kopię z mastera i ten brach może być funkcjonalny lub niestandardowy. Pracujemy nad tymi skopiowanymi lub opcjonalnymi gałęziami, a gdy opracowany kod jest stabilny, to tylko łączymy go z gałęzią master i nie wszyscy programiści mają do tego uprawnienia. Więc kiedy wypychamy cokolwiek do master bezpośrednio, do którego moglibyśmy mieć dostęp, dajemy komendę jako git push origin master / git pull origin master i jeśli pracujemy na operacji lub innym typie bracha, który został stworzony z master lub innej gałęzi, wtedy podamy jako git push origin feature_branchname / git pull origin feature_branchname.
Początkowy wzorzec -–> może być interpretowany jako gałąź nadrzędna na zdalnej nazwie zwanej początkiem.
Sprawdzanie pilota Origin
Jeśli chcemy uzyskać dodatkowe informacje na temat zdalnej gałęzi, git udostępnia coś, co nazywa się poleceniem git show, którego można użyć jak poniżej, np.
Ta konkretna lista wyświetli adres URL, a także szczegóły gałęzi śledzenia dla pilota. Szczegóły tego polecenia będą przydatne, gdy będziemy pracować z wieloma pilotami i gałęziami, ponieważ mogą one zapewnić, na której gałęzi możemy szczegółowo przeciągnąć lub wcisnąć nasze zmiany. Tutaj, ponieważ mam tylko jedną gałąź utworzoną powyżej zrzutu ekranu, zawiera tylko te szczegóły. Aby uzyskać więcej informacji, wziąłem zrzut ekranu z oficjalnej strony dokumentacji git poniżej:
Jeśli widzimy nad poleceniem git remote show origin, wyświetla ono szczegóły około pięciu gałęzi i które gałęzie można połączyć z daną gałęzią wraz ze szczegółami push i pull, np. Kiedy dajemy git push lub git pull, a następnie do której gałęzi szczegóły zostaną przesłane lub pobrane z.
Możemy również zmienić nazwę zdalnego źródła na inną nazwę, używając polecenia zmiany nazwy, jak pokazano poniżej
git zdalnie zmień nazwę pochodzenia na test_origin
na powyższym zrzucie ekranu z powodzeniem zmieniłem pilot źródłowy na test_origin, a to polecenie zmieni również wszystkie jego odniesienia do śledzenia. Możemy użyć wszystkich powyższych poleceń, które widzieliśmy wcześniej, z nową zdalną nazwą w miejscu pochodzenia, jak poniżej.
git push test_origin master / git pull test_origin master.
Podobnie możemy usunąć utworzony pilot za pomocą polecenia git remote remove lub git remote rm, jak pokazano poniżej
po usunięciu pilota wszystkie odniesienia do śledzenia również zostaną usunięte. Dlatego musimy zachować ostrożność podczas korzystania z tego polecenia.
Kiedy więc zaczniemy pracować z git, origin i master, są to podstawy, a ich znajomość stanie się boomem, gdy pomylimy się z poleceniami pull lub push i merge, szczególnie gdy na twoim serwerze jest wiele pilotów lub gałęzi.
Polecane artykuły
To jest przewodnik po Git Origin Master. Tutaj omawiamy zdalne polecenie i gałęzie Git oraz Inspekcję pilota Origin. Możesz także spojrzeć na następujący artykuł, aby dowiedzieć się więcej -
- Co to jest Git Fetch?
- Co to jest Git Branch?
- Terminologia Git
- Alternatywy Git
- Trzy etapy cyklu życia Git z przepływem pracy
- Jak korzystać z GIT Cherry-pick z Przykładem?