Jak korzystasz z repozytorium „git --bare init”?

Muszę utworzyć centralne repozytorium Git, ale jestem trochę zdezorientowany ...

Utworzyłem puste repozytorium (na moim serwerze git, maszyna 2) z:

$ mkdir test_repo
$ git --bare init

Teraz muszę przesłać pliki z mojego lokalnego repozytorium (komputer 1) do nagiego repozytorium (komputer 2). Mam dostęp do maszyny 2 przez SSH. Chodzi o to, że myślę, że nie rozumiem koncepcji nagiego repozytorium ...

Jaki jest właściwy sposób przechowywania mojego kodu w czystym repozytorium? Jak mogę wypchnąć zmiany z mojego lokalnego repozytorium do samego repozytorium?

Czy to właściwy sposób na posiadanie centralnego repozytorium, aby mieć puste repozytorium?

Jestem trochę zmieszany z tym tematem. Proszę dać mi wskazówkę na ten temat.

Po pierwsze, aby to sprawdzić, musisz przejść do katalogu utworzonego przed uruchomieniem git init --bare. Ponadto konwencjonalne jest nadawanie rozszerzonym repozytoriom .git. Więc możesz to zrobić

git init --bare test_repo.git

W przypadku wersji Git <1.8 zrobiłbyś to

mkdir test_repo.git
cd test_repo.git
git --bare init

Aby odpowiedzieć na twoje późniejsze pytania, do nagich repozytoriów (z definicji) nie jest dołączone działające drzewo, więc nie możesz łatwo dodawać do nich plików, tak jak w normalnym repozytorium innym niż nagie (np. Z git add <file>i po nim git commit. )

Prawie zawsze aktualizujesz nagie repozytorium, wypychając je (używając git push) z innego repozytorium.

Pamiętaj, że w takim przypadku musisz najpierw pozwolić użytkownikom na wypychanie do Twojego repozytorium. test_repo.gitZrób to w środku

git config receive.denyCurrentBranch ignore

Edycja społeczności

git init --bare --shared=group

Jak komentuje prasanthv, tego właśnie chcesz, jeśli robisz to w pracy, a nie w przypadku prywatnego projektu domowego.

Dodam tę odpowiedź, ponieważ po przybyciu tutaj (z tym samym pytaniem) żadna z odpowiedzi tak naprawdę nie opisuje wszystkich wymaganych kroków niezbędnych do przejścia od zera do w pełni użytecznego zdalnego (nagiego) repozytorium.

Uwaga: ten przykład używa lokalnych ścieżek do lokalizacji samego repo, ale inne protokoły git (takie jak SSH wskazane przez OP) powinny działać dobrze.

Po drodze próbowałem dodać notatki dla osób mniej zaznajomionych z git.

1. Zainicjuj nagie repo ...

> git init --bare /path/to/bare/repo.git
Initialised empty Git repository in /path/to/bare/repo.git/

Spowoduje to utworzenie folderu (repo.git) i zapełnienie go plikami git reprezentującymi repozytorium git. W obecnej chwili repozytorium jest bezużyteczne - nie zawiera żadnych zobowiązań, a co ważniejsze, nie ma oddziałów . Chociaż możesz sklonować to repozytorium, nie możesz z niego wyciągnąć.

Następnie musimy utworzyć folder roboczy. Można to zrobić na kilka sposobów, w zależności od tego, czy masz istniejące pliki.

2a. Utwórz nowy folder roboczy (bez istniejących plików), klonując puste repozytorium

git clone /path/to/bare/repo.git /path/to/work
Cloning into '/path/to/work'...
warning: You appear to have cloned an empty repository.
done.

To polecenie działa tylko wtedy, /path/to/workgdy nie istnieje lub jest pustym folderem. Zwróć uwagę na ostrzeżenie - na tym etapie nadal nie masz nic przydatnego. Jeśli cd /path/to/workpobiegniesz git status, dostaniesz coś takiego:

On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)

ale to kłamstwo. Tak naprawdę nie jesteś na gałęzi master(ponieważ git branchnic nie zwraca) i jak dotąd nie ma żadnych zobowiązań.

Następnie skopiuj / przenieś / utwórz niektóre pliki w folderze roboczym, dodaj je do git i utwórz pierwszy zatwierdzenie.

> cd /path/to/work
> echo 123 > afile.txt
> git add .
> git config --local user.name adelphus
> git config --local user.email [email protected]
> git commit -m "added afile"
[master (root-commit) 614ab02] added afile
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

Te git configpolecenia są potrzebne tylko wtedy, gdy nie mają już powiedziano git, kim jesteś. Pamiętaj, że jeśli teraz uruchomisz git branch, zobaczysz mastergałąź na liście. Teraz uruchom git status:

On branch master
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

nothing to commit, working directory clean

Jest to również mylące - upstream jeszcze nie „zniknął”, po prostu nie został jeszcze stworzony i git branch --unset-upstreamnie pomoże. Ale to w porządku, teraz, kiedy mamy pierwsze zatwierdzenie, możemy wypchnąć, a master zostanie utworzony na samym repozytorium.

> git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 207 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /path/to/bare/repo.git
 * [new branch]      master -> master

W tym momencie mamy w pełni funkcjonalne nagie repozytorium, które można klonować gdzie indziej w gałęzi master, a także lokalną kopię roboczą, która może ciągnąć i pchać.

> git pull
Already up-to-date.
> git push origin master
Everything up-to-date

