Używanie git jako centralnego repozytorium

Skonfigurowałem git na własny użytek - dzięki czemu mogę uzyskać dostęp do projektu z „dowolnego miejsca” i zachować bezpieczeństwo wersji, jeśli akurat pracuję nad częścią X tutaj i częścią Y tutaj i mogę połączyć, jeśli to konieczne.

Jednak tylko jedna z moich maszyn programistycznych ma statyczny adres IP. Mój mózg utknął w trybie CVS, więc próbowałem skonfigurować git, aby ta maszyna była „centralnym” serwerem, z którego korzystają wszyscy inni.

Ten rodzaj działa. Mam kilka maszyn AC, które robią git-pull od „master” M. Mają git pushy, aby wysłać dane z powrotem.

Problem pojawia się, gdy robię programowanie na masterie. Po pierwsze, nie mogę wymyślić, jak uzyskać centralne repozytorium, aby zapewnić najnowszą wersję bez robienia tego

git reset --hard HEAD

co wydaje się nieco przesadne. A jeśli wykonam programowanie na komputerze centralnym przed zresetowaniem, nie jestem pewien, jak połączyć go ze zmianami, które zostały już wprowadzone.

Coś w moim modelu mentalnym jest dalekie. Wsparcie?

Chcesz, aby twoje centralne repozytorium było puste. Powiedzmy, że maszyna, na której żyje, nazywa się static:

$ ssh static git init --bare /git/myproject.git

To nagie repozytorium jest centralnym punktem spotkania: służy do przepychania się i wyciągania z niego, a nie rozwoju.

Wykonaj swój rozwój na klonach centralnego repozytorium:

$ cd ~/src
$ git clone static:/git/myproject.git

Nawet jeśli jesteś włączony static, pracuj w klonie:

$ git clone /git/myproject.git

Chociaż tylko ty pracujesz nad tym repozytorium, przyzwyczaj się do pracy nad tym, co dokumentacja git nazywa gałęziami tematycznymi . Bezpośrednią korzyścią z tego jest to, że utrzymuje czysty wzorzec , to znaczy, że zawsze możesz wyciągnąć z centralnego oddziału głównego do wzorca bieżącego lokalnego repozytorium bez scalania.

Na przykład:

$ git checkout -b fix-bug-in-foo
$ hack
$ git add file.c file.h
$ git commit -m "Fix ..."

To może nie wydawać się wielkim problemem, ale daje ci swobodę pozostawienia projektu przedstawionego na tej gałęzi w stanie częściowo ugotowanym, lub jeśli twój fajny pomysł okaże się flopem, możesz łatwo wyrzucić tę gałąź bez niszcząc wszystko inne w twoim projekcie, co już działa na innych gałęziach. Nieskończone darmowe mulligany!

Może tej nocy wrócisz do domu i dodasz nową funkcję. Następnego dnia rano ty

$ git checkout master
$ git pull

zaktualizować lokalnego wzorca, aby odzwierciedlić zawartość centralnego repozytorium.

Ale teraz powiedz, że naprawiłeś błąd foo i jesteś gotowy, aby włączyć go do głównej gałęzi. Najpierw chcesz zintegrować go ze zmianami z ostatniej nocy:

$ git checkout fix-bug-in-foo
$ git rebase master

To rebasepolecenie sprawia, że ​​twoje repozytorium wygląda tak, jakbyś naprawił błąd foo nad nową funkcją zeszłej nocy. (Jest to trochę podobne svn update, ale bardziej elastyczne i wydajne).

Teraz, aby dostać się do swojego centralnego mistrza:

$ git checkout master
$ git merge fix-bug-in-foo
$ git push origin master

Traktowaliśmy mistrza jako coś wyjątkowego, ale to tylko konwencjonalne. Możesz staticrównie łatwo udostępniać pracę w różnych gałęziach różnych repozytoriów za pośrednictwem repozytorium git .

Jeśli masz centralny serwer z centralnym repozytorium git, to repozytorium powinno być barerepozytorium. Nagie repozytoria nie zawierają działających kopii plików. W związku z tym, jeśli pracujesz na tym komputerze centralnym, nie pracujesz bezpośrednio z centralnym repozytorium, ale z lokalnym klonem.

Ta odpowiedź jest podobna do odpowiedzi gbacon , ale zakłada, że ​​masz już lokalną konfigurację repozytorium i chcesz utworzyć zdalny master, który będzie traktowany jako repozytorium centralne. Po prostu dodaje szczegóły z innego podejścia.

Używam git do przechowywania plików konfiguracyjnych kropek. Naciskam i wyciągam z tego, co uważam za „centralne repo”. Wygodnie zresetować wszystkie moje pliki kropek na wielu komputerach.

$ ssh example.com
$ mkdir dotconf.git && cd dotconf.git
$ git init --bare
$ exit

To stworzyło puste nagie repo na stronie repo.

Teraz, jeśli mam już istniejące repozytorium lokalnie, mogę przekazać je do zdalnej witryny.

$ cd ~/src/dotconf

chdir do katalogu lokalnego.

$ git remote add origin ssh://example.com/~/dotconf.git

Dodaj zdalne repozytorium jako źródło, więc push / pull będzie działać na podstawie tego repozytorium.

$ git push origin master

Popchnij mojego mistrza do źródła (jak poprzednio oznaczone za pomocą pilota git). Teraz to zdalne repo jest traktowane jako moje „repozytorium centralne”. Wszystkie moje polecenia git push / pull będą oddziaływać z początkiem.

Jeśli przejdę do innego hosta, mogę łatwo wyciągnąć za pośrednictwem klonu repozytorium do nowej lokalizacji.

$ git clone ssh://example.com/~/dotconf.git

Jeśli chcę wykonać programowanie na zdalnym serwerze, najpierw klonuję, a następnie wypycham / wyciągam z powrotem do samego repozytorium.

$ cd ~/src
$ git clone ~/dotconf.git
$ cd ~/src/dotconf
  * do coding *
$ git push
  * check in from another location *
$ git pull

Prawdopodobnie będziesz musiał to ustawić, git config --add branch.master.remote originaby git pullnie narzekać, że nie jesteś wystarczająco precyzyjny. Inną alternatywą jest ustawienie gałęzi master --trackna zdalne pochodzenie. Przydatne, jeśli masz wiele oddziałów.

Właśnie badałem dzisiaj ten sam problem. Ten post na blogu zawiera wiele dyskusji na ten temat, ale większość uważa, że ​​to, co powiedział Manni. Spójrz na komentarz do posta autorstwa Davida Frencha, aby zobaczyć inne możliwości, w tym co zrobić, jeśli skończysz przypadkiem popychając do repozytorium, które ma nieprzypisaną pracę w indeksie lub drzewie roboczym. „git reset –soft HEAD ^” wycofuje wypchniętą zmianę bez zakłócania pracy.