Jak udostępnić oddział funkcji git (lub tematu) wielu programistom

Question

Podążam za przepływem pracy opisanym jako here, ponieważ znalazłem wiele odniesień wskazujących tę stronę jako dobry przepływ pracy. Jak wspomniano w artykule, gałęzie "funkcji" są współdzielone między programistami, ale nie przechodzą do centralnego repozytorium.

Załóżmy, że programista "A" uruchamia nowy oddział funkcji z git checkout -b newfeature develop. Teraz powiedzmy, że deweloper "B" musi również pracować nad tą funkcją. To jest mój problem.

Co zrobiłem:

1. deweloper "B" dodaje maszynę deweloperowi jako zdalnego
2. deweloperskim "B" biegnie git branch remoteA/newfeature
3. deweloper "B" działa w tej branży, popełnić swoją pracę i przekazuje zmiany z powrotem do remoteA.

Krok 3 nie działa, właśnie teraz. Dostaję komunikat:

remote: error: By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent with what you pushed, and will require 'git reset --hard' to match the work tree to HEAD.

remote: error: You can set 'receive.denyCurrentBranch' configuration variable to 'ignore' or 'warn' in the remote repository to allow pushing into its current branch; however, this is not recommended unless you arranged to update its work tree to match what you pushed in some other way.

remote: error: To squelch this message and still keep the default behaviour, set receive.denyCurrentBranch' configuration variable to 'refuse'.

już ustawiony sharedRepository = true, ale to nie pomogło.

mam 2 pytania:

1. co jest poprawny sposób udostępniania funkcji między gałęzie deweloperów?
2. Jak mogę cofnąć zmiany w repozytorium dewelopera B na oryginalną wersję dewelopera A?

Answer 1

Możesz przejść do zwykłego repozytorium. To, czego nie możesz zrobić, to popchnąć do repozytorium, które ma oddział, który chcesz wypisać. Powód tego powinien mieć sens. Zmiana plików, nad którymi prawdopodobnie pracuje ktoś inny, byłaby niepoprawna.

Zazwyczaj będziesz chciał przejść do trybu nadrzędnego lub do innej wspólnej, współużytkowanej gałęzi. Aby uniknąć tego konfliktu, właściciel zdalnego repozytorium typu non-bare powinien pracować w lokalnym oddziale lub co najmniej w innym oddziale. Następnie możesz przejść do udostępnionej gałęzi.

Aby użyć przykładu:

1. deweloper "B" dodaje maszynę deweloperowi jako zdalnego
2. deweloperskim "B" działa git branch remoteA/newfeature
   1. deweloper "A" działa na lokalnym oddziale. git checkout -b work-newfeature
3. programista "B" działa w tej branży, zatwierdza jego pracę i przesyła zmiany z powrotem do remoteA.
   1. Twórca „A” rebases dostać nową pracę: git rebase newfeature

Answer 2

Najprostszym sposobem na udostępnienie gałęzi obiektów jest po prostu przekazanie ich do centralnego repozytorium, aby każdy mógł je pobrać. W ten sposób możesz po prostu użyć infrastruktury, którą już posiadasz do swojego głównego repozytorium i możesz łatwo udostępniać kod.

Gdy gałąź funkcji na pilocie nie jest już potrzebny można po prostu usunąć go wykonując

git push <server> :branch 

radzę przeciwko dzielenia bezpośrednio między komputerami deweloperskich jak to jest podatne na problemy jak użytkownicy będąc na różne sieci (niepołączone ze sobą).

Jeśli to możliwe, możesz także użyć modelu GitHub, w którym na serwerze znajduje się jedno centralne repozytorium (główne repozytorium główne). A poza tym głównym repozytorium każdy programista ma "widelec" tego repozytorium, w którym ma pełny dostęp do zatwierdzania i może przesuwać gałęzie do swoich potrzeb.

W tym przypadku możesz dodać swoje widełki współpracowników jako piloty zdalnego sterowania do swojego repozytorium, jednocześnie zachowując łatwy dostęp do jednego scentralizowanego serwera (oszczędzając Ci kłopotów z ustawieniem kluczy SSH na każdym komputerze itd. Itd.).

opis tego modelu GitHub można znaleźć tutaj: http://www.eqqon.com/index.php/Collaborative_Github_Workflow

Aktualizacja: Jako commentor podkreślić, że jest to dobry link, aby zacząć korzystać z workflow scentralizowane-funkcja-gałęzi: http://nvie.com/posts/a-successful-git-branching-model/

Update2: aby rozwinąć na drugie pytanie:

Co próbujesz zrobić, to nacisnąć na zakaz nagiej repozytorium innego dewelopera. Git został wprowadzony w poprzedniej wersji (jak sądzę 1.6) koncepcji repozytorium - to repozytorium, które ma stan sprawdzony, ale zawiera tylko bazę danych, która zwykle przechodzi w numer .git.

Powodem tej zmiany było to, że za każdym razem, gdy naciskasz na repozytorium współpracowników (który aktualnie pracuje nad czymś) - manipulujesz repozytorium tuż pod nosem. Sprawdza więc wersję featureA-1 ... zaczyna pracę. Następnie naciskasz featureA-2 na jego repozytorium, a kiedy chce się zaangażować, wpada w kłopoty, ponieważ oddział, w którym się znajdował, awansował o jedno zatwierdzenie, którego nie widział podczas rozwój.

Ponieważ jest to dość uciążliwy - Większość ludzi przyjęły pojęcie lokalnych repozytoriów git (te, w których aktywnie działają na) należy prywatny natomiast masz publiczny git-repo (the widelec) gdzie otrzymujesz i udostępniasz zmiany. W ten sposób nigdy nie zostaniesz przerwany przez nikogo innego podczas swojej pracy (to i tak jest cały pomysł zdecentralizowanego modelu) i może on zawierać tylko te zmiany, które chcesz. (Nikt nie może wcisnąć czegoś na twoją obecną pracę).