Jak zsynchronizować kopię (fork) z głównym repozytorium na Github

Opublikowane przez Tomasz Prasołek w dniu 17 listopada 2018

Pod koniec października postanowiłem, że czynnie dołączę do społeczności GitHub (biernie już dawno dołączyłem zakładając tam konto 🙂 ). Postanowiłem wspomóc na GitHubie jeden projekt – narzędzie git-istage. A wszystko zaczyna się od tego, że trzeba zrobić fork tego repozytorium, w którym chcemy wprowadzić zmiany.

git-istage

14 października Immo Landwerth napisał na Twitterze, że stworzył narzędzie do Gita:

Want to review & stage changes quickly from the command line? Check out my `git istage` tool. You can now simply install it via `dotnet tool install git-istage -g`. https://t.co/I7wwqcpc0Q

— Immo Landwerth (@terrajobst) 14 października 2018

Postanowiłem zobaczyć co to za narzędzie i jak ono działa. Jest to narzędzie pomocne w dodawaniu zmian do stage’a. Coś jak polecenie git add -p, ale bardziej elastyczne. Zauważyłem na Githubie, że są otwarte Issues do repozytorium tego narzędzia. Jednym z nich była prośba o dodanie listy skrótów klawiszowych w programie, aby nie trzeba było otwierać dokumentacji. Pomyślałem, że to zadanie nie może być trudne i chciałem to zrobić. To był mój pierwszy raz jak robiłem takie rzeczy, czyli mówiąc poważnie: kontrybuowanie w projekcie open source 🙂

Od czego zacząłem?

Mój pierwszy fork

Najpierw zrobiłem fork repozytorium projektu, które chce się poprawić. Fork jest to kopia repozytorium, ale zrobiona na serwerze, nie lokalnie. Następnie sklonowałem tego forka lokalnie u siebie na dysku i zacząłem programować.

Po jakimś czasie miałem zrobionych kilka commitów na własnych branchu. Chciałem zrobić z tego pull requesta. Zauważyłem jednak, że na gałęzi master w głównym repo projektu nastąpiły zmiany. W normalnych warunkach, aby w swoim branchu mieć najnowsze commity, to najpierw ściągnął bym najnowsze zmiany na master. Przełączył się na swój branch i zrobił to:

git rebase master

Rozwiązał ewentualne konflikty i tyle. Jednak poprawki zrobione przeze mnie były na klonie repozytorium z mojego konta. Główne repozytorium jest w innym miejscu na GitHubie. Co zrobić?

Podczas klonowania git automatycznie dodaje URL tego repozytorium do konfiguracji projektu, aby było wiadomo skąd ściągać i gdzie wysyłać zrobione przeze mnie zmiany. Można to sprawdzić poleceniem:

git remote -v

Widać, że URL wskazuje na mojego GitHuba. Domyślna nazwa dla takiego URLa to origin – taka jest przyjęta konwencja. To jest tylko string, można to zmienić na co się tylko chce, ale nie zalecam 🙂

Wiele zdalnych repozytoriów

Jednak można dodać więcej takich ścieżek. Dodam teraz ścieżkę do oryginalnego repozytorium projektu git-istage, czyli: https://github.com/terrajobst/git-istage

git remote add upstream https://github.com/terrajobst/git-istage

Widać, że mamy teraz skonfigurowane 2 ścieżki do repozytoriów:

Aby ściągnąć najnowsze zmiany z głównego repozytorium tego projektu wpisujemy:

git fetch upstream

Ściągnęło nam branch upstream/master, który wskazuje na branch master z URL: https://github.com/terrajobst/git-istage. Wszystkie dostępne branche w naszym repozytorium możemy sprawdzić poleceniem:

git branch -a

Zobaczymy, że mamy kilka branchów master:

Teraz aby zsynchronizować najnowsze zmiany wystarczy wpisać:

git rebase upstream/master

I mamy już aktualnego naszego lokalnego mastera. Teraz wystarczy zrobić rebase naszego brancha i wszystko będzie aktualne, można wrócić do programowania.

Przygotowałem jeszcze schemat, aby w ładniejszy sposób pokazać wszystkie te zależności między repozytoriami:

Podsumowanie

1 listopada po kilkunastu poprawkach mój pull request został zaakceptowany 🙂 Lista skrótów klawiszowych mojego autorstwa jest dostępna dla wszystkich korzystających z tego narzędzia 🙂 Osobiście korzystam z tego narzędzia i polecam również Wam. Bardzo usprawnia dodawania plików do stage’a. Na początku trzeba się nauczyć kilku skróty klawiszowych (już jest dostępna lista skrótów, pokazywana po naciśnięciu przycisku F1) , ale jak się już się ich nauczy to obsługa tego narzędzia jest bardzo szybka.

Zródła:
https://help.github.com/articles/configuring-a-remote-for-a-fork/