Jak zaktualizować rozwidlone repozytorium GitHub?


3602

Niedawno rozwidliłem projekt i zastosowałem kilka poprawek. Następnie utworzyłem żądanie ściągnięcia, które zostało następnie zaakceptowane.

Kilka dni później inny użytkownik wprowadził kolejną zmianę. Więc mój widelec nie zawiera tej zmiany.

Jak mogę wprowadzić tę zmianę do mojego widelca? Czy muszę usunąć i ponownie utworzyć widelec, gdy będę miał dalsze zmiany, aby wnieść swój wkład? Czy jest przycisk aktualizacji?


120
Można to również zrobić z interfejsu użytkownika github. Chciałbym podziękować [temu drugiemu plakatowi] [1]. [1]: stackoverflow.com/a/21131381/728141
Mike Schroll

2
Kolejny dobry post na blogu na ten temat - Aktualizowanie widelca GitHub
Arup Rakshit

3
Znalazłem to w artykułach pomocy Github: help.github.com/articles/syncing-a-fork
Pranav


Oto demo wideo, które robi to za pomocą dwóch kont github youtube.com/watch?v=kpE0gTX4ycE
lifebalance

Odpowiedzi:


3978

W lokalnym klonie swojego rozwidlonego repozytorium możesz dodać oryginalne repozytorium GitHub jako „zdalne”. („Piloty” są jak pseudonimy dla adresów URL repozytoriów - originna przykład jest jeden.) Następnie możesz pobrać wszystkie gałęzie z tego repozytorium nadrzędnego i zmienić podstawę pracy, aby kontynuować pracę nad wersją nadrzędną. Pod względem poleceń, które mogą wyglądać:

# Add the remote, call it "upstream":

git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

Jeśli nie chcesz przepisać historii swojej gałęzi master (na przykład ponieważ inne osoby mogły ją sklonować), powinieneś zastąpić ostatnią komendę git merge upstream/master. Aby jednak wysyłać kolejne żądania ściągania, które są tak czyste, jak to możliwe, prawdopodobnie lepiej jest zmienić bazę.


Jeśli dokonałeś zmiany bazy na gałąź upstream/master, może być konieczne wymuszenie wypychania w celu wypchnięcia go do własnego rozwidlonego repozytorium na GitHub. Zrobiłbyś to z:

git push -f origin master

Musisz użyć tylko -fza pierwszym razem po dokonaniu zmiany.


94
Ponieważ twój widelec istnieje tylko w github, a github nie ma narzędzi do wykonywania scalania przez interfejs sieciowy, więc poprawną odpowiedzią jest lokalne połączenie scalające i wypchnięcie zmian z powrotem do swojego widelca.
Tim Keating

29
Oto świetny samouczek, który znalazłem na temat pracy z githubem
Tim Keating

50
Szybka uwaga, że ​​zamiast konieczności zmiany bazy własnej gałęzi master, aby upewnić się, że zaczynasz od stanu czystego, prawdopodobnie powinieneś pracować na oddzielnej gałęzi i wysyłać z niej żądanie ściągnięcia. Utrzymuje to twojego mistrza w czystości dla wszelkich przyszłych fuzji i powstrzymuje cię od konieczności przepisywania historii, za pomocą -fktórej popsuje się wszystkich, którzy mogliby sklonować twoją wersję.
Mateusz Kowalczyk

11
Zamiast polecenia rebase użyłem następującego: W git merge --no-ff upstream/masterten sposób twoje zatwierdzenia nie są już na topie.
Steckdoserich

51
Kolejna awaria Gita. Jeśli to narzędzie ma obsługiwać rozproszoną współpracę, to dlaczego tak trudno jest wykonać podstawowy przepływ pracy? 4 miliony ludzi i 2200 głosów pozytywnych oznacza, że ​​narzędzie zawiodło. „możesz dodać oryginalne repozytorium GitHub jako„ zdalne ” - Dlaczego w ogóle trzeba to robić? Dlaczego nie robi się tego podczas rozwidlenia? Co jest takiego zepsutego w tym narzędziu?
jww 16.04.17

