Hoe converteer je een normale Git-repository naar een kale?

Hoe kan ik een ‘normale’ Git-repository converteren naar een kale?

Het belangrijkste verschil lijkt te zijn:

• in de normale Git-repository heb je een map .gitin de repository met alle relevante gegevens en alle andere bestanden waaruit je werkkopie bestaat

• in een kale Git-repository is er geen werkkopie en de map (laten we het repo.gitnoemen) bevat de daadwerkelijke repositorygegevens

Antwoord 1, autoriteit 100%

Kortom: vervang de inhoud van repodoor de inhoud van repo/.giten vertel de repository dat het nu een kale repository is.

Voer hiervoor de volgende opdrachten uit:

cd repo
mv .git ../repo.git # renaming just for clarity
cd ..
rm -fr repo
cd repo.git
git config --bool core.bare true

Merk op dat dit anders is dan het doen van een git clone --barenaar een nieuwe locatie (zie hieronder).

Antwoord 2, autoriteit 38%

Uw methode lijkt te werken; de bestandsstructuur van een kale repository is precies wat zich in de .git-map bevindt. Maar ik weet niet of een van de bestanden daadwerkelijk is gewijzigd, dus als dat niet lukt, kun je dat gewoon doen

git clone --bare /path/to/repo

Je zult het waarschijnlijk in een andere map moeten doen om een ​​naamconflict te voorkomen, en dan kun je het gewoon terugzetten naar waar je maar wilt. En mogelijk moet u het configuratiebestand wijzigen zodat het verwijst naar waar uw oorspronkelijke repo zich bevindt.

Antwoord 3, autoriteit 18%

Ik denk dat de volgende link nuttig zou zijn

GitFaq: Hoe maak ik een bestaande niet-bare repository kaal ?

$ mv repo/.git repo.git
$ git --git-dir=repo.git config core.bare true
$ rm -rf repo

Antwoord 4, autoriteit 11%

Tenzij je specifiek bits op het bestandssysteem wilt of moet draaien, is het echt doodeenvoudig om een ​​kale versie van een niet-bare repository te maken (vermeld in verschillende andere berichten hier). Het maakt deel uit van de kernfunctionaliteit van git:

git clone --bare existing_repo_path bare_repo_path

Antwoord 5, autoriteit 4%

Overweeg ook om

git clone --mirror path_to_source_repository path_to_bare_repository

Van de documentatie:

Stel een mirror van de bronrepository in. Dit impliceert –kaal. In vergelijking met –bare wijst –mirror niet alleen lokale vertakkingen van de bron toe aan lokale vertakkingen van het doel, het wijst alle refs toe (inclusief vertakkingen die op afstand volgen, notities enz.) en stelt een refspec-configuratie in zodat al deze refs worden overschreven door een git remote update in de doelrepository.

Antwoord 6

Ik wilde gewoon naar een repository op een netwerkpad pushen, maar Git liet me dat niet doen, tenzij die repository als kaal was gemarkeerd.
Ik hoefde alleen maar de configuratie te wijzigen:

git config --bool core.bare true

Je hoeft niet met de bestanden te knoeien, tenzij je het schoon wilt houden.

Antwoord 7

ik heb de antwoorden gelezen en heb dit gedaan:

cd repos
mv .git repos.git
cd repos.git
git config --bool core.bare true # from another answer
cd ../
mv repos.git ../
cd ../
rm -rf repos/ # or delete using a file manager if you like

hierdoor blijft de inhoud van repos/.gitals de kale repos.git

Antwoord 8

Dit is wat ik denk dat het veiligst en eenvoudigst is. Er is hier niets dat hierboven niet is vermeld. Ik wil gewoon een antwoord zien dat een veilige stapsgewijze procedure laat zien. Je start een map op vanuit de repository (repo) die je kaal wilt maken. Ik heb de hierboven geïmpliceerde conventie aangenomen dat kale repository-mappen een .git-extensie hebben.

(1) Backup, just in case.
    (a) > mkdir backup
    (b) > cd backup
    (c) > git clone ../repo
(2) Make it bare, then move it
    (a) > cd ../repo
    (b) > git config --bool core.bare true
    (c) > mv .git ../repo.git
(3) Confirm the bare repository works (optional, since we have a backup)
    (a) > cd ..
    (b) > mkdir test
    (c) > cd test
    (d) > git clone ../repo.git
(4) Clean up
    (a) > rm -Rf repo
    (b) (optional) > rm -Rf backup/repo
    (c) (optional) > rm -Rf test/repo

Antwoord 9

Toegevoegd 2:
Na het schrijven van het antwoord realiseerde ik me dat het geaccepteerde antwoord waarschijnlijk hetzelfde resultaat zou opleveren op mijn pc als het werd gevolgd door git add *.

Ik heb bestanden uit mijn werkmap laten verdwijnen (alleen .gitover), het is weer lekker compact door:

git switch --orphan some_new_branch_name 

Vervolgens converteren naar kaal als men dat wil:

git config --bool core.bare true

Op die manier blijft de configuratie inclusief externe link behouden:

$ git config --list
core.repositoryformatversion=0
core.filemode=true
core.bare=true
remote.origin.url=https://github.com/vmatare/thinkfan.git
remote.origin.fetch=+refs/*:refs/*
remote.origin.mirror=true

Toegevoegd:
In de opmerkingen wordt vermeld dat het “geen door git genegeerde bestanden” zou verwijderen, in dat geval moeten ze bovendien handmatig worden verwijderd (of de repository zelf, dat is de .git-submap, moet ergens anders worden verplaatst).

Opmerkingen:
Vóór core.bare trueresulteerden sommige acties in fouten:

$ git fetch --all
Fetching origin
fatal: Refusing to fetch into current branch refs/heads/devel of non-bare repository
error: Could not fetch origin

some_new_branch_namezijn daarna niet vermeld in de uitvoer van git branch. Om verder te testen heb ik git checkout mastergedaan. Ik kreeg bestanden keer op keer geen some_new_branch_namein uitvoer van git branch, dus ik denk dat nieuwe orphanbranch zou niet aan de repository worden toegevoegd, tenzij daar wat werk wordt gedaan (en/of commits worden uitgevoerd).

Antwoord 10

Oneliner voor het uitvoeren van alle bovenstaande bewerkingen:

for i in `ls -A .`; do if [ $i != ".git" ]; then rm -rf $i; fi; done; mv .git/* .; rm -rf .git; git config --bool core.bare true

(geef me niet de schuld als er iets ontploft en je had geen back-ups :P)

Antwoord 11

Wauw, het is gewoon verbazingwekkend hoeveel mensen hierop inspeelden, vooral als je bedenkt dat er geen enkele stopte om te vragen waarom deze persoon doet wat hij doet.

Het ENIGE verschil tussen een kale en niet-bare git-repository is dat de niet-bare versie een werkkopie heeft. De belangrijkste reden waarom je een kale repo nodig hebt, is dat als je deze beschikbaar wilt stellen aan een derde partij, je er niet direct aan kunt werken, dus op een gegeven moment moet je hem klonen en op dat moment ben je meteen terug naar een gewone werkkopieversie.

Dat gezegd hebbende, om te converteren naar een kale repo hoef je alleen maar ervoor te zorgen dat er geen commits in behandeling zijn en dan gewoon :

rm -R * && mv .git/* . && rm -R .git

Zo, kale repo.