Jakie są koncepcyjne różnice między użyciem podmodułu git i poddrzewa?
Jakie są typowe scenariusze dla każdego z nich?
Jakie są koncepcyjne różnice między użyciem podmodułu git i poddrzewa?
Jakie są typowe scenariusze dla każdego z nich?
Odpowiedzi:
Co jeśli chcę, aby linki zawsze wskazywały na HEAD zewnętrznego repo?
Możesz utworzyć submoduł, aby śledził HEAD oddziału zdalnego repozytorium submodułu, za pomocą:
o git submodule add -b <branch> <repository> [<path>]
. (aby określić gałąź do naśladowania)
o, git submodule update --remote
która <repository>/<branch>
domyślnie zaktualizuje zawartość submodułu do najnowszej wersji HEAD origin/master
. Twój główny projekt nadal będzie śledził skróty HEAD submodułu, nawet jeśli --remote
jest używany.
add -b
a --remote
później poleceń aktualizacji, zgodnie z dokumentacją aktualizacji submodułu . W takim razie, czy -b
naprawdę jest nadal potrzebny do podążania za GŁOWĄ mistrza?
-b
służy do generowania odpowiednich metadanych .gitmodule dla submodułu (jest to odpowiednik a git config -f .gitmodules submodule.<path>.branch <branch>
).
--remote
- --remote
działa również, jeśli -b
nie był używany add
. W obu przypadkach aktualizacja spowoduje zatwierdzenie w repozytorium nadrzędnym zawierającym podmoduł, więc linki tak naprawdę „nie zawsze wskazują HEAD” w bardzo automatyczny sposób… albo go nie otrzymałem, albo to roszczenie lepiej być usunięte z oryginalnej odpowiedzi (?)
Różnica koncepcyjna to:
W podmodułach git zwykle chcesz rozdzielić duże repozytorium na mniejsze. Sposób odwoływania się do podmodułu jest podobny do stylu rajskiego - odwołujesz się do pojedynczego zatwierdzenia z drugiego repozytorium (podmodułu). Jeśli potrzebujesz zmiany w podmodule, musisz dokonać zatwierdzenia / wypchnięcia w podmodule, następnie odwołaj się do nowego zatwierdzenia w głównym repozytorium, a następnie zatwierdz / zmień zmienione odwołanie do głównego repozytorium. W ten sposób musisz mieć dostęp do obu repozytoriów dla pełnej kompilacji.
Z poddrzewem git integrujesz kolejne repozytorium w swoim, w tym jego historię. Więc po jego integracji rozmiar twojego repozytorium jest prawdopodobnie większy (więc nie jest to strategia zmniejszania repozytoriów). Po integracji nie ma połączenia z drugim repozytorium i nie potrzebujesz do niego dostępu, chyba że chcesz uzyskać aktualizację. Tak więc ta strategia dotyczy bardziej ponownego wykorzystania kodu i historii - ja osobiście jej nie używam.
git subtree
tobą nadal możesz naciskać - jeśli chcesz - prawda?
podmoduł
wypychający główne repozytorium do pilota nie wypycha plików podmodułu
sub-drzewo
wypychające główne repozytorium do zdalnego wypycha pliki sub-drzewa
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags production refs/heads/master:refs/heads/master