Git: modo corretto per modificare Active Branch in un repository nudo?

195

Ho un repository nudo che viene utilizzato come archivio centrale per il mio progetto. Tutti gli sviluppatori fanno git clone <repo>per condividere con esso. Quando eseguono il clone, ottengono un checkout del ramo master (a meno che non lo faccia git clone -n) perché repo.git/HEADcontiene ref: refs/heads/master, rendendolo il ramo attivo .

La domanda è: come posso modificare correttamente l' Active Branch ? Potrei semplicemente hackerare il repo.git/HEADfile direttamente, ma questo sembra brutto e, beh, hacky.

Ho provato a farlo git checkout <otherbranch>nella .gitdirectory dei repository , ma non è riuscito perché non ero in un albero di lavoro.

Ho provato, git update-ref HEAD refs/heads/otherbranchma che refs / heads / master è stato aggiornato per essere lo stesso di refs / heads / otherbranch (ok, l'ho fatto in un repository fittizio, non in quello di produzione!)

Ci ho provato git update-ref --no-deref HEAD refs/heads/otherbranche ha funzionato quasi. Ha aggiornato il HEADfile, ma lo ha impostato su SHA1 del commit indicato da refs/heads/otherbranch.

Sto testando con la versione git 1.7.0.2.msysgit.0.

Immagino che non ci sia modo di farlo git push, dato che consentire a tutti quanti di cambiare il tuo ramo predefinito sembra un po 'pericoloso (!), Ma sicuramente c'è un modo migliore per farlo nella .gitdirectory repo che hackerare direttamente il HEADfile.

git

— kbro
fonte

IMO stai fondamentalmente cercando di fare The Wrong Thing qui. Se vuoi che il ramo predefinito sia qualcosa di diverso dal master, allora quel ramo deve essere il master. In alternativa, utilizzare due diversi repository.

— Nicholas Knight,

12

In che modo sta fondamentalmente cercando di fare la cosa sbagliata qui? Un repository nudo supporta più rami. Uso un repository nudo come backup nel mio repository locale e come tale rispecchia i rami. Ho un master su entrambi e un ramo di sviluppo su entrambi. Se voglio vedere il registro del ramo di sviluppo sul repository nudo, devo hackerare i file - sembra che git sia fondamentalmente sbagliato qui per quanto riguarda il supporto del repository nudo.

— Cthutu,

15

@NicholasKnight IMHO hai fondamentalmente torto qui. Non c'è niente di speciale in "master" come nome di un ramo, è solo un valore predefinito. Nei repository che mantengono non abbiamo una filiale principale, in quanto "principale" non è significativo per l'azienda. Ogni volta che eseguiamo un rilascio, creiamo un nuovo ramo di manutenzione con il nuovo numero di rilascio e lo assegniamo come ramo attivo.

— Spacemoose

@NicholasKnight Mentre apprezzo da dove vieni, questo è il primo SO Q / A che mi ha detto come passare al master! Avevo il mio repository iniziale su un ramo di feature quando ho creato il mio clone nudo, e i cloni successivi da quel repository nudo erano inadempienti su quel ramo anziché sul master.

— Warbo,

1

Caspita - questa domanda corre e corre - è il mio marcatore di punti reputazione numero 1! La cosa su "master" è che è solo un nome, e se non ha senso per la tua organizzazione, squadra, progetto, fase, qualunque cosa, quindi scegli qualcosa che È appropriato in modo che quando i tuoi collaboratori clonino il tuo repository cambino immediatamente al ramo in cui tu, come Configuration Manager, vuoi che siano attivi. Lavoravo con ClearCase (bletch!) Quindi le tue scelte erano "main", "main" o "main". Che schiffo.

— Kbro,

280

Se si ha accesso al repository nudo remoto, questo articolo suggerisce :

git symbolic-ref HEAD refs/heads/mybranch

Che aggiornerà il file HEAD nel tuo repository in modo che contenga:

ref: refs/heads/mybranch

come documentato nel git-symbolic-ref

Se non hai accesso al repository remoto, vedi la mia risposta precedente .

Ricorda che un comando come git remote set-head:

non modifica il ramo predefinito del repository remoto .
Modifica solo un ramo di tracciamento remoto memorizzato nel repository locale comerefs/remotes/<name>/HEAD
non cambia HEADse stesso (di nuovo, solo refs/remotes/<name>/HEAD), quindi la necessità di git symbolic-ref.

Quindi git remote set-head non è la risposta qui.
git symbolic-ref HEADè, se si ha accesso diretto al repository remoto.

— VonC
fonte

3

Grazie! Ho accesso diretto al repository nudo remoto quindi git-symbolic-ref farà il lavoro. Mi piace il trucco non comune-antenato menzionato sull'altro thread, sicuramente uno per il cassetto in basso. Ho passato anni a cercare su Google per questo, ma non sono riuscito a trovare la tua risposta precedente, eppure "git remote head master" lo trova come il secondo colpo più alto in classifica, proprio sotto git-remote (1). Bizzarro. Mostra solo quanto sia difficile trovare qualcosa quando non sai esattamente cosa stai cercando.

— Kbro,

git symbolic-ref HEAD refs/heads/mybranchha funzionato bene per me! GRAZIE! ;)