738

Od maja 2014 r. Można aktualizować widelec bezpośrednio z GitHub. To nadal działa od września 2017 r., ALE doprowadzi do brudnej historii zatwierdzeń.

  1. Otwórz widelec na GitHub.
  2. Kliknij na Pull Requests.
  3. Kliknij na New Pull Request. Domyślnie GitHub porówna oryginał z twoim widelcem i nie powinno być nic do porównania, jeśli nie wprowadzisz żadnych zmian.
  4. Kliknij, switching the basejeśli widzisz ten link. W przeciwnym razie ręcznie ustaw base forkupuszczanie na widelec i head forkna górę. Teraz GitHub porówna twój widelec z oryginałem i powinieneś zobaczyć wszystkie najnowsze zmiany. wprowadź opis zdjęcia tutaj
  5. Create pull requesti przypisz przewidywalną nazwę do żądania ściągnięcia (np Update from original.).
  6. Przewiń w dół do Merge pull request, ale jeszcze niczego nie klikaj.

Teraz masz trzy opcje, ale każda z nich doprowadzi do niezbyt czystej historii zatwierdzeń.

  1. Domyślnie stworzy brzydkie zatwierdzenie scalania.
  2. Jeśli klikniesz menu rozwijane i wybierzesz „Squash and merge”, wszystkie interweniujące zatwierdzenia zostaną zmiażdżone w jeden. Jest to najczęściej coś, czego nie chcesz.
  3. Jeśli klikniesz Rebase and merge, wszystkie zatwierdzenia zostaną wykonane „z” tobą, oryginalne PR będą łączyły się z twoim PR i wyświetli się GitHub This branch is X commits ahead, Y commits behind <original fork>.

Tak, możesz aktualizować swoje repozytorium przy użyciu upstream przy użyciu internetowego interfejsu GitHub, ale zrobienie tego popsunie twoją historię zatwierdzania. Kij do wiersza poleceń zamiast - to proste.


19
Raz zadziałało świetnie. Za drugim razem ten proces nie działał w ten sam sposób: link „Przełączanie bazy” nie pojawił się. A kiedy kliknę „Kliknij, aby utworzyć żądanie ściągnięcia”, utworzyłem PR w repozytorium SOURCE. NIE to, co chciałem ..
javadba

29
Nadal działa (Marchi 2015), mimo że nie ma już linku „Przełączanie bazy”. Musisz zmienić menu rozwijane „Baza”, aby oba wskazywały na widelec, a następnie pojawi się monit o „Porównaj między repozytoriami”, który zabierze Cię tam, gdzie chcesz.
mluisbrown,

8
Kwiecień 2015. Działa. Dzięki. Dostałem „Przełączanie na bazę”. Jednak krok 6 brzmiał „Utwórz żądanie ściągnięcia” -> wpisz komentarz -> „Utwórz żądanie ściągnięcia”. Skończyć z 1 zatwierdzeniem przed oryginałem.
Cartland

5
@cartland (lub inne) - tak, mówi „Ta gałąź jest o 1 zatwierdzenie wyprzedzona przed ...” Czy to jest coś, o co należy się martwić? Czy można pozbyć się tej wiadomości?
RenniePet

11
nie byłoby lepiej, wystarczy przycisk aktualizacji lub synchronizacji!
transformator

456

Oto oficjalny dokument GitHub dotyczący synchronizacji wideł :

Synchronizowanie widelca

Ustawić

Przed synchronizacją musisz dodać pilota, który wskazuje na repozytorium nadrzędne. Być może zrobiłeś to, gdy pierwotnie widelec.

Wskazówka: zsynchronizowanie rozwidlenia aktualizuje tylko lokalną kopię repozytorium; nie aktualizuje twojego repozytorium na GitHub.

