Błąd wypychania Git „[zdalne odrzucenie] master -> master (oddział jest obecnie wyewidencjonowany)”

Wczoraj zadałem pytanie, jak sklonować repozytorium Git z jednego z moich komputerów na inny. Jak mogę „sklonować” z innego komputera? .

Teraz mogę pomyślnie sklonować repozytorium Git z mojego źródła (192.168.1.2) do mojego miejsca docelowego (192.168.1.1).

Ale kiedy dokonałem edycji pliku a git commit -a -m "test"i a git push, pojawia się ten błąd w miejscu docelowym (192.168.1.1):

git push                                                
hap@192.168.1.2's password: 
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error: 
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error: 
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working'

Używam dwóch różnych wersji Git (1.7 na pilocie i 1.5 na komputerze lokalnym). Czy to możliwy powód?

Możesz po prostu przekonwertować swoje zdalne repozytorium na zwykłe repozytorium (w pustym repozytorium nie ma kopii roboczej - folder zawiera tylko rzeczywiste dane repozytorium).

Wykonaj następujące polecenie w folderze zdalnego repozytorium:

git config --bool core.bare true

Następnie usuń wszystkie pliki oprócz .gittego folderu. A wtedy będziesz mógł wykonać git pushzdalne repozytorium bez żadnych błędów.

Właśnie miałem ten sam błąd, kiedy zacząłem uczyć się Git . Niektóre inne odpowiedzi najwyraźniej nie są dla kogoś nowego w Git!

(Zamierzam użyć nietechnicznych terminów, aby przekazać pomysł.) W każdym razie dzieje się tak, że masz dwa repozytoria, jeden to oryginał, który pierwszy stworzyłeś, a drugi to dzieło, które właśnie stworzyłeś.

W tej chwili jesteś w swoim repozytorium pracy i korzystasz z gałęzi „master”. Ale zdarza się, że jesteś „zalogowany” w swoim oryginalnym repozytorium do tej samej gałęzi „master”. Teraz, gdy jesteś „zalogowany” w oryginale, Git obawia się, że możesz zepsuć się, ponieważ możesz pracować nad oryginałem i popsuć wszystko. Musisz więc wrócić do oryginalnego repozytorium i zrobić „git checkout someotherbranch”, a teraz możesz bez problemu naciskać.

Mam nadzieję, że to pomoże.

Komunikat o błędzie opisuje, co się stało. Bardziej nowoczesne wersje Git odmawiają aktualizacji gałęzi za pomocą wypychania, jeśli gałąź ta jest wyewidencjonowana.

Najłatwiejszym sposobem pracy między dwoma nie nagimi repozytoriami jest albo

1. zawsze aktualizuj repozytoria poprzez ściągnięcie (lub pobranie i scalenie) lub, jeśli musisz,

2. wypychając do oddzielnej gałęzi (gałąź importu), a następnie łącząc tę ​​gałąź z gałęzią główną na komputerze zdalnym.

Powodem tego ograniczenia jest to, że operacja wypychania działa tylko na zdalnym repozytorium Git, nie ma dostępu do indeksu i drzewa roboczego. Tak więc, jeśli jest to dozwolone, wypychanie wypisanej gałęzi zmieniłoby HEAD niezgodność z drzewem indeksu i drzewa roboczego w zdalnym repozytorium.

Ułatwi to przypadkowe zatwierdzenie zmiany, która cofnie wszystkie wprowadzone zmiany, a także bardzo utrudni rozróżnienie między lokalnymi zmianami, które nie zostały zatwierdzone HEAD, a różnicami między nowym , indeksem i drzewem roboczym, które zostały spowodowane przez ruch pchający HEAD.

Podsumowanie

Nie można wypychać do tej sprawdzonej gałęzi repozytorium, ponieważ bałaganiłby użytkownika tego repozytorium w sposób, który najprawdopodobniej zakończy się utratą danych i historii . Ale możesz wypychać do dowolnej innej gałęzi tego samego repozytorium.

Ponieważ nagie repozytoria nigdy nie mają wypisanej żadnej gałęzi, zawsze możesz wypchnąć do dowolnej gałęzi nagiego repozytorium.

Istnieje wiele rozwiązań w zależności od potrzeb.

Rozwiązanie 1: Użyj nagiego repozytorium