— vinzenzweber il

1

Apprezzo molto questa domanda, perché ho verificato per sbaglio un ramo diverso rispetto al master e ora ho dovuto risolverlo.

— Jonny Best il

Questo non funziona per me. Stranamente, anche se HEAD remoto nel repository nudo ora mostra il ramo corretto, git STILL mi imposta automaticamente su un ramo diverso quando clono da esso!

— Magnus,

@Magnus sarebbe una buona domanda da porre in una nuova pagina.

— VonC,

3

Per cambiare il ramo è necessario cambiare il riferimento HEAD al ramo che si desidera utilizzare.

Prima elenca tutti i riferimenti nel repository nudo eseguendo

$find ref

Quindi trova il riferimento per il tuo ramo, il formato sarà il seguente refs/heads/<my_branch>. Quindi il prossimo passo è controllare il riferimento corrente, basta digitare:

$git symbolic-ref HEAD

quindi sai qual è il ramo corrente quindi aggiornalo secondo necessità.

$git sumbolic-ref HEAD ref/heads/<my_branch>

Grazie. Godere.

— Saul Rosales
fonte

2

Come cambiare correttamente l'Active Branch?

status: checkout git nella directory .git del repository restituisce fatale: questa operazione deve essere eseguita in un albero di lavoro
suggerimenti: basta aggiungere l'argomento --work-tree

esempio dettagliato: ipotesi: bare git sul server remoto:

~ / bare_git_repository.git albero di lavoro distaccato: / var / www / myappremote

sul server locale: crea il ramo versione 1.7 (il nostro altro ramo)

git branch version.1.7

git push origin version.1.7

sul server remoto con repository git bare:

$ cd ~ / bare_git_repository.git

ramo $ git

versione principale 1.7

Come detto, seguendo il comando

git checkout version.1.7

ritorno

fatale: questa operazione deve essere eseguita in un albero di lavoro

Utilizzando il seguente comando

git --work-tree = / var / www / myappremote versione di pagamento. 1.7

cambiare correttamente il ramo attivo in modo corretto

ramo $ git

maestro

version.1.7

controllare i risultati con quanto segue

ll / var / www / myappremote

spero che possa aiutare

— C-tools
fonte

Questa soluzione molto semplice ha funzionato per me, grazie! Una nota: ho dovuto creare manualmente una directory dell'albero di lavoro vuota per eseguire correttamente il comando.

— Joël Esponde

-1

Inoltre, se non si ha accesso al repository nudo, eseguendo un git remote set-heade il gioco è fatto

Vedi questa risposta precedente

— dvdvck
fonte

-3

Ho anche un repository nudo sul nostro server ed è stato in grado di recuperare correttamente i file utilizzando

git clone //server/repo/directory -b branch_name

in un nuovo repository locale anche se la manpage dice che questo è solo per repository non nudi.

— MCJH
fonte

1

Mentre quello che dici è vero, il fatto che stai usando -b per selezionare un determinato ramo interrompe la tua risposta nel contesto della mia domanda, che è come impostare il ramo DEFAULT.

— Kbro,

-4

Ho confrontato due directory prima e dopo l'applicazione

git symbolic-ref HEAD refs/heads/mybranch

e sembra che solo il file repo.git / HEAD sia stato modificato, quindi probabilmente è abbastanza sicuro solo "hackerare" il file.

— boryn
fonte

2

Ci sono sottili problemi di rottura che possono essere introdotti modificando direttamente i file ref di Git. Consiglio vivamente contro questo. I comandi idraulici sono più facili e sicuri della modifica diretta dei riferimenti.

— Alain O'Dea,

2

Qual è il vantaggio di questo @boryn?

— Alex Chamberlain,

2

Git tiene traccia di molte cose in background come una storia di riferimenti. Se si modifica manualmente il file, non verrà registrato. È vero che probabilmente non importerà. Ma se perdi traccia di alcuni commit e vuoi trovarli, sarai più felice se non avessi semplicemente "hackerato" il file.

— qwerty9967,

Ho usato il comando. Ma questa risposta è stata utile per capire come funziona e, in parte, per capire che refs / head è qualcosa di interno e non dovrei cambiarlo, solo l'ultima parte del "percorso". Quindi, ho votato perché penso che dopo tutto siano state informazioni preziose.

— Mike Keskinov,