$ git remote -v
# List the current remotes
origin  https://github.com/user/repo.git (fetch)
origin  https://github.com/user/repo.git (push)

$ git remote add upstream https://github.com/otheruser/repo.git
# Set a new remote

$ git remote -v
# Verify new remote
origin    https://github.com/user/repo.git (fetch)
origin    https://github.com/user/repo.git (push)
upstream  https://github.com/otheruser/repo.git (fetch)
upstream  https://github.com/otheruser/repo.git (push)

Synchronizacja

Aby zsynchronizować repozytorium z nadrzędnym, wymagane są dwa kroki: najpierw musisz pobrać ze zdalnego, a następnie scalić żądaną gałąź z lokalną.

Ujmujący

Pobieranie ze zdalnego repozytorium spowoduje przeniesienie jego gałęzi i odpowiednich zatwierdzeń. Są one przechowywane w lokalnym repozytorium w specjalnych oddziałach.

$ git fetch upstream
# Grab the upstream remote's branches
remote: Counting objects: 75, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62 (delta 27), reused 44 (delta 9)
Unpacking objects: 100% (62/62), done.
From https://github.com/otheruser/repo
 * [new branch]      master     -> upstream/master

Mamy teraz główny oddział upstream przechowywany w lokalnym oddziale upstream / master

$ git branch -va
# List all local and remote-tracking branches
* master                  a422352 My local commit
  remotes/origin/HEAD     -> origin/master
  remotes/origin/master   a422352 My local commit
  remotes/upstream/master 5fdff0f Some upstream commit

Scalanie

Po pobraniu repozytorium nadrzędnego chcemy scalić jego zmiany w naszym oddziale lokalnym. Spowoduje to zsynchronizowanie tego oddziału z nadrzędnym, bez utraty lokalnych zmian.

$ git checkout master
# Check out our local master branch
Switched to branch 'master'

$ git merge upstream/master
# Merge upstream's master into our own
Updating a422352..5fdff0f
Fast-forward
 README                    |    9 -------
 README.md                 |    7 ++++++
 2 files changed, 7 insertions(+), 9 deletions(-)
 delete mode 100644 README
 create mode 100644 README.md

Jeśli twój lokalny oddział nie ma żadnych unikalnych zatwierdzeń, git zamiast tego wykona „przewijanie do przodu”:

$ git merge upstream/master
Updating 34e91da..16c56ad
Fast-forward
 README.md                 |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Wskazówka: jeśli chcesz zaktualizować swoje repozytorium w GitHub, postępuj zgodnie z instrukcjami tutaj


1
To aktualizuje mój lokalny widelec, ale mój widelec na Github.com wciąż mówi „43 zatwierdza za”. Musiałem użyć techniki Lobzika, aby utworzyć dla siebie żądanie ściągnięcia, aby scalić główne zmiany w moim widelcu Github.com.
Michael McGinnis

11
@MichaelMcGinnis Po scaleniu lokalnym będziesz musiał przekazać zmiany do github. git push origin master
jumpnett

1
Może być mądry, aby naciskać --follow-tags: stackoverflow.com/a/26438076/667847
Kenny

1
Muszę to zrobić osobno dla wszystkich oddziałów git merge upstream/master, a następnie sprawdzić, aby rozwinąć oddział i zrobićgit merge upstream/develop
Shobi

stackoverflow.com/a/14074925/470749 był dla mnie pomocny, ponieważ otrzymywałem, Permission denied (publickey). fatal: Could not read from remote repository.gdy próbowałem pobrać z konta Facebook Github powyżej.
Ryan

98