Zgodnie z sugestią, jeśli na jednym komputerze nie potrzebujesz katalogu roboczego, możesz przejść do czystego repozytorium. Aby uniknąć bałaganu w repozytorium, możesz go po prostu sklonować:

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

Teraz możesz przesłać wszystko, co chcesz, na ten sam adres jak poprzednio.

Rozwiązanie 2: Przekaż do oddziału, który nie został wyewidencjonowany

Ale jeśli musisz sprawdzić kod na pilocie <remote>, możesz użyć specjalnej gałęzi do wypychania. Powiedzmy, że w lokalnym repozytorium zadzwoniłeś do swojego pilota origini jesteś na oddziale głównym. Więc możesz to zrobić

machine2$ git push origin master:master+machine2

Następnie musisz scalić go, gdy jesteś w originzdalnym repozytorium:

machine1$ git merge master+machine2

Autopsja problemu

Kiedy gałąź jest wyewidencjonowana, zatwierdzanie doda nowe zatwierdzenie z nagłówkiem bieżącej gałęzi jako jej rodzicem i przesunie główkę gałęzi, aby była nowym zatwierdzeniem.

Więc

A ← B
    ↑
[HEAD,branch1]

staje się

A ← B ← C
        ↑
    [HEAD,branch1]

Ale gdyby ktoś mógł przepchnąć się do tej gałęzi między nimi, użytkownik znalazłby się w trybie, który git nazywa odłączonym trybem głowy :

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

Teraz użytkownik nie znajduje się już w gałęzi 1, bez wyraźnego poproszenia o sprawdzenie innej gałęzi. Co gorsza, użytkownik jest teraz poza jakimkolwiek oddziałem , a każde nowe zatwierdzenie będzie po prostu zwisać :

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

Hipotetycznie, jeśli w tym momencie użytkownik sprawdzi inny oddział, wówczas ten zwisający zatwierdzenie staje się uczciwą grą dla śmieciarza Gita .

Można obejść to „ograniczenie”, edytując .git/configna serwerze docelowym. Dodaj następujące elementy, aby umożliwić wypychanie repozytorium git, nawet jeśli jest ono „wypisane”:

[receive]
denyCurrentBranch = warn

lub

[receive]
denyCurrentBranch = false

Pierwszy pozwoli na push, ostrzegając jednocześnie o możliwości zepsucia gałęzi, podczas gdy drugi po prostu pozwoli na to spokojnie.

Można tego użyć do „wdrożenia” kodu na serwerze, który nie jest przeznaczony do edycji. To nie jest najlepsze podejście, ale szybkie wdrożenie kodu.

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

Użyj tego w repozytorium serwerów, a także zaktualizuje działające drzewo, jeśli nie nastąpi żadne nie śledzone nadpisanie.

Został on dodany w Git 2.3, jak wspomniał VonC w komentarzach.

Skompilowałem Git 2.3 i spróbowałem. Przykładowe użycie:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

Wynik:

a
b

Tak, bzostałem popchnięty!

Podoba mi się pomysł posiadania repozytorium nadającego się do użytku na zdalnym urządzeniu, ale zamiast fikcyjnej gałęzi, lubię używać:

git checkout --detach

To wydaje się być bardzo nową funkcją Gita - używam gita w wersji 1.7.7.4.

Miałem ten sam problem. Dla mnie używam Git push do przenoszenia kodu na moje serwery. Nigdy nie zmieniam kodu po stronie serwera, więc jest to bezpieczne.

W repozytorium pchasz się, aby wpisać:

git config receive.denyCurrentBranch ignore

Umożliwi to zmianę repozytorium, gdy jest ono kopią roboczą.

Po uruchomieniu wypychania Git przejdź do komputera zdalnego i wpisz:

git checkout -f

Spowoduje to, że wprowadzone zmiany zostaną odzwierciedlone w kopii roboczej zdalnego komputera.

Pamiętaj, że nie zawsze jest to bezpieczne, jeśli wprowadzisz zmiany w kopii roboczej, do której naciskasz.

Możesz odtworzyć repozytorium serwera i przekazać dane z lokalnego wzorca gałęzi do wzorca serwera.

Na zdalnym serwerze:

mkdir myrepo.git
cd myrepo.git
git init --bare

OK, z lokalnego oddziału:

git push origin master:master

Co prawdopodobnie zrobiłeś, aby to spowodować:

