Praca z Git na wielu komputerach

Może to zabrzmieć nieco dziwnie, ale zastanawiam się nad dobrym sposobem pracy w Git z wielu komputerów połączonych ze sobą w jakiś sposób. Wygląda mi na to, że mam dwie opcje i widzę korzyści po obu stronach:

• Używaj samego git do udostępniania, każda maszyna ma swoje własne repozytorium i musisz pobierać między nimi.
  • Możesz pracować na dowolnym komputerze, nawet jeśli drugi jest offline. Myślę, że to samo w sobie jest dość duże.
• Użyj jednego repozytorium, które jest udostępniane w sieci między komputerami.
  • Nie trzeba wykonywać ściągnięć git za każdym razem, gdy zmieniasz maszyny, ponieważ Twój kod jest zawsze aktualny.
  • Nie martw się, że zapomniałeś wypchnąć kod z innego komputera, który nie jest hostem, który jest teraz poza zasięgiem, ponieważ pracowałeś na współużytkowaniu plików na tym komputerze.

Moja intuicja mówi, że ogólnie wszyscy wybierają pierwszą opcję. Ale wadą jest to, że nie zawsze możesz uzyskać dostęp do kodu z innych maszyn, a na pewno nie chcę wypychać wszystkich moich oddziałów WIP do github pod koniec każdego dnia. Nie chcę też cały czas pozostawiać włączonych komputerów, aby móc bezpośrednio z nich pobierać. Wreszcie drobną kwestią jest to, że wszystkie polecenia git, aby aktualizować wiele gałęzi, mogą być uciążliwe.

Czy istnieje trzecia rada w tej sytuacji? Może dostępne są narzędzia innych firm, które ułatwiają ten proces? Jeśli radzisz sobie z tą sytuacją regularnie, co sugerujesz?

Codziennie radzę sobie z obydwoma proponowanymi przez ciebie rozwiązaniami. Istnieją dwa kluczowe pojęcia, aby dobrze sobie z nimi radzić.

1. Użyj gałęzi tematycznych. Uważam, że historia produkcji powinna być nieskazitelna. W rezultacie spędzam dużo czasu, czyniąc productionhistorię mojego oddziału logiczną, powtarzalną i debugowalną. Jednak w przypadku korzystania z wielu komputerów czasami konieczne jest zatwierdzenie trwającej pracy. Użyj gałęzi tematu. Możesz pulli pushta gałąź z obu komputerów przy niewielkim wysiłku, a kiedy jest ona gotowa do połączenia masterlub zmiany production jej podstawy, aby stworzyć łatwiejszą do utrzymania historię.
2. Używanie jednego repozytorium udostępnionego przez sieć jest w porządku, chyba że udostępniasz go także innym użytkownikom. Używamy wspólnego repozytorium dla skryptów, twórczo nazywanego scriptsrepozytorium. Z początku wydawało się, że to dobry pomysł, ponieważ repo nie zmienia się często, ale z czasem stało się dość koszmarem. Łatwo jest wzajemnie nadpisywać swoje prace, a Ty spędzasz tyle samo czasu na kontrolowaniu ruchu lotniczego, kto wdraża repozytorium, jak Ty w nim pracujesz.

Najlepszym rozwiązaniem jest utrzymywanie lokalnego repozytorium na każdym komputerze i udostępnianie gałęzi tematycznych między nimi za pomocą pilota. Zaangażuj prace w tych oddziałach tak często, jak chcesz. Tak długo, jak chcesz, aby rebasehistoria była bardziej zrozumiała, w praktyce jest dość skuteczna.

Jeśli w ciągu dnia pracujesz nad więcej niż jedną gałęzią tematyczną, ale nie chcesz przesyłać każdej z nich osobno do pilota, git push <remote>domyślnie wypchną wszystkie pasujące gałęzie <remote>. To ustawienie domyślne zmieni się w późniejszej wersji git , ale można je zmienić, ustawiając push.defaultw pliku konfiguracyjnym lub określając dopasowanie refspec:

git push <remote> :

Jeśli nie wszystkie maszyny są cały czas włączone, nie ma srebrnej kuli: przed wyłączeniem maszyny należy wprowadzić zmiany gdzie indziej. Pcham na prywatny serwer, ale równie dobrze może to być Dropbox lub klucz USB, który nosisz wszędzie.

Tak, przesunięcie wielu gałęzi w centralne miejsce może być uciążliwe, ale nie powinno to być zbyt trudne do napisania. Używam do tego push.shskryptu, który uruchamiam za każdym razem, gdy kończę pracę na komputerze.

Doszedłem do tego z nieco innego kierunku (i używam rtęci, ale filozoficznie to samo). To nie jest mój pomysł, po prostu go używam i działa na moje osobiste rzeczy.

Utworzyłem klon moich repozytoriów w folderze SkyDrive (może to być również dropbox lub inne wybrane przez ciebie narzędzie do magicznej synchronizacji), następnie skonfigurowałem instancje na moich dwóch komputerach, aby automatycznie przesyłać do repozytorium SkyDrive po zatwierdzeniu.

Kiedy zmieniam skrzynki, to tylko kwestia ciągnięcia i aktualizacji - teoretycznie zawsze będziesz pracować w sposób liniowy, nawet jeśli jest w wielu repozytoriach.

Kluczem tutaj jest to, że repozytorium SkyDrive istnieje głównie po to, aby zapewnić sposób, że mam dostęp do mniej więcej najnowszej wersji kodu na obu moich komputerach - choć to by działało również przez więcej - i aby zapewnić dodatkowa kopia zapasowa. Wszystko, co jest „zrobione”, jest wypychane do Kiln (gdybym używał git i poprawnie rozumiem sposób, w jaki gra się gra, to byłby moment, w którym dokonałbym rebase).

To, czego tak naprawdę nie chciałbym zrobić, to uruchomić folder współdzielony ... jeśli używasz DVCS, możesz równie dobrze skorzystać z tej korzyści.

Pierwsza z dwóch alternatyw to odpowiedź. Sugeruje to „D” w „DVCS”. Każdy użytkownik ma własną lokalną instancję repozytorium, a repozytoria rozmawiają między sobą w zarządzalny sposób.

Możesz zrobić drugą alternatywę, ale problem polega na tym, że istnieje tylko jeden katalog roboczy repozytorium. Więc drzewo pracy może być jednocześnie tylko w jednym stanie - Joe nie pracuje nad jedną gałęzią, a Jane pracuje nad inną. Programiści mogą więc wzajemnie nadpisywać zmiany, nawzajem nawzajem sobie nawzajem pracować. Dlaczego to wcale nie ma kontroli wersji!

Nazywa się to środkiem pośrednim, posiadaniem czystego repozytorium na dysku sieciowym i umożliwianiem poszczególnym użytkownikom wpisywania się i wylogowywania z niego. To oddziela twoją pracę WIP (która tak, trzymasz lokalnie) od pracy, którą publikujesz do repozytorium. To nie jest „oszczędzanie” - to „publikowanie”. Praca, którą chcesz, aby Twoi rówieśnicy mogli zobaczyć i wykorzystać.