Wiele odpowiedzi kończy się przesunięciem widelca o jeden zatwierdzenie przed repozytorium nadrzędnym. Ta odpowiedź zawiera podsumowanie kroków tutaj, które przeniosą widelec do tego samego zatwierdzenia, co rodzic .

  1. Zmień katalog na lokalne repozytorium.

    • Przełącz się na oddział główny, jeśli tak nie jest git checkout master
  2. Dodaj element nadrzędny jako zdalne repozytorium, git remote add upstream <repo-location>

  3. Kwestia git fetch upstream
  4. Kwestia git rebase upstream/master

    • Na tym etapie sprawdzasz, czy zatwierdza się to, co zostanie scalone, wpisując git status
  5. Kwestia git push origin master

Aby uzyskać więcej informacji na temat tych poleceń, patrz krok 3 .


13
@MT: Gdzie jednak wpisujesz te polecenia? Istota pytania, jak rozumiem, polega na tym, jak ponownie zsynchronizować osobisty widelec GitHub z głównym projektem i zrobić to wszystko z GitHub . Innymi słowy, jak możesz zaktualizować zdalny rozwidlenie bez lokalnego repozytorium?
Jan Y

4
@JohnY Korzystanie z GitHub zawsze tworzy dodatkowe zatwierdzenie. Musisz to wszystko zrobić w powłoce na lokalnym repozytorium, aby uniknąć tego dodatkowego zatwierdzenia.
Jonathan Cross

48

Przedmowa: Twój rozwidlenie jest „początkiem”, a repozytorium, z którego rozwidlasz się, to „upstream”.

Załóżmy, że sklonowałeś już swój widelec na swój komputer za pomocą następującego polecenia:

git clone git@github.com:your_name/project_name.git
cd project_name

Jeśli tak jest, musisz kontynuować w następującej kolejności:

  1. Dodaj „upstream” do sklonowanego repozytorium („origin”):

    git remote add upstream git@github.com:original_author/project_name.git
    
  2. Pobierz commits (i gałęzie) z „upstream”:

    git fetch upstream
    
  3. Przejdź do gałęzi „master” widelca („origin”):

    git checkout master
    
  4. Ukryj zmiany w gałęzi „master”:

    git stash
    
  5. Scal zmiany z gałęzi „master” „upstream” do swojej „master” gałęzi „origin”:

    git merge upstream/master
    
  6. Rozwiąż ewentualne konflikty scalania i zatwierdź połączenie

    git commit -am "Merged from upstream"
    
  7. Wciśnij zmiany do swojego widelca

    git push
    
  8. Odzyskaj swoje ukryte zmiany (jeśli istnieją)

    git stash pop
    
  9. Jesteś skończony! Gratulacje!

GitHub udostępnia także instrukcje dotyczące tego tematu: Synchronizowanie rozwidlenia


1
Pomógł częściowo: Czy to git remote add upstream git@github.com:original_author/project_name.gittylko alias git remote add upstream https://github.com/original_author/project_name.git?
Wolf

2
Wolf , zgaduję, że już o tym wiesz, ale dla potomności ... Jest to format ssh. help.github.com/articles/configuring-a-remote-for-a-fork
Brad Ellis

2
Dziękuję Ci bardzo. git stashi git stash popczęść bardzo pomocna
सत्यमेव जयते

To zadziałało. Po git merge upstream / master automatyczne scalanie nie powiodło się z powodu nieuporządkowanych ścieżek, które musiałem uruchomić git add -A, a następnie git commit -m „message”, to było aktualne.
highcenbug

47

Jeśli, podobnie jak ja, nigdy nie zobowiązujesz się bezpośrednio do opanowania , co naprawdę powinieneś, możesz wykonać następujące czynności.

Z lokalnego klonu widelca utwórz pilota zdalnego sterowania. Musisz to zrobić tylko raz:

git remote add upstream https://github.com/whoever/whatever.git

Następnie za każdym razem, gdy chcesz dogonić nadrzędną gałąź nadrzędną repozytorium, musisz:

git checkout master
git pull upstream master