Takie rzeczy zdarzają się, gdy wybieracie mały program. Za chwilę zmienisz coś, co już działało, więc rzuciłeś zaklęcie ciągłego cofania poziomu 3:

machine1:~/proj1> git init

i zaczynasz dodawać / zatwierdzać. Ale potem projekt zaczyna się bardziej angażować i chcesz pracować na innym komputerze (takim jak domowy komputer stacjonarny lub laptop), więc robisz coś takiego

machine2:~> git clone ssh://machine1/~/proj1

i klonuje się i wszystko wygląda dobrze, więc pracujesz nad kodem z machine2.

Następnie ... próbujesz wypchnąć swoje zatwierdzenia z komputera2, i otrzymujesz komunikat ostrzegawczy w tytule.

Powodem tego komunikatu jest to, że repozytorium git, z którego ściągnąłeś, było przeznaczone do użycia tylko dla tego folderu na komputerze 1. Możesz go sklonować , ale pchanie może powodować problemy. „Właściwy” sposób zarządzania kodem w dwóch różnych lokalizacjach polega na „nagim” repozytorium, jak sugerowano. Nagie repozytorium nie jest zaprojektowane tak, aby można było w nim wykonać jakąkolwiek pracę , ma na celu koordynację zatwierdzeń z wielu źródeł. Dlatego najlepiej oceniana odpowiedź sugeruje usunięcie wszystkich plików / folderów innych niż folder .git po tobie git config --bool core.bare true.

Wyjaśnienie najwyżej ocenianej odpowiedzi: wiele komentarzy do tej odpowiedzi mówi coś w stylu: „Nie usunąłem plików innych niż .git z komputera 1 i nadal byłem w stanie zatwierdzić z komputera 2”. Zgadza się. Jednak te inne pliki są teraz całkowicie „rozwiedzione” z repozytorium git. Idź git statustam i powinieneś zobaczyć coś w rodzaju „fatal: Ta operacja musi być uruchomiona w drzewie roboczym”. Zatem propozycja usunięcia plików nie jest taka, aby zatwierdzenie z komputera2 działało ; jest tak, abyś nie pomylił się i nie pomyślał, że git nadal śledzi te pliki. Ale usunięcie plików jest problemem, jeśli nadal chcesz pracować na plikach na komputerze 1, prawda?

Co powinieneś naprawdę zrobić?

Zależy od tego, ile planujesz nadal pracować na komputerze 1 i komputerze 2 ...

Jeśli skończyłeś programować z komputera 1 i przeniosłeś cały program na komputer 2 ... po prostu zrób to, co sugeruje najwyżej oceniona odpowiedź: git config --bool core.bare truea następnie, opcjonalnie, usuń wszystkie pliki / foldery inne niż .git z tego folderu, ponieważ są nieśledzone i mogą powodować zamieszanie.

Jeśli twoja praca na maszynie2 była tylko jednorazową sprawą i nie musisz kontynuować tam rozwoju ... nie zawracaj sobie głowy tworzeniem repozytorium; po prostu ftp / rsync / scp / etc. pliki z komputera * 2 * na wierzchu plików na komputerze * 1 *, zatwierdzaj / wypychaj z komputera * 1 *, a następnie usuń pliki z komputera * 2 *. Inni sugerowali utworzenie gałęzi, ale myślę, że to trochę bałagan, jeśli chcesz po prostu połączyć rozwój, który zrobiłeś jednorazowo z innej maszyny.

Jeśli chcesz kontynuować rozwój zarówno na komputerze 1, jak i na komputerze 2 ... musisz odpowiednio skonfigurować ustawienia. Musisz przekonwertować swoje repozytorium na zwykłe, a następnie musisz utworzyć klon tego na maszynie1, abyś mógł w nim pracować . Prawdopodobnie najszybszym sposobem na zrobienie tego jest zrobienie tego

machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1

Bardzo ważne: ponieważ zmieniłeś lokalizację repozytorium z proj1 na proj1.git, musisz to zaktualizować w pliku .git / config na komputerze machine2 . Następnie możesz zatwierdzić zmiany z komputera2. Na koniec staram się trzymać moje nagie repo w centralnej lokalizacji, z dala od drzew roboczych (tj. Nie umieszczam „proj1.git” w tym samym folderze nadrzędnym, co „proj1”). Radzę zrobić to samo, ale chciałem, aby powyższe kroki były jak najprostsze.