2b. Utwórz folder roboczy z istniejących plików Jeśli masz już folder z plikami (więc nie możesz go sklonować), możesz zainicjować nowe repozytorium git, dodać pierwsze zatwierdzenie, a następnie połączyć je z samym repozytorium.

> cd /path/to/work_with_stuff
> git init 
Initialised empty Git repository in /path/to/work_with_stuff
> git add .
# add git config stuff if needed
> git commit -m "added stuff"

[master (root-commit) 614ab02] added stuff
 20 files changed, 1431 insertions(+)
 create mode 100644 stuff.txt
...

W tym momencie mamy nasz pierwszy zatwierdzenie i lokalną gałąź master, którą musimy przekształcić w zdalnie śledzoną gałąź upstream.

> git remote add origin /path/to/bare/repo.git
> git push -u origin master
Counting objects: 31, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (31/31), done.
Writing objects: 100% (31/31), 43.23 KiB | 0 bytes/s, done.
Total 31 (delta 11), reused 0 (delta 0)
To /path/to/bare/repo.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

Zwróć uwagę na -uflagę na git push, aby ustawić (nową) śledzoną gałąź nadrzędną. Tak jak poprzednio, mamy teraz w pełni funkcjonalne nagie repozytorium, które można klonować w innym miejscu w gałęzi master, a także lokalną kopię roboczą, którą można pobierać i wypychać.

Dla niektórych może to wydawać się oczywiste, ale git w najlepszym razie mnie dezorientuje (komunikaty o błędach i statusie naprawdę wymagają przeróbek) - mam nadzieję, że pomoże to innym.

Odpowiadając na pytania jeden po drugim:

Nagie repozytorium to takie, które nie ma działającego drzewa . Oznacza to, że cała jego zawartość jest tym, co masz w .gitkatalogu.

Możesz tylko commitodsłonić repozytorium, pushwchodząc do niego z lokalnego klonu. Nie ma działającego drzewa, więc nie ma zmodyfikowanych plików, żadnych zmian.

Aby mieć centralne repozytorium, jedynym sposobem jest posiadanie barerepozytorium.

Możesz także poprosić git o utworzenie dla ciebie katalogu:

git init --bare test_repo.git

Ogólna praktyka polega na tym, że centralne repozytorium ma dostęp do repozytorium.

Jeśli masz tło SVN, możesz powiązać repozytorium SVN z repozytorium Git bare. Nie ma plików w repozytorium w oryginalnej formie. Podczas gdy Twoje lokalne repozytorium będzie dodatkowo zawierało pliki, które tworzą „kod”.

Musisz dodać pilota do samego repozytorium z repozytorium lokalnego i wcisnąć do niego swój „kod”.

Będzie to coś w stylu:

git remote add central <url> # url will be ssh based for you
git push --all central

To powinno wystarczyć:

git remote add origin <url-of-bare-repo>
git push --all origin

Zobacz więcej szczegółów „ GIT: Jak zaktualizować moje nagie repo? ”.
Uwagi:

• możesz użyć innej nazwy niż „ origin” dla zdalnego odniesienia do repozytorium.
• to nie popchnie twoich tagów, potrzebujesz do tego osobnego git push --tags origin.

Miło jest zweryfikować, czy kod, który wypchnąłeś, rzeczywiście został zatwierdzony.

Możesz uzyskać dziennik zmian w czystym repozytorium, jawnie ustawiając ścieżkę za pomocą opcji --relative.

$ cd test_repo
$ git log --relative=/

Spowoduje to wyświetlenie zatwierdzonych zmian, jakby to było zwykłe repozytorium git.

Na podstawie odpowiedzi Marka Longaira i Roboprog:

jeśli wersja git> = 1.8

git init --bare --shared=group .git
git config receive.denyCurrentBranch ignore

Lub:

jeśli wersja git <1.8

mkdir .git
cd .git
git init --bare --shared=group 
git config receive.denyCurrentBranch ignore

Flaga --bare tworzy repozytorium, które nie ma katalogu roboczego. Samo repozytorium jest centralnym repozytorium i nie można tutaj edytować (przechowywać) kodów, aby uniknąć błędu scalania.

Na przykład po dodaniu pliku do lokalnego repozytorium (komputer 1) i wypchnięciu go do pustego repozytorium nie można zobaczyć pliku w pustym repozytorium, ponieważ jest on zawsze „pusty”. Jednak naprawdę wypychasz coś do repozytorium i możesz to zobaczyć w sposób niejawny poprzez klonowanie innego repozytorium na twoim serwerze (maszyna 2).

Zarówno lokalne repozytorium na komputerze 1, jak i repozytorium „kopiuj” na komputerze 2 nie są puste. związek między nagimi a nie nagimi repozytoriami

Blog pomoże ci to zrozumieć. https://www.atlassian.com/git/tutorials/setting-up-a-repository

Możesz wykonać następujące polecenia, aby zainicjować lokalne repozytorium

mkdir newProject
cd newProject
touch .gitignore
git init
git add .
git commit -m "Initial Commit"
git remote add origin user@host:~/path_on_server/newProject.git
git push origin master

Powinieneś pracować nad projektem z lokalnego repozytorium i używać serwera jako centralnego repozytorium.

Możesz również postępować zgodnie z tym artykułem, który wyjaśnia każdy aspekt tworzenia i utrzymywania repozytorium Git. Git dla początkujących