Zakładając, że nigdy nie popełniłeś niczego samodzielnie, powinieneś już to zrobić. Teraz możesz popchnąć lokalnego mistrza do swojego oryginalnego widelca GitHub. Możesz również dokonać zmiany podstawy rozwoju na swoim aktualnym lokalnym komputerze głównym.

Po początkowej konfiguracji pobierania danych i sprawdzaniu danych głównych należy jedynie uruchomić następującą komendę, aby zsynchronizować dane główne z danymi wyjściowymi: git pull upstream master .


45

Od listopada 2013 r. W GitHub otwarto nieoficjalne żądanie funkcji z prośbą o dodanie bardzo prostej i intuicyjnej metody synchronizacji lokalnego rozwidlenia z nadrzędnym:

https://github.com/isaacs/github/issues/121

Uwaga: Ponieważ żądanie funkcji jest nieoficjalne, zaleca się również kontakt, support@github.comaby dodać wsparcie dla takiej funkcji, która ma zostać zaimplementowana. Powyższe nieoficjalne żądanie funkcji może być wykorzystane jako dowód na zainteresowanie związane z tym wdrożeniem.


23

Na dzień tej odpowiedzi GitHub nie ma ( a może powinienem już nie mówić? ) Tej funkcji w interfejsie internetowym. Możesz jednak poprosić support@github.como dodanie swojego głosu.

W międzyczasie użytkownik GitHub, bardiharborow, stworzył narzędzie do wykonania tego: https://upriver.github.io/

Źródło jest tutaj: https://github.com/upriver/upriver.github.io


2
Chociaż uważam to narzędzie za dobry pomysł, rzeczywistość jest ZŁA. Załadowałem tylko 20 repozytoriów z mojego konta, a nawet stopka przekierowuje na stronę, która nie istnieje. Jeśli to naprawię, będę wielkim orędownikiem.
sorin

2
Na dzień dzisiejszy z powodzeniem korzystałem z uprivera, aby zsynchronizować widelec z repozytorium upstream, więc działa on dla moich celów i będę go nadal używać.
NauticalMile

1
@sorin Te 20 repo / ograniczenie gałęzi (raczej jest teraz 30) pochodzi z domyślnych ustawień stronicowania GitHub. Aby to obsłużyć, należy wprowadzić pewne zmiany w kodzie.
Andreas


11

W rzeczywistości możliwe jest utworzenie rozgałęzienia w rozwidleniu z dowolnego zatwierdzenia pobierania w przeglądarce:

  • Otwórz https://github.com/<repo>/commits/<hash>, gdzie repo to Twój widelec, a skrót to pełny skrót zatwierdzenia, który można znaleźć w interfejsie sieciowym. Na przykład mogę otworzyć https://github.com/max630/linux/commits/0aa0313f9d576affd7747cc3f179feb097d28990 , co wskazuje na linux masterczas pisania.
  • Kliknij przycisk „Drzewo: ....”.
  • Wpisz nazwę nowego oddziału i naciśnij Enter

Wpisz opis zdjęcia tutaj

Następnie możesz pobrać tę gałąź do lokalnego klonu i nie będziesz musiał przesyłać wszystkich tych danych z powrotem do GitHub, gdy wypychasz zmiany na szczycie tego zatwierdzenia. Lub użyj interfejsu internetowego, aby zmienić coś w tej gałęzi.

Jak to działa (zgaduję, nie wiem, jak dokładnie to robi GitHub): widelce współużytkują pamięć obiektów i używają przestrzeni nazw do oddzielania odniesień użytkowników. Dzięki temu możesz uzyskać dostęp do wszystkich zatwierdzeń przez widelec, nawet jeśli nie istniały one do czasu rozwidlenia.


2
To jest świetne! Pozwala to uniknąć całkowicie bezcelowego przesyłania tych zatwierdzeń do github.
Rotsor,

9

Wykonaj poniższe kroki. Próbowałem ich i to mi pomogło.

Kasa do oddziału

Składnia: git branch yourDevelopmentBranch
Przykład: git checkout master

