Próbuję znaleźć najlepszy przepływ pracy do pracy z widelcem istniejącego projektu opensource w Github. Chcę wziąć istniejący projekt i wprowadzić w nim istotne zmiany, w tym przypadku przenieść go na system Android i dodać specyficzną funkcjonalność tylko na Androida. Chciałbym spełnić następujące warunki:Najlepszy przepływ pracy podczas rozwidlania i zmiany nazwy projektu GitHub
- Będą mogli pobrać zmiany z publicznego repozytorium na nowy port Android, gdy oryginalny kod zostanie zaktualizowany.
- Potrafię sumbitować zmiany (za pomocą żądań ściągnięcia) do projektu oryginalnego, gdy naprawię błędy, które nie dotyczą tylko portu Android.
- Masz oddzielną, przemianowaną wersję projektu, aby było jasne, że jest to port Android. Spojrzałem na zmianę nazwy widelca i Github dał mi ogromne ostrzeżenia o tym.
Moje pierwsze myśli są Chciałbym widelec oryginalny projekt następnie widelec i zmienić mój widelec dać mi następujące repo:
original-author/projectA
nicstrong/projectA
nicstrong/projectA-android
Pozwoliłoby mi pracować na moim lokalnym repo local/projectA- Android push zmienia się na nicstrong/projectA-android. Następnie, aby zaktualizować z oryginalnego projektu, mogłem ponownie ustawić nicstrong/projectA na najnowszy z original-author/projectA, a następnie pobrać/scalić z nicstrong/projectA do local/projectA-android.
Moje pytania są następujące:
- Jestem zupełnie nowy w całej Git rzeczy. Czy wydaje się to dobrym podejściem ? Czy istnieje lepszy przepływ pracy do obsługi tego scenerio?
- Jak obsługiwać przesuwanie z projektu z powrotem do nicstrong/projectA, aby móc ustawić żądanie ściągnięcia oryginalnego projektu?
Aby utworzyć wiele potrzebnych wideł, skorzystałem z techniki opisanej w tym poście: http://adrianshort.org/2011/11/08/create-multiple-forks-of-a-github-repo/ – dbasch
@dbasch prawda, ale nie będzie to prawdziwe widelec, ponieważ nie będzie żadnego żądania ściągnięcia z drugiego "widelca" z powrotem do pierwotnego repo. – VonC
Będę używał repozytorium projectA do wysyłania żądań do oryginalnego repo. Zmiany w projectA-android/backport zostaną ręcznie połączone z projectA. Czy to dobra strategia? – dbasch