Zaimplementować przepływ pracy typu fork

Ukończone

Rozwidlenie to kopia repozytorium. Forkowanie repozytorium umożliwia swobodne eksperymentowanie ze zmianami bez wpływu na oryginalny projekt.

Najczęściej forki są używane do zaproponowania zmian w projekcie kogoś innego lub użycia projektu innego użytkownika jako punktu wyjścia dla twojego pomysłu.

Rozgałęzienie to kompletna kopia repozytorium, w tym wszystkie pliki, zatwierdzenia i (opcjonalnie) gałęzie.

Forki to doskonały sposób wspierania workflowu Inner Source: możesz utworzyć forka, aby sugerować zmiany, gdy nie masz uprawnień do bezpośredniego zapisu w oryginalnym projekcie. Gdy będziesz gotowy, aby udostępnić te zmiany, łatwo jest je przekazać z powrotem przy użyciu żądań przeciągnięcia.

Co kryje się w widelcu?

Fork zaczyna się od całej zawartości repozytorium nadrzędnego (oryginalnego). Możesz uwzględnić wszystkie gałęzie lub ograniczyć je tylko do gałęzi domyślnej podczas tworzenia rozwidlenia.

Ważne uwagi:

  • Żadne uprawnienia, zasady ani potoki kompilacji nie są kopiowane.
  • Nowe rozwidlenie działa tak, jakby ktoś sklonował oryginalne repozytorium, a następnie przesłał je do nowego, pustego repozytorium.
  • Po utworzeniu rozwidlenia nowe pliki, foldery i gałęzie nie są współużytkowane między repozytoriami, chyba że pull request je wprowadza.

Udostępnianie kodu między forkami

Żądania ściągnięcia można tworzyć w obu kierunkach: z fork do upstream lub z upstream do fork. Najbardziej typowym podejściem jest od fork do upstream.

Uprawnienia, zasady, buildy i elementy robocze repozytorium docelowego będą stosowane do pull requestu.

Wybieranie między gałęziami i forkami

  • Małe zespoły (2–5 deweloperów): zalecamy pracę w jednym repozytorium. Wszyscy powinni pracować na gałęziach tematycznych, a gałąź główna powinna być chroniona za pomocą zasad dotyczących gałęzi.

  • Większe zespoły: W miarę rozwoju zespołu możesz się przekonać, że ten układ przestaje być wystarczający i będziesz wolał przejść na przepływ pracy wykorzystujący forki.

  • Kiedy należy używać forki:

    • Repozytorium ma wielu przypadkowych lub rzadkich współautorów (takich jak projekt open source).
    • Tylko główni współautorzy mają bezpośrednie prawa do zatwierdzania w repozytorium.
    • Chcesz, aby współpracownicy spoza podstawowego zespołu pracowali z forku.
    • Chcesz odizolować zmiany, aż będziesz mieć możliwość przejrzenia pracy.

Przepływ pracy rozwidlania

Poniżej przedstawiono podstawowe kroki przepływu pracy forkowania:

  1. Utwórz forka.
  2. Sklonuj go lokalnie.
  3. Wprowadź zmiany lokalnie i prześlij je do gałęzi.
  4. Utwórz i ukończ żądanie ściągnięcia w górę.
  5. Zsynchronizuj swoje rozgałęzienie z najnowszymi zmianami z nadrzędnego repozytorium.

Krok 1. Tworzenie rozwidlenia

  1. Przejdź do repozytorium, które chcesz sforkować, a następnie wybierz "Fork".
  2. Określ nazwę i wybierz projekt, w którym ma zostać utworzony fork.
  3. Jeśli repozytorium zawiera wiele gałęzi tematycznych, zalecamy rozwidlenie jedynie gałęzi domyślnej.
  4. Wybierz wielokropek, a następnie pozycję "Rozwidlenie", aby utworzyć rozwidlenie.

Diagram przedstawiający tworzenie rozwidlenia.

Uwaga

Aby utworzyć fork, musisz mieć uprawnienie Tworzenie repozytorium w wybranym projekcie. Zalecamy utworzenie dedykowanego projektu dla rozwidleń (forks), w którym wszyscy współpracownicy mają uprawnienie do tworzenia repozytoriów.

Krok 2: Sklonuj swoje fork lokalnie

Gdy rozwidlenie będzie gotowe, sklonuj go przy użyciu wiersza polecenia lub środowiska IDE, takiego jak Visual Studio. Fork będzie twoim źródłem zdalnym.

git clone {your_fork_url}
For convenience, after cloning, you'll want to add the upstream repository (where you forked from) as a remote named upstream:

```bash
git remote add upstream {upstream_url}

Krok 3. Wprowadzanie i wypychanie zmian

Można pracować bezpośrednio w gałęzi głównej — w końcu ten fork jest twoją kopią repozytorium. Zalecamy jednak nadal pracować w gałęzi tematycznej, ponieważ:

  • Umożliwia to jednoczesne utrzymywanie wielu niezależnych strumieni roboczych.
  • Zmniejsza to zamieszanie później, gdy chcesz zsynchronizować zmiany w swoim forku.

Wprowadź i zatwierdź zmiany w zwykły sposób. Po zakończeniu wprowadzania zmian, wprowadź je do origin (twoje rozwidlenie).

Krok 4. Tworzenie i wykonywanie żądania ściągnięcia

Otwórz żądanie ściągnięcia z rozwidlenia do nadrzędnego repozytorium. Wszystkie zasady, wymagani recenzenci i kompilacje zostaną zastosowane w repozytorium nadrzędnym. Po spełnieniu wszystkich zasad żądanie ściągnięcia można ukończyć, a zmiany stają się stałą częścią nadrzędnego repozytorium.

Diagram przedstawiający tworzenie i zamykanie pull requesta.

Ważny

Każda osoba z uprawnieniami do odczytu może otworzyć pull request do upstream. Jeśli skonfigurowano potok kompilacji żądania ściągnięcia, kompilacja zostanie uruchomiona względem kodu wprowadzonego w rozwidleniu.

Krok 5: Zsynchronizuj swój fork z najnowszymi zmianami

Gdy żądanie ściągnięcia zostanie zaakceptowane do nadrzędnego strumienia, upewnij się, że rozwidlenie odzwierciedla najnowszy stan repozytorium.

Zalecamy ponowne łączenie gałęzi głównej nadrzędnej (przy założeniu, że głównym elementem jest gałąź programowania):

git fetch upstream main
git rebase upstream/main
git push origin

Zalety procesu rozwidlenia

Przepływ pracy rozwidlenia umożliwia izolowanie zmian z repozytorium głównego, aż będziesz gotów do ich zintegrowania. Kiedy będziesz gotowy, integracja kodu jest tak prosta, jak ukończenie pull request.

Takie podejście zapewnia:

  • Bezpieczeństwo: Zmiany są izolowane do momentu dokonania przeglądu.
  • Współpraca: wiele osób może pracować nad różnymi funkcjami jednocześnie.
  • Jakość: wszystkie zmiany przechodzą przez ten sam proces przeglądu.
  • Elastyczność: Współautorzy nie potrzebują uprawnień do zapisu w repozytorium głównym.