Najlepsza praktyka śledzenia źródła w widelcu na github

Question

Podsumowanie: Jakie są najlepsze praktyki dotyczące długotrwałego śledzenia repozytoriów, w których chcesz zachować zestaw zmian lokalnych?

Chcę zachować widelec na aktualnej wersji Github, ale nadal zezwalam na wyraźne śledzenie zmian unikalnych dla widelca. (Do tej dyskusji załóżmy, że upstream punkty do głównego repozytorium projektu i że origin odnosi się do mojego talerza z repozytorium)

Wyobraźmy mam coś takiego, gdzie rozwidlony repozytorium gdy upstream/master był w E.

Upstream: 
A-B-C-D-E-F 


Fork:  
A-B-C-D-E ----- P ------T 
     \-L-M-/ \-Q-R-/ 

Po rozwidleniu repozytorium utworzyłem dwie gałęzie funkcjonalne (LM i QR), aby dodać nowe funkcje, których potrzebowałem i scalić je z powrotem do mojego pochodzenia/wzorca. Teraz moja filia ma ulepszenia, które nie istnieją wcześniej.

Uważam, że upstream ma kilka interesujących poprawek, więc chcę przywrócić synchronizację z wcześniejszym oprogramowaniem. Opierając się na większości odniesień, które znalazłem (git hub fork), zalecanym sposobem na to jest połączenie wyższego/głównego z twoim początkiem/wzorcem i kontynuowanie na twojej drodze. Więc chciałbym wydawać takie polecenia jak:

git checkout master 
git fetch upstream 
git git merge upstream/master 
git push 

Następnie chciałbym skończyć z repozytoriów, które wygląda następująco:

Upstream: 
A-B-C-D-E-F 


Fork:  
A-B-C-D-E ----- P ------T-F' 
     \-L-M-/ \-Q-R-/ 

Istnieje kilka problemów widzę z tym jednak.

1. nie mamy popełnić F w moim repo, mam F”, który ma taką samą treść, ale inny hash. Nie mogę więc łatwo odwoływać się do zatwierdzeń między dwoma repozytoriami i wiedzieć, że mam zmianę. (Robi się jeszcze bardziej skomplikowana, gdy biorąc pod uwagę, że przed prawdopodobnie ma więcej niż jedną zmianę i ma swój własny zestaw oddziałów fabularnych, które zostały połączone)

2. Jak poruszać się do przodu i nadal robi to coraz trudniej mi znać jakie zmiany mam w moim repozytorium poza tym, co znajduje się w górze. Na przykład mogę przesłać niektóre z tych zmian wstecz, kontynuując dodawanie własnych poprawek. Po kilku powtórzeniach tego, jak każdy, kto przegląda moje repozytorium, wie, jak różni się on od wcześniejszego? (czy istnieje polecenie git, aby znaleźć te zmiany?)

3. Podobna do # 2, w jaki sposób ktoś znalazłby poprawkę we wcześniejszym etapie i sprawdzi, czy mój fork zawiera poprawkę?

Myślę, że głównym problemem jest nie ma dla mnie sposób, aby zagwarantować, że mój repozytorium jest w „Sync” z pod prąd w danym punkcie, ponieważ kod i skróty nie są takie same. Jak więc dokładnie śledzić zmiany i nie dopuszczać do szaleństwa, starając się zachować synchronizację?

Uwaga: Zastanawiałem się nad użyciem rebase, aby zachować repozytorium z mojego środowiska, ale ma to zupełnie inny zestaw problemów. Na przykład, jeśli ktokolwiek odwołuje się do mojego repozytorium poprzez submoduły, gałęzie itp., To przepisanie historii przerwie ich odniesienia. Dodatkowo, nie sądzę, że moja historia gałęzi przetrwałaby rebelizację, więc nie miałbym pełnego obrazu wszystkich utworzonych przeze mnie gałęzi operacji i powiązanej historii.

Jak radzą sobie z tym inni ludzie? Jakie są najlepsze praktyki, którymi powinienem się przyjrzeć?

---

Aktualizacja:

oparciu o informacje zwrotne od Seta, stworzyłem zbiór repozytoriów testowych, aby zobaczyć co mi chodzi i jak to działa się tak mówi.

Repozytoria są:

• upstream
• fork

Powinny one pokazać wyraźniej jak scalanie od góry wygląda, gdy istnieją lokalne zmiany, jak również.

Answer 1

Niepoprawnie w swoim założeniu. W swoim przykładzie tekstowym powiedziałeś, że chcesz uruchomić polecenie git merge. Jeśli naprawdę miałeś na myśli to, a nie, to git-merge jest najlepszą praktyką w tej sytuacji), to NIE dostaniesz F` w swojej gałęzi, dostaniesz F. Być może zdjęcie:

Po fetch ale przed scaleniem, Twoje repo wyglądać następująco:

Upstream: 
A-B-C-D-E-F [master] 


Fork: /-F     [upstream/master] 
A-B-C-D-E ----- P ------T  [master] 
     \-L-M-/ \-Q-R-/  [Other branches] 

Po scaleniu, Twój repo będzie wyglądać następująco:

Fork: /-F-------------\ [upstream/master] 
A-B-C-D-E ----- P ------T-U [master] 
     \-L-M-/ \-Q-R-/  [Other branches] 

New popełnić „U” w repo będzie seryjnej commit, podobnie jak zatwierdzenia "P" i "T".

git cherry-pick utworzy "F" jak wskazano w twoim przykładzie. Nie rób tego. git rebase może czasami obsługiwać rozgałęzienia gałęzi git rebase -p, ale nie zawsze działa. To także przepisywanie publicznej historii, co jest złym pomysłem.

Mam dokument na temat najlepszych praktyk git: Commit Often, Perfect Later, Publish Once Być może zechcesz zbadać sekcję przepływu pracy w poszukiwaniu dalszych inspiracji.