Pobierz gałąź repozytorium źródłowego, aby uzyskać najnowszy kod

Składnia: git pull https://github.com/tastejs/awesome-app-ideas master
Przykład: git pull https://github.com/ORIGINAL_OWNER/ORIGINAL_REPO.git BRANCH_NAME


1
Jeśli używasz GitHub, możesz również chcieć przekazać zmiany do swojego oddziału GitHub. git push HttpsForYourForkOfTheRepo BRANCH_NAME
user3731622,

9

Aktualizuję moje rozwidlone repo za pomocą tej jednej linii:

git pull https://github.com/forkuser/forkedrepo.git branch

Użyj tego, jeśli nie chcesz dodawać kolejnego zdalnego punktu końcowego do swojego projektu, ponieważ zamieszczono tutaj inne rozwiązania.


2
Czy są na to ograniczenia? tzn. czy ma to zastosowanie tylko w przypadkach, w których nie dodano zatwierdzeń, fuzji, żądań ściągnięcia lub zleceń ściągnięcia połączono w górę od czasu ostatniej aktualizacji?
LightCC

1
działa jak normalne ściąganie ze zdalnej gałęzi. Jeśli zrobiłeś X zatwierdzeń na lokalnym repozytorium, a teraz jesteś Y zatwierdzeniem za oryginalnym repozytorium, spowoduje przeniesienie zatwierdzeń Y do lokalnego oddziału i prawdopodobnie doprowadzi do konfliktów do rozwiązania.
R.Bravo,

1
@LightCC Nie różni się niczym od ściągania wcześniej dodanego pilota, z wyjątkiem faktu, że nie dodałeś pilota . Wadą jest to, że za każdym razem będziesz musiał wprowadzić pełny adres URL repozytorium pull.
Marc.2377

1
Jest to idealne rozwiązanie, jeśli nie musisz wyciągać wiele razy z oryginalnego repozytorium, lub jeśli projekt rozwidlony jest stosunkowo prosty.
AxeEffect

7

Jako uzupełnienie tej odpowiedzi szukałem sposobu na zaktualizowanie wszystkich zdalnych gałęzi mojego sklonowanego repo ( origin ) z gałęzi upstream za jednym razem. Tak to zrobiłem.

Zakłada się, że skonfigurowałeś już zdalne skierowanie w górę do repozytorium źródłowego (skąd pochodzi źródło ) i zsynchronizowałeś go git fetch upstream.

Następnie uruchomić:

for branch in $(git ls-remote --heads upstream|sed 's#^.*refs/heads/##'); do git push origin refs/remotes/upstream/$branch:refs/heads/$branch; done

Pierwsza część tego polecenia zawiera listę wszystkich głowic w zdalnym repozytorium nadrzędnym i usuwa SHA-1, a następnie refs/heads/prefiks nazwy gałęzi.

Następnie dla każdej z tych gałęzi wypycha lokalną kopię wcześniejszej zdalnej gałęzi śledzenia ( refs/remotes/upstream/<branch>po stronie lokalnej) bezpośrednio do zdalnej gałęzi na początku ( refs/heads/<branch>po stronie zdalnej).

Każde z tych poleceń synchronizacji gałęzi może się nie powieść z jednego z dwóch powodów: albo gałąź nadrzędna została przepisana, albo wypychasz zatwierdzenia z tej gałęzi do swojego widelca. W pierwszym przypadku, w którym nic nie przypisałeś gałęzi widelca, możesz bezpiecznie naciskać mocno (dodaj przełącznik -f , tj. git push -fW powyższym poleceniu). W drugim przypadku jest to normalne, ponieważ rozgałęzienie rozgałęzienia się rozdzieliło i nie można oczekiwać, że polecenie synchronizacji zadziała, dopóki zatwierdzenia nie zostaną ponownie połączone w górę .


6

