Problemy z modułem roboczym pod Gintem

Question

Ostatnio mamy wiele problemów z naszymi repozytoriami Git. Jesteśmy użytkownikami submodułów git dla 4 wspólnych repozytoriów pomiędzy naszymi aplikacjami.

Na przykład repozytorium "witryna" ma w sumie 3 submoduły.

[submodule "vendor/api"] 
    path = vendor/api 
    url = git@your.cool.domain.com:api 
[submodule "vendor/auth"] 
    path = vendor/auth 
    url = git@your.cool.domain.com:auth 
[submodule "vendor/tools"] 
    path = vendor/tools 
    url = git@your.cool.domain.com:tools 

Sprawdziliśmy poprawnie nasze główne repozytorium "strona internetowa". Teraz jeden z moich współpracowników zrobić push, potem git pull; git status:

# On branch master 
# Changed but not updated: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
# modified: vendor/api (new commits) 
# modified: vendor/auth (new commits) 
# modified: vendor/tools (new commits) 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

mcfly@future:~/projects/website$ git diff 

diff --git a/vendor/api b/vendor/api 
index 41795fc..b582d80 160000 
--- a/vendor/api 
+++ b/vendor/api 
@@ -1 +1 @@ 
-Subproject commit 41795fc4dde464d633f4c0f01eebb6ab1ad55582 
+Subproject commit b582d802419b0ee7bc3959e7623fec0b94680269 
diff --git a/vendor/auth b/vendor/auth 
index a00369b..4599a71 160000 
--- a/vendor/auth 
+++ b/vendor/auth 
@@ -1 +1 @@ 
-Subproject commit a00369bf29f14c761ce71f7b95aa1e9c107fb2ed 
+Subproject commit 4599a7179c9b7ca4afa610a15ffa4a8fc6ebf911 
diff --git a/vendor/tools b/vendor/tools 
index f966744..c678cf6 160000 
--- a/vendor/tools 
+++ b/vendor/tools 
@@ -1 +1 @@ 
-Subproject commit f966744359510656b492ae3091288664cdb1410b 
+Subproject commit c678cf6f599fc450e312f0459ffe74e593f5890f 

jaki jest problem z tym git diff? Problem polega na tym, że nowe zatwierdzenia dla każdego modułu podrzędnego są starsze niż te, które zostaną nadpisane. Nie tego chcemy, ponieważ w repozytorium poprawnie wskazuje 41795fc4dde464d633f4c0f01eebb6ab1ad55582, a00369bf29f14c761ce71f7b95aa1e9c107fb2ed i f966744359510656b492ae3091288664cdb1410b, a jeśli dodamy te modyfikacje do naszego następnego zatwierdzenia, prawdopodobnie zlikwidujemy te rzeczy. Nie wiem, dlaczego otrzymała najstarszą wersję, a nie najnowszą.

starałem się rozwiązać ten sam, ale bez powodzenia:

mcfly@future:~/projects/website$ git pull; git submodule foreach git pull 

robi ostatnie polecenie to nie jest prawidłowe, ponieważ prawdopodobnie będziemy aktualizować wskaźnik na „stronie”, aby najnowszy każdym modułem i my nie chcę tego. Chcemy zachować poprawną wersję, która znajduje się w repozytorium.

Jedną z rzeczy, które mam wytłumaczyć, że zazwyczaj pracują wewnątrz tego submodułów, na przykład:

mcfly@future:~/projects/website$ cd vendor/api 
mcfly@future:~/projects/website/vendor/api$ git checkout master 
mcfly@future:~/projects/website/vendor/api$ echo "lorem ipsum" >> example.file 
mcfly@future:~/projects/website/vendor/api$ git add example.file; git push 

Kiedy robimy git submodule update do „mistrz” oddział traci na każdym modułem.

Wreszcie, jaki jest poprawny sposób robienia push, pull i pracy z submodułami i nie mając wszystkich tych problemów?

góry dziękuję

Answer 1

Spójrz na git-scm documention i przekazać go wokół swojej drużynie. Zjawisko, które widzisz, jest dokładnie opisane w sekcji "Cloning a Project with Submodules".

Po pierwsze, obserwowany stan początkowy, w którym git diff pokazuje nieoczekiwanie przeciwne wyniki dla tych skrótów zatwierdzających, wskazuje, że scalono aktualizację modułu podrzędnego w repozytorium nadrzędnym, ale lokalnie nie uruchomiono git submodule update. Musisz uruchomić git submodule update za każdym razem, gdy usuniesz zmianę podmodułu w głównym projekcie. Czemu? Wskaźnik submodułu, tj. To, co zdaniem repozytorium macierzystego jest stanem vendor/auth, nie jest w rzeczywistości zatwierdzeniem HEAD modułu repozytoryjnego vendor/auth. To trochę zagmatwane, dopóki nie zrozumiesz, jak git śledzi stany modułów. Ponownie, git-scm documentation jest wart odczytu.

Po drugie, git submodule update porzuca gałąź master na module podległym według projektu. Zapoznaj się z sekcją dotyczącą tych dokumentów. Strona człowiek, jak to często prawdziwe z git, mówi nam, co musimy wiedzieć:

update 
    Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. This will 
    make the submodules HEAD be detached unless --rebase or --merge is specified or the key submodule.$name.update is set to rebase, merge or none. none 
    can be overridden by specifying --checkout. 

Ty oddanie submodules w „” wolnostojący HEAD stanie za każdym razem wydawać git submodule update bez argumentu.

Jak więc pracować z submodułami bez tych problemów? Najpierw zapytaj siebie i swój zespół: czy naprawdę ich potrzebujemy? Submodules są w niektórych przypadkach potężną i użyteczną funkcją, ale zostały zaprojektowane dla bibliotek innych firm, niż aktywne projekty podzielone na podkatalogi. Z pewnością można z nich korzystać w ten sposób, ale narzut związany z zarządzaniem może gwałtownie przekroczyć wszelkie korzyści, jakie otrzymujesz. O ile twoje repozytorium nie jest dość duże, lub twoje submoduły są całkowicie modułowe, warto zadać pytanie: "Would we be better off with a single repository?" Nawet jeśli odpowiedź brzmi "nie", sprawdź, subtree merging,, które może być bardziej skuteczne w przypadku użycia.

Jeśli nadal chcesz korzystać z submodules, sprawdź the docs umieszczonego powyżej, jak również wielu questions i answers na SO i innych stron o workflow modułem. Powinny one pomóc w osiągnięciu dokładniejszego procesu.