W kilku krokach konfiguracji możesz łatwo wdrożyć zmiany w swojej witrynie przy użyciu jednego linku

git push production

Co jest miłe i proste, i nie musisz logować się do zdalnego serwera i robić nic takiego. Pamiętaj, że będzie to działać najlepiej, jeśli nie wykorzystasz kasy produkcyjnej jako działającej gałęzi! (OP działał w nieco innym kontekście i myślę, że rozwiązanie @Robert Gould dobrze to rozwiązało. To rozwiązanie jest bardziej odpowiednie do wdrożenia na zdalnym serwerze).

Najpierw musisz założyć puste repozytorium gdzieś na serwerze, poza twoim webrootem.

mkdir mywebsite.git
cd mywebsite.git
git init --bare

Następnie utwórz plik hooks/post-receive:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

I spraw, aby plik był wykonywalny:

chmod +x hooks/post-receive

Na twoim komputerze lokalnym

git remote add production git@myserver.com:mywebsite.git
git push production +master:refs/heads/master

Wszystko gotowe! Teraz w przyszłości możesz użyć git push productiondo wdrożenia zmian!

Kredyt za to rozwiązanie znajduje się na stronie http://sebduggan.com/blog/deploy-your-website-changes-using-git/ . Poszukaj bardziej szczegółowego wyjaśnienia tego, co się dzieje.

Powinieneś pchać tylko do samego repozytorium. Nagie repozytorium to repozytorium, które nie ma sprawdzonych gałęzi. Gdybyś miał przejść do katalogu nagiego repozytorium, zobaczyłbyś tylko zawartość katalogu .git.

Masz 3 opcje

1. Pociągnij i pchnij ponownie:

   git pull; git push
   

2. Wciśnij w inny oddział:

   git push origin master:foo
   

   i scal je zdalnie (przez żądaniegit lub pull-request )

   git merge foo
   

3. Wymuś to (niezalecane, chyba że celowo zmieniłeś zatwierdzanie przez rebase):

   git push origin master -f
   

   Jeśli nadal odmawia, wyłącz denyCurrentBranch na zdalnym repozytorium:

   git config receive.denyCurrentBranch ignore
   

W rzeczywistości ustawienie pilota na niezrejestrowaną gałąź jest wystarczające. Po sprawdzeniu pilota w innej gałęzi możesz pchać.

Sprawdź swój .git/configprojekt docelowy:

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

Jeśli core. barejest to fałsz, możesz ustawić na true:

$ git config core.bare true

a następnie w lokalnym push do zdalnego:

git push remote_repo   // suppose the destination repo is remote_repo

zakończy się sukcesem, w remote_repo możesz sprawdzić wersję git.

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
Date:   Thu May 17 21:54:37 2018 +0800

a teraz nie możesz używać git w swoim „obszarze roboczym”:

$ git status
fatal: This operation must be run in a work tree

powinieneś bare.barepowrócić do wartości false.

$ git config core.bare false

Miałem ten sam problem przy użyciu Git do synchronizacji repozytoriów na moim telefonie z Androidem i laptopie. Rozwiązaniem było dla mnie pociągnięcie zamiast push, jak sugerował @CharlesBailey.

git push origin master w repozytorium Androida nie powiodło się z tymi samymi komunikatami o błędach, które otrzymał @ hap497 z powodu wypychania do niezarejestrowanego pobrania repozytorium + kopia robocza.

git pull droid masterw repozytorium laptopa i kopii roboczej działa dla mnie. Oczywiście musisz wcześniej uruchomić coś takiego git remote add droid /media/KINGSTON4GB/notes_repo/.

Starsze wersje Git pozwalały na wypychanie do aktualnie wyewidencjonowanego oddziału niepublicznego repozytorium.

Okazuje się, że było to strasznie mylące. Dodali więc ostrzeżenie, które widzisz, co jest również bardzo mylące.

Jeśli pierwsze repozytorium działa tylko jako serwer, przekonwertuj je na zwykłe repozytorium, zgodnie z zaleceniami innych odpowiedzi i gotowe.

Jeśli jednak potrzebujesz współdzielonej gałęzi między dwoma repozytoriami, które są w użyciu, możesz to osiągnąć przy pomocy następującej konfiguracji

Repo1 - będzie działać jako serwer, a także będzie wykorzystywany do programowania

Repo2 - będzie tylko dla rozwoju

