Jest nas dwóch nad czymś. Używamy tej struktury gałęzi
Oboje pracujemy nad oddzielnymi gałęziami (dev-A, B) i ilekroć skończymy - promujemy nasze zmiany do opanowania.
Wadą tego jest to, że nie możemy uzyskać zmian wprowadzanych przez innych programistów. Wszystko istnieje w drzewie głównym - ale nie możemy uzyskać najnowszych aktualizacji innych programistów.
Czy istnieje sposób, aby to rozwiązać, czy też powinniśmy zmienić strukturę naszych oddziałów (według funkcji?)?
Odpowiedzi:
Widziałem gałęzie programistów używane w dwóch głównych scenariuszach:
Społeczność typu open source, w której gałęzie te są faktycznie widelcami repozytoriów, dzięki czemu opiekunowie projektów mogą zablokować dostęp do głównego repozytorium i wymagać integracji poprzez żądania ściągania. To sprawia, że życie jest trudniejsze dla współpracowników, ale o wiele łatwiejsze dla opiekunów, co oczywiście jest właśnie o to chodzi i jest to bardzo udany model w GitHub.
Zespoły i organizacje, które nie mają ciągłej integracji i historii niestabilności we wdrożeniach lub, co gorsza, niestabilności w swoich kompilacjach. Zespoły te zazwyczaj starają się wykorzystywać gałęzie programistów jako sposób ochrony stabilności głównej linii, a rezultatem jest - zazwyczaj - długi i bardzo bolesny okres łączenia przed wydaniem, a następnie jeszcze dłuższy i bardziej bolesny okres stabilizacji, który czasem nastąpi dopiero po wydaniu.
Nie chcę, aby było to rażące pytanie, dlaczego potrzebujesz CI, ale z twojego pytania jasno wynika, że wiesz, że nie integrujesz swoich zmian wystarczająco często, więc IMO nie ma sensu tańczyć wokół problemu.
O ile nie pracujesz w rozproszonym geograficznie zespole z potrzebą „blokowania” zmian od zewnętrznych programistów, model rozgałęzień na programistę naprawdę nie ma większego sensu. Szczególnie nie ma to sensu w przypadku git, ponieważ każdy programista już technicznie ma swoje własne repozytorium. Większość organizacji powinna się integrować bardzo często - jak kilka razy dziennie.
Obecnie należę do grupy około 35 autorów podzielonych na 4 oddzielne zespoły, większość ludzi zamelduje się co najmniej 2-3 razy dziennie, niektóre osoby 10-15 razy; rzadko zdarza się, że kompilacje są zepsute, a niezwykle rzadko są one łamane przez ponad kilka minut. Git obsługuje scalanie tak łatwo, że zdalne gałęzie programistów są po prostu niepotrzebnym narzutem. Wystarczy pobrać, scalić lokalnie i uruchomić testy zatwierdzania przed wypchnięciem - to proste.
Jeśli absolutnie musisz odroczyć integrację w celu ochrony stabilności gałęzi master, typowym, sprawdzonym modelem jest użycie gałęzi niestabilnej - czasami nazywanej gałąź rozwoju , jak opisano w udanym modelu rozgałęziania Git . Jeśli programiści nie mogą z powodzeniem połączyć się z tą gałęzią (która musi tylko budować , a nie działać bezbłędnie) przynajmniej raz dziennie, to masz problem z jakością / dyscypliną, a nie problem z kontrolą wersji; ukrywanie go za pomocą niezintegrowanych gałęzi programistów tylko odsuwa problem, a przez to powoduje, że ewentualne połączenia są o wiele bardziej bolesne i niestabilne, niż powinny być.
Gałęzie obiektów nie są najgorsze, ale bardzo niewiele projektów IMO jest na tyle duże, że można je uzasadnić; jeśli twój projekt jest bardzo duży (tj. mnóstwo funkcji jednocześnie opracowywanych), zobaczysz lepsze wyniki z podziału na osobne komponenty autonomiczne niż z powodu problemu z kontrolą źródła.
Można zignorować tę radę, jeśli chcesz, i robić wiele zespołów, ale jeden z powodów, model rozgałęzienia połączonych powyżej jest tak popularne i skuteczne jest to, że jest ono przeznaczone do pracy z ciągłej integracji, a nie przeciwko nim.
Jeśli pracujesz w oddziale roboczym:
git commit -am "Committing changes before merge"
git merge master
możesz także łączyć się z innymi gałęziami programistów
git checkout dev-A
git merge dev-B
Spowoduje to scalenie zmian w systemie głównym w gałęzi programistycznej.
git merge masterpodczas sprawdzania gałęzi funkcji szukałem tego. Dzięki
Jeśli dev-A i dev-B są różnymi gałęziami dla różnych projektów, to odpowiedź @scaryrawr byłaby najlepsza.
Ale jeśli dev-A i dev-B to w rzeczywistości dokładnie ten sam kod (ten sam projekt), to alternatywą byłoby, aby obie działały na jednej z gałęzi. Na przykład tworzysz odgałęzienie główne o nazwie „devWork”. Oboje sprawdzacie devWork, pracujemy nad tym, zatwierdzacie i wypychacie zmiany. Wprowadzone zmiany nie byłyby wprowadzone w Master, ale w devWork, wtedy inni użytkownicy oddziału muszą po prostu wykonać PULL lokalnie, aby uzyskać wypchnięte zmiany.
Następnie możesz zastosować standardowe metody, aby wykonać pracę nad devWork z powrotem do Master itp.