Git - pchanie zdalnego oddziału do dużego projektu jest bardzo powolne

Question

Po prostu ruszamy się do pracy. Mamy dość duży projekt z dość dużymi zasobami w ramach kontroli wersji (~ 500MB).

Dzisiaj staraliśmy się przekazać oddział na zdalny serwer i byliśmy zaskoczeni, że git wydawał się próbować przesłać cały projekt. Spodziewałbym się, że git będzie wysyłać tylko delta dla plików tekstowych 4-5, które miały zmiany (tak jak w przypadku normalnego pushowania do master). Czy to nie działa jak odległe oddziały? Użyliśmy git push origin some_branch_name, czy istnieje lepsze polecenie do użycia w tym przypadku? Czy nie powinniśmy przechowywać dużych zasobów w git? Jeśli nie, jak ludzie zwykle radzą sobie z tym scenariuszem? Czy istnieje lepszy sposób, aby jeden programista mógł dzielić pracę w toku z innym programistą bez zatwierdzania zmian w oddziale głównym? W tej chwili patrzymy na około 15 minut, aby wypchnąć zdalną gałąź, co naprawdę nie działa. Co robimy źle?

Answer 1

Czy możesz zaktualizować swój wpis za pomocą kilku rzeczy?

Aby uzyskać lepsze wyobrażenie o tym, jak projekt wygląda, proszę umieszczać wokół górnej 10+ wpisów z następujących czynności:

git log --decorate=short --oneline --graph --all 

Jeśli duże zasoby są binarne, to nie one nie powinny być przechowywane w git . Jeśli te zasoby binarne są aktualizowane, to git musi wewnętrznie wykonać ich kompletny duplikat, którego algorytm kompresji nie lubi, i wysłać go na serwer. Co do tego, co z nimi zrobić, zależy to od scenariusza. Musisz opracować.

Wygląda na to, że masz kilku programistów pracujących na tym samym pilocie. Czy to jest poprawne? Jeśli tak, żaden programista nie powinien zgłaszać się bezpośrednio na numer master (nigdy nie powinno się to zdarzać). Każdy programista może mieć swój własny nazwany oddział. Na przykład programista John może utworzyć wszystkie swoje gałęzie pod numerem john/<branch_name>. Pomoże to utrzymać porządek w pracy.

Również git nie działa z deltami. Przechowuje plik w całości za każdym razem, gdy zostanie zmieniony. Może się to wydawać nieefektywne, ale stosowana kompresja ogranicza rozmiar do minimum. Pomaga to w kasowaniu i historii logów skanowania znacznie szybciej. Przeczytaj pierwszą część Git Basics, aby uzyskać wizualizację.