Skonfiguruj Repo1 w następujący sposób

Utwórz oddział, aby udostępnić pracę.

git branch shared_branch

Aby być bezpiecznym, powinieneś również utworzyć $ (REPO) .git / hooks / update, który odrzuca wszelkie zmiany w czymkolwiek innym niż shared_branch, ponieważ nie chcesz, żeby ludzie mulili się z twoimi prywatnymi oddziałami.

repo1/.git/hooks  (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"

if [ "${refname}" != "refs/heads/shared_branch" ]
then
   echo "You can only push changes to shared_branch, you cannot push to ${refname}"
   exit 1
fi

Teraz utwórz lokalny oddział w repo1, w którym wykonasz swoją rzeczywistą pracę.

git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'

(może wymagać git config --global push.default upstream, aby git pushdo pracy)

Teraz możesz utworzyć repo2 za pomocą

git clone path/to/repo1 repo2 
git checkout shared_branch 

W tym momencie masz zarówno konfigurację repo1, jak i repo2, aby działać na lokalnych oddziałach, które wypychają i wyciągają z shared_branchrepo1, bez potrzeby martwienia się o ten komunikat o błędzie lub zsynchronizowania katalogu roboczego w repo1. Niezależnie od tego, jakiego normalnego przepływu pracy używasz, powinno działać.

OK, jeśli chcesz normalne zdalne repozytorium, utwórz dodatkową gałąź i sprawdź ją. Wciśnij go do jednej gałęzi (która nie jest wyewidencjonowana) i połącz ją z tą, która jest obecnie aktywna później po wypchnięciu z lokalnie.

Na przykład na zdalnym serwerze:

git branch dev
git checkout dev

W konfiguracji lokalnej:

git push 

Na zdalnym serwerze:

git merge dev

Oto jeden test, który możesz zrobić, aby zobaczyć, jak baredziałają rzeczy związane z serwerem:

Wyobraź sobie, że masz na nim stację roboczą i serwer z działającą witryną i chcesz od czasu do czasu aktualizować tę witrynę (dotyczy to również sytuacji, w której dwóch programistów przesyła swoje prace tam iz powrotem przez gołego pośrednika).

Inicjalizacja

Utwórz katalog na komputerze lokalnym i cddo niego, a następnie wykonaj następujące polecenia:

# initialization
git init --bare server/.git
git clone server content
git clone server local

1. Najpierw utwórz pusty serverkatalog (zwróć uwagę na .git na końcu). Ten katalog będzie służył jako kontener tylko dla plików repozytorium.
2. Następnie sklonuj repozytorium serwera do nowo utworzonego contentkatalogu. To jest twój katalog na żywo / produkcyjny, który będzie obsługiwany przez oprogramowanie twojego serwera.
3. Pierwsze dwa katalogi znajdują się na serwerze, trzeci to katalog lokalny na stacji roboczej.

Przepływ pracy

Oto podstawowy przepływ pracy:

1. Wejdź do localkatalogu, utwórz niektóre pliki i zatwierdź je. Wreszcie wypchnij je na serwer:

   # create crazy stuff
   git commit -av
   git push origin master
   

2. Teraz przejdź do contentkatalogu i zaktualizuj zawartość serwera:

   git pull
   

3. Powtórz 1-2. Tutaj contentmoże być inny programista, który może również pchać na serwer, a localty możesz go wyciągnąć.

Wykorzystanie tego do przekazania go do zdalnego oddziału upstream rozwiązało dla mnie ten problem:

git push <remote> master:origin/master

Pilot nie miał dostępu do repozytorium nadrzędnego, więc był to dobry sposób na uzyskanie najnowszych zmian w tym pilocie

Musiałem ponownie uruchomić git --initw istniejącym nagim repozytorium, a to utworzyło .gitkatalog wewnątrz drzewa nagich repozytoriów - zdałem sobie sprawę, że po wpisaniugit status . Usunąłem to i znowu wszystko było w porządku :)

(Wszystkie te odpowiedzi są świetne, ale w moim przypadku było to coś zupełnie innego (o ile widzę), jak opisano.)

Jestem pewien, że większość osób przeglądających to pytanie zatrzyma się na pierwszych dwóch ogromnych odpowiedziach, ale nadal chciałbym zaoferować moje rozwiązanie.

Miałem konfigurację projektu internetowego Eclipse + EGit, gdy napotkałem opisany błąd. Pomogło mi po prostu użycie aplikacji GitHub, która w magiczny sposób rozwiązała problem. Podczas gdy EGit zawsze odmawiał pushowania, aplikacja komputerowa GitHub tylko wzruszyła ramionami i naciskała moje zmiany. Może w bardziej elegancki sposób radzi sobie z sytuacją wielokrotnego logowania.

Artykuł, który znalazłem, który może być przydatny dla innych, to Git za 5 minut .

Miałem projekt Xcode pod kontrolą wersji Git, który chciałem przekazać do wirtualnego rozproszonego Ethernetu (VDE), który mam w DC. VDE działa w Centos 5.

Żaden z artykułów, które czytałem o Git, nie mówił o czystych repozytoriach. Wszystko brzmiało tak prosto, dopóki nie spróbowałem, jak sądzę, łatwości pochodzącej z tła SVN .

Sugestie, aby zdalne repozytorium nie działało. Jeszcze lepiej dla moich wymagań było sklonowanie projektu Xcode projectname.git, skopiowanie go na zdalny serwer; następnie popycha magicznie działa. Następnym krokiem będzie nakłonienie Xcode do przesyłania bez błędów dotyczących zatwierdzeń, ale na razie nie mam nic przeciwko robieniu tego z Terminalu.

Więc:

cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>

Aby przesłać zmiany z projektu Xcode po zatwierdzeniu w Xcode:

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com:repos/projectname.git<br/>

Jestem pewien, że istnieje gładszy, bardziej wyrafinowany sposób na wykonanie powyższych czynności, ale przynajmniej to działa. Aby wszystko było jasne, oto kilka wyjaśnień: /xcode-project-directoryto katalog, w którym znajduje się twój projekt xcode. Prawdopodobnie jest/Users/Your_Name/Documents/Project_Name . nazwa projektu to dosłownie nazwa projektu, ale można go nazwać dowolną nazwą. Git nie dba o to.

Aby korzystać z SCP, musisz mieć konto użytkownika na zdalnym serwerze, który ma dostęp do SSH . Każdy, kto ma własny serwer, będzie miał taką możliwość. Jeśli korzystasz z hostingu współdzielonego lub podobnego, możesz nie mieć szczęścia.

remotehost.comto nazwa twojego zdalnego hosta. Możesz równie łatwo użyć jego adresu IP. Dla większej przejrzystości używam Gitosis na zdalnym hoście z kluczami SSH, więc nie popycham hasła, kiedy go wypycham . Artykuł Hosting Git Reposiaries, Easy (and Secure) Way mówi o tym, jak to wszystko skonfigurować.

Najlepszym sposobem na to jest:

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

Sklonuje to repozytorium, ale nie wykona żadnych kopii roboczych .../remote. Jeśli spojrzysz na pilota, zobaczysz utworzony jeden katalog o nazwie currentrepo.git, który prawdopodobnie jest tym, czego chcesz.

Następnie z lokalnego repozytorium Git:

git remote add remoterepo ..../remote/currentrepo.git

Po wprowadzeniu zmian możesz:

git push remoterepo master

Właśnie natrafiłem na ten problem z repozytorium git wdrażania na Heroku .

Nie wiem, po co Heroku ma po swojej stronie repozytorium, ale jako obejście tego problemu mogłem zresetować zdalne repozytorium i ponownie je załadować.

Nie powinieneś używać kopii swojego repozytorium Heroku jako jedynego repozytorium git do współpracy, ale na wszelki wypadek powiem jasno: nie rób tego, chyba że masz pewność, że masz pełną kopię swojego repozytorium bezpiecznie przechowywaną w innym miejscu niż Heroku. Wykonanie resetu spowoduje usunięcie zawartości repozytorium.

Zresetować:

0. Zainstaluj pasek narzędzi Heroku (który zawiera klienta wiersza poleceń), jeśli jeszcze tego nie zrobiłeś.

1. Zainstaluj wtyczkę heroku-repo, jeśli jeszcze tego nie zrobiłeś.

   heroku plugins:install https://github.com/heroku/heroku-repo.git
   

2. Wykonaj reset, który usuwa repozytorium i tworzy nowe, puste

   heroku repo:reset
   

3. Wciśnij do pilota Heroku, jak zwykle; wszystko ponownie załaduje.

Powiedzmy, że trzeba będzie zmienić plik konfiguracyjny na serwerze zdalnym po utworzeniu pustego (pustego) repozytorium

root@development:/home/git/repository/my-project# cat config 

tam zobaczysz

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

Przekształcisz to w fałsz w prawdę, a ja usunąłem logallrefupdates = true (nie jestem pewien, czy zostanie użyty!)

do

[core]
repositoryformatversion = 0
filemode = true
bare = true

Możesz przetestować następujące

$ git remote show origin
* remote origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push  URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)

Ta gałąź HEAD: (nieznana) zostanie wyświetlona, ​​jeśli nie możesz PUSH. Więc jeśli gałąź HEAD jest nieznana, powinieneś zmienić go na true, a po udanym wypychaniu możesz ponownie użyć

git remote show origin

i zobaczysz

 HEAD branch: master

Dla mnie działającym rozwiązaniem jest:

NA PILOCIE:

git checkout -b some_tmp_name

NA LOKALU:

git push

NA PILOCIE:

git checkout master
git branch -d some_tmp_name

Ale to nie jest prawdziwe rozwiązanie, to tylko obejście.

Na wypadek, gdyby ktoś uznał to za przydatne. Dla mnie był to problem z uprawnieniami serwera git. Sprawdziłem projekt od samego początku i wcisnąłem prosty plik, a następnie otrzymałem komunikat „Push push: Push to origin / master was został odrzucony”

Dzięki Git dwa zwykłe repozytoria (inne niż zwykłe) nie mogą bezpośrednio pchać / wyciągać plików tam i z powrotem. Musi istnieć pośrednie repozytorium nagie. Najwyraźniej to trochę jak małżeństwo, które ma dziecko, a para się rozwiedli. Rodzice nie będą ze sobą rozmawiać, ale będą komunikować się przez dziecko.

Masz więc jedno repozytorium, klonujesz je do nagiego repozytorium, a następnie klonujesz do trzeciego. Pierwszy i trzeci mogą wymieniać informacje za pośrednictwem drugiego repozytorium, samego. Wydaje mi się, że ma to sens, ponieważ nie chciałbyś, aby ktoś mógł sprawdzać rzeczy w twoim repozytorium bez twojej zgody, ponieważ mogłoby to powodować konflikty scalania i tym podobne.

Oto przykład:

Na PC, w ~ / workspace

git init
echo "line 1" > afile.txt
git add .
git commit -m ‘initial import’
git clone --bare . ../remote-repository.git
git remote add origin ../remote-repository.git
git push --set-upstream origin master

Na laptopie w ~ / workspace (nie uruchamiaj git init itp.)

git clone //LJZ-DELLPC/remote-repository.git/ .

// Następnie wykonaj różne zatwierdzenia i popchnij je:

echo "line 2" > afile.txt
git add afile.txt
git commit -m 'added line 2'
git push    

Następnie z powrotem na PC, w ~ / workspace

git pull

// Następnie wykonaj różne zatwierdzenia i popchnij je:

git push

Na laptopie git pull

i tak dalej..

Oto absolutnie konkretny przykład na jednym komputerze, skopiowany bezpośrednio z okna poleceń, abyśmy wiedzieli, że nie pominięto żadnych kroków, że naprawdę działało itp.:

lylez@LJZ-DELLPC ~
$ cd gitdir
/home/lylez/gitdir

lylez@LJZ-DELLPC ~/gitdir
$ ls

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 1" > afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'initial import'
[master (root-commit) f407e12] initial import
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ..

lylez@LJZ-DELLPC ~/gitdir
$ ls
repo1  repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1-remote

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git commit -m 'added line 2'
[master 5ad31e0] added line 2
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   f407e12..5ad31e0  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cd ../repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../repo1-bare-clone
   f407e12..5ad31e0  master     -> origin/master
Updating f407e12..5ad31e0
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 3" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'added line 3'
[master 3fa569e] added line 3
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../repo1-bare-clone
   5ad31e0..3fa569e  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ../repo1-remote/

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   5ad31e0..3fa569e  master     -> origin/master
Updating 5ad31e0..3fa569e
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote

Moje rozwiązanie (w użyciu)

1. Kasa „master” na zdalnym serwerze
2. Pracuj lokalnie na gałęzi „dev”
3. Wciśnij zmiany do zdalnego urządzenia
4. Scal dev w master na pilocie

bingo