Přejít k navigační liště

Zdroják » Různé » Git fork synchronizace

Git fork synchronizace

Články Různé

Už po několikáté jsem musel vzpomínat, jak správně synchronizovat forknutý repozitář z GitHubu. Znáte to také? Nejspíš ano. Pojďme si postup připomenout společně.

Nálepky:

Text vyšel původně na webu autora.

Proč je synchronizace potřeba?

V případě, že se jedná o jednorázovou kontribuci, není potřeba synchronizaci řešit. Postup je většinou následující:

  1. Fork původní repozitory.
  2. Klon forknuté repozitory.
  3. Lokální změny a push do forknuté repozitory.
  4. Pull request do původní repozitory.
  5. (Případně) Opakování kroků 3-4.
  6. Akceptace pull requestu.
  7. Dobrý pocit. 😀 😎

Pokud se ale vaše kontribuce opakuje, už je potřeba synchronizaci řešit, protože pokud jste si pro přispívání nevybrali mrtvý (anebo hodně stabilní) projekt, tak na původním repo probíhá aktivní vývoj a během doby, kdy probíhal proces vývoje a akceptace vašeho prvního pull requestu, už tam nejspíš někdo nakomitoval další změny.

Jak vypadá proces synchronizace ?

V následujícím obrázku přibyly k výše popsanému postupu dva nové kroky: 5. fetch a 6. push. To je právě ona synchronizace.

V obrázku pak už chybí další, cyklicky se opakující kroky, tj. pro druhý pull request by ještě přibyl krok 7. pull request, pro třetí pull request by to byly kroky 8. fetch + 9. push + 10. pull request atd.

Schéma synchronizace mezi Git repozitory

Jak se to dělá v Gitu?

Předpokládám, že fork už máme udělaný. Pro potřeby tohoto příkladu použiju jako původní repozitory gruntwork-io/terratest, kterou mám forknutou jako sw-samuraj/terratest.

(Všechny následující příkazy si můžete bez obav pouštět u sebe lokálně. Pouze pokud byste chtěli zkusit i push, tak si samozřejmě musíte udělat svůj vlastní fork.)

Nyní si uděláme klon forknuté repo:

git clone git@github.com:sw-samuraj/terratest.git

a vypíšeme si výchozí seznam remote repozitory:

$ git remote -v
origin	git@github.com:sw-samuraj/terratest.git (fetch)
origin	git@github.com:sw-samuraj/terratest.git (push)

Přidání původního repozitory

Původní repozitory – většinou nazývanou upstream – přidáme příkazem:

$ git remote add upstream git@github.com:gruntwork-io/terratest.git

Opět si vypíšeme seznam remote repozitory a vidíme, že máme dvě:

  • origin je náš nový fork.
  • upstream je původní repozitory,
$ git remote -v
origin	git@github.com:sw-samuraj/terratest.git (fetch)
origin	git@github.com:sw-samuraj/terratest.git (push)
upstream	git@github.com:gruntwork-io/terratest.git (fetch)
upstream	git@github.com:gruntwork-io/terratest.git (push)

Stažení změn z původního repozitory

Samotná synchronizace se skládá ze čtyř kroků:

  1. fetch změn v původní repozitory (upstream).
  2. checkout lokálního branche, kam chceme změny zpropagovat.
  3. merge daného upstream branche.
  4. push do forknuté (origin) repozitory.
$ git fetch upstream
$ git checkout master
$ git merge upstream/master
$ git push

Je jen na vás, jestli vaše změny uděláte před nebo po merge z upstream repozitory. Dobré pravidlo je udělat synchronizaci před zahájením práce na novém pull requestu.

A to je vše. Happy contributing!

Komentáře

Subscribe
Upozornit na
guest
3 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Harvie.CZ

Proc misto fetch+checkout+merge neudelat proste pull? Podle me to bude mit stejnej efekt.
Jeste je teda potreba rict, ze po merge i pull muze bejt obcas potreba commit, pokud se tam resil nejakej konflikt…

Jan Trejbal

Dobrým pravidlem je mít co pull request to (feature) branch. Potom je kontrola příchozích změn zbytečná, protože není třeba.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.