Aplikacja „Pull” to rozwiązanie do automatycznej konfiguracji i zapomnienia. Zsynchronizuje domyślną gałąź twojego widelca z repozytorium nadrzędnym.

Odwiedź adres URL, kliknij zielony przycisk „Zainstaluj” i wybierz repozytoria, w których chcesz włączyć automatyczną synchronizację.

Oddział jest aktualizowany raz na godzinę bezpośrednio na GitHub, na komputerze lokalnym musisz pobrać oddział główny, aby upewnić się, że twoja kopia lokalna jest zsynchronizowana.


2
Pamiętaj, że dzięki podstawowej konfiguracji możesz utracić zmiany wprowadzone w rozwidlonym repozytorium. Aby zachować zmiany, skonfiguruj plik konfiguracyjny i określ mergemethod. Więcej na ten temat tutaj
Saurabh P Bhandari

1
Zauważyłem, że podstawowa konfiguracja wysyła żądania ściągania i łączy je (w przeciwieństwie do tego, co podano w dokumentacji). Jest to nieco denerwujące, ale rozwiązuje problem utraty danych?
krlmlr

4

Android Studio nauczył się teraz obsługi repozytoriów widełek GitHub (nie musisz nawet dodawać zdalnego repozytorium za pomocą polecenia konsoli).

Otwórz menu VCSGit

I zwróć uwagę na dwa ostatnie elementy menu podręcznego:

  • Zrestartuj mój widelec GitHub

  • Utwórz żądanie ściągnięcia

Spróbuj ich. Pierwszego używam do synchronizacji mojego lokalnego repozytorium. W każdym razie gałęzie z nadrzędnego zdalnego repozytorium („upstream”) będą dostępne w Android Studio po kliknięciu „Rebase my GitHub fork” i będziesz mógł z nimi łatwo operować.

(Używam Androida Studio 3.0 z wtyczkami „Git Integration” i „GitHub”).

Wpisz opis zdjęcia tutaj


4

Po sklonowaniu rozwidlonego repozytorium przejdź do ścieżki katalogu, w której znajduje się klon, i kilku wierszy w terminalu Git Bash.

$ cd project-name

$ git remote add upstream https://github.com/user-name/project-name.git
 # Adding the upstream -> the main repo with which you wanna sync

$ git remote -v # you will see the upstream here 

$ git checkout master # see if you are already on master branch

$ git fetch upstream

I dobrze, że możesz iść. Wszystkie zaktualizowane zmiany w głównym repozytorium zostaną wprowadzone do repozytorium wideł.

Komenda „fetch” jest niezbędna do zachowania aktualności w projekcie: tylko podczas wykonywania „git fetch” będziesz informowany o zmianach, które twoi koledzy wypchnęli na zdalny serwer.

Nadal możesz odwiedzić tutaj, aby uzyskać dalsze zapytania


4

Jeśli ustawisz swój upstream. Sprawdź za pomocą git remote -v, to wystarczy.

git fetch upstream
git checkout master
git merge --no-edit upstream/master
git push

2

Zależy to od wielkości repozytorium i sposobu jego rozwidlenia.

Jeśli jest to dość duże repozytorium, być może chciałbyś nim zarządzać w specjalny sposób (np. Historia upuszczania). Zasadniczo można uzyskać różnice między bieżącą a wcześniejszą wersją, zatwierdzić je, a następnie wybrać ponownie do opanowania.

Spróbuj przeczytać ten . Opisuje, jak obsługiwać duże repozytoria Git i jak je przesyłać za pomocą najnowszych zmian.


2

Chciałbym dodać do użytkownika @ krlmlr odpowiedź .

Początkowo rozwidlony repozytorium jeden oddział o nazwie: master. Jeśli pracujesz nad nową funkcją lub poprawką, zazwyczaj tworzysz nowy oddziałfeature i wprowadzasz zmiany.

Jeśli chcesz, aby rozwidlone repozytorium było zsynchronizowane z repozytorium nadrzędnym, możesz skonfigurować plik konfiguracyjny ( pull.yml) dla aplikacji Pull ( w gałęzi funkcji ) w następujący sposób:

version: "1"
rules:
  - base: feature
    upstream: master
    mergeMethod: merge
  - base: master
    upstream: parent_repo:master
    mergeMethod: hardreset

Dzięki temu mastergałąź rozwidlonego repozytorium jest na bieżąco z repozytorium nadrzędnym. Utrzymuje featuregałąź rozwidlonego repo aktualizowaną poprzez mastergałąź rozwidlonego repo, łącząc to samo. Zakłada się, żefeature gałąź jest gałąź domyślną, która zawiera plik konfiguracyjny.

Oto dwie z mergemethodsnich, jedna hardresetpomaga wymuszać synchronizację zmian w mastergałęzi rozwidlonego repozytorium z repozytorium nadrzędnym, a druga metoda merge. Ta metoda służy do scalania zmian dokonanych przez Ciebie w featureoddziale i zmian dokonanych z powodu wymuszenia synchronizacji wmaster oddziale. W przypadku konfliktu scalenia aplikacja pull pozwoli ci wybrać następny kierunek działania podczas żądania pull.

Możesz przeczytać o podstawowych i zaawansowanych konfiguracjach i różnych mergemethods tutaj .

Obecnie używam tej konfiguracji w moim rozwidlonym repozytorium tutaj, aby mieć pewność, że wymagane tutaj ulepszenie pozostanie aktualne.


1

Utrzymywanie rozwidlonego repozytorium zawsze wymaga aktualizacji na dwa sposoby.

1. Utwórz rozgałęzienia z głównego widelca i dokonaj tam zmian .

Więc kiedy twoje żądanie ściągnięcia zostanie zaakceptowane, możesz bezpiecznie usunąć gałąź, ponieważ Twój przekazany kod będzie wtedy dostępny w twoim głównym repozytorium w wersji rozwidlonej, gdy zaktualizujesz go za pomocą upstream. Dzięki temu twój mistrz będzie zawsze w czystym stanie, aby utworzyć nowy oddział, aby dokonać kolejnej zmiany.

2. Utwórz zaplanowane zadanie dla wzorca widelca, aby wykonać aktualizację automatycznie .

Można to zrobić za pomocą crona . Oto przykładowy kod, jeśli robisz to w systemie Linux.

$ crontab -e

umieść ten kod, crontab fileaby wykonać zadanie co godzinę.

0 * * * * sh ~/cron.sh

następnie utwórz cron.shplik skryptu i interakcję git z ssh-agent i / lub oczekuj, jak poniżej

#!/bin/sh
WORKDIR=/path/to/your/dir   
REPOSITORY=<name of your repo>
MASTER="git@github.com:<username>/$REPOSITORY.git"   
UPSTREAM=git@github.com:<upstream>/<name of the repo>.git  

cd $WORKDIR && rm -rf $REPOSITORY
eval `ssh-agent` && expect ~/.ssh/agent && ssh-add -l
git clone $MASTER && cd $REPOSITORY && git checkout master
git remote add upstream $UPSTREAM && git fetch --prune upstream
if [ `git rev-list HEAD...upstream/master --count` -eq 0 ]
then
    echo "all the same, do nothing"
else
    echo "update exist, do rebase!"
    git reset --hard upstream/master
    git push origin master --force
fi
cd $WORKDIR && rm -rf $REPOSITORY
eval `ssh-agent -k`

Sprawdź swoje rozwidlone repozytorium. Od czasu do czasu zawsze wyświetla to powiadomienie:

Ta gałąź ma nawet <upstream>: master .

wprowadź opis zdjęcia tutaj


0

Użyj tych poleceń (na szczęście)

git remote -v
git pull
git fetch upstream
git checkout master
git merge upstream/master --no-ff
git add .
git commit -m"Sync with upstream repository."
git push -v
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.