Git: Comment corriger la branche active dans un référentiel nu?

195

J'ai un référentiel nu utilisé comme magasin central pour mon projet. Tous les développeurs font git clone <repo>pour partager avec elle. Quand ils font le clone, ils obtiennent une extraction de la branche principale (à moins qu'ils le fassent git clone -n) car repo.git/HEADcontient ref: refs/heads/master, ce qui en fait la branche active .

La question est, comment puis-je changer la branche active correctement? Je pourrais simplement pirater le repo.git/HEADfichier directement, mais cela semble méchant et, bien, hacky.

J'ai essayé de faire git checkout <otherbranch>dans le .gitrépertoire repo , mais cela a échoué car je n'étais pas dans un arbre de travail.

J'ai essayé git update-ref HEAD refs/heads/otherbranchmais juste mis à jour refs / heads / master pour être le même que refs / heads / otherbranch (ok, j'ai fait celui-ci dans un dépôt factice, pas celui de production!)

J'ai essayé git update-ref --no-deref HEAD refs/heads/otherbranchet ça a presque fonctionné. Il a mis à jour le HEADfichier, mais il l'a défini sur le SHA1 de la validation pointée par refs/heads/otherbranch.

Je teste avec la version git 1.7.0.2.msysgit.0.

Je suppose qu'il n'y a aucun moyen de le faire git push, car autoriser tout le monde à changer votre branche par défaut semble un peu dangereux (!), Mais il y a sûrement une meilleure façon de le faire dans le .gitrépertoire repo que de pirater directement le HEADfichier.

git

— kbro
source

OMI, vous essayez simplement de faire la mauvaise chose ici. Si vous voulez que la branche par défaut soit autre que master, alors cette branche doit être master. Vous pouvez également utiliser deux référentiels différents.

— Nicholas Knight

12

Comment cela essaie-t-il fondamentalement de faire la mauvaise chose ici? Un référentiel nu prend en charge plusieurs branches. J'utilise un référentiel nu en tant que sauvegarde de mon référentiel local et, en tant que tel, reflète les branches. J'ai un master sur les deux et une branche développement sur les deux. Si je veux voir le journal de la branche de développement sur le dépôt nu, je dois pirater des fichiers - il semble que git ait fondamentalement tort ici en ce qui concerne le support du dépôt nu.

— Cthutu

15

@NicholasKnight À mon humble avis, vous avez fondamentalement tort ici. Il n'y a rien de spécial à propos de "master" comme nom de branche, c'est juste une valeur par défaut. Dans les dépôts qui maintiennent, nous n'avons pas de succursale principale, car «maître» n'a pas de sens pour l'entreprise. Chaque fois que nous faisons une version, nous créons une nouvelle branche de maintenance avec le nouveau numéro de version, et l'assignons comme branche active.

— Spacemoose

@NicholasKnight Bien que j'apprécie d'où vous venez, c'est le premier SO Q / A qui m'a dit comment passer en master! J'avais mon dépôt initial sur une branche de fonctionnalité lorsque j'ai créé mon clone nu, et les clones suivants de ce dépôt nu étaient par défaut sur cette branche au lieu de maître.

— Warbo

1

Wow - cette question court et tourne - c'est mon meilleur marqueur de points de réputation! La chose à propos de "master" est que c'est juste un nom, et si cela n'a pas de sens pour votre organisation, équipe, projet, phase, peu importe, alors choisissez quelque chose qui EST approprié pour que lorsque vos collaborateurs clonent votre référentiel, ils changent immédiatement à la branche sur laquelle vous, en tant que Gestionnaire de configuration, souhaitez qu'ils se trouvent. J'avais l'habitude de travailler avec ClearCase (bletch!) Donc vos choix étaient "principal", "principal" ou "principal". Yuk.

— kbro

280

Si vous avez accès au référentiel nu à distance, cet article suggère :

git symbolic-ref HEAD refs/heads/mybranch

Qui mettra à jour le fichier HEAD dans votre référentiel afin qu'il contienne:

ref: refs/heads/mybranch

comme documenté dans le git-symbolic-ref

Si vous n'avez pas accès au référentiel distant, consultez ma réponse précédente .

N'oubliez pas qu'une commande comme git remote set-head:

ne change pas la branche par défaut du dépôt distant .
Il modifie uniquement une branche de suivi à distance stockée dans votre référentiel local commerefs/remotes/<name>/HEAD
ne se change pas HEAD(encore, seulement refs/remotes/<name>/HEAD), d'où la nécessité de git symbolic-ref.

Ce git remote set-head n'est donc pas la réponse ici.
git symbolic-ref HEADest, si vous avez un accès direct au référentiel distant.

— VonC
source

3

Merci! J'ai un accès direct au référentiel nu à distance, donc git-symbolic-ref fera le travail. J'aime bien l'astuce sans ancêtre commun mentionnée sur l'autre fil - certainement une pour le tiroir du bas. J'ai passé des années à googler pour cela, mais je n'ai pas trouvé votre réponse précédente, mais "git remote head master" le trouve comme le deuxième hit le plus élevé, juste en dessous de git-remote (1). Bizarre. Va juste montrer à quel point il est difficile de trouver quelque chose quand on ne sait pas exactement ce que l'on cherche.

— kbro

git symbolic-ref HEAD refs/heads/mybrancha très bien fonctionné pour moi! MERCI! ;)

— vinzenzweber

1

J'apprécie vraiment cette question, car j'ai accidentellement vérifié une branche différente de celle de master et maintenant je devais y remédier.

— Jonny Best

Ça ne marche pas pour moi. Curieusement, même si la tête distante dans le référentiel nu affiche maintenant la branche correcte, git STILL me par défaut à une autre branche lorsque je clone à partir d'elle!

— Magnus

@Magnus, ce serait une bonne question à poser dans une nouvelle page.

— VonC

3

Pour modifier la branche, vous devez remplacer la référence HEAD par la branche que vous souhaitez utiliser.

Listez d'abord toutes les références dans le référentiel nu en faisant

$find ref

Trouvez ensuite la référence de votre branche, le format sera le suivant refs/heads/<my_branch>. La prochaine étape consiste donc à vérifier la référence actuelle, il suffit de taper:

$git symbolic-ref HEAD

afin que vous sachiez quelle est la branche actuelle, puis mettez-la à jour si nécessaire.

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

Thant c'est tout. Prendre plaisir.

— Saul Rosales
source

2

Comment changer la branche active correctement?

status: git checkout dans le répertoire repo .git renvoie fatal: cette opération doit être exécutée dans une arborescence de travail
conseils: ajoutez simplement l'argument --work-tree

exemple détaillé: hypothèses: bare git sur serveur distant:

~ / bare_git_repository.git arbre de travail détaché: / var / www / myappremote

sur le serveur local: créer la branche version 1.7 (notre autre branche)

git branch version.1.7

git push origin version.1.7

sur le serveur distant avec git bare repo:

$ cd ~ / bare_git_repository.git

$ git branch

maître
version.1.7

Comme indiqué, suite à la commande

git checkout version.1.7

revenir

fatal: cette opération doit être exécutée dans une arborescence de travail

Utilisation de la commande suivante

git --work-tree = / var / www / myappremote checkout version.1.7

modifier correctement la branche active

$ git branch

Maître

version.1.7

vérifier les résultats avec ce qui suit

ll / var / www / myappremote

j'espère que cela vous aidera

— c-tools
source

Cette solution très simple a fonctionné pour moi, merci! Une remarque: j'ai dû créer un répertoire d'arborescence de travail vide pour que la commande s'exécute avec succès.

— Joël Esponde

-1

De plus, si vous n'avez pas accès au référentiel nu, en faisant un git remote set-head et vous avez terminé

Voir cette réponse précédente

— dvdvck
source

-3

J'ai également un dépôt nu sur notre serveur et j'ai réussi à récupérer des fichiers en utilisant

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

dans un nouveau référentiel local même si la page de manuel indique que ce n'est que pour les référentiels non nus.

— mcjh
source

1

Bien que ce que vous dites soit vrai, le fait que vous utilisez -b pour sélectionner une branche particulière rompt votre réponse dans le contexte de ma question, qui est de savoir comment définir la branche DEFAULT.

— kbro

-4

J'ai comparé deux répertoires avant et après avoir postulé

git symbolic-ref HEAD refs/heads/mybranch

et il semble que seul le fichier repo.git / HEAD ait été modifié, il est donc très sûr de "pirater" le fichier.

— boryn
source

2

Il existe des problèmes de rupture subtils qui peuvent être introduits en modifiant directement les fichiers de référence Git. Je le déconseille fortement. Les commandes de plomberie sont plus faciles et plus sûres que la modification directe des références.

— Alain O'Dea

2

Quel est l'avantage de ce @boryn?

— Alex Chamberlain

2

Git garde une trace de beaucoup de choses en arrière-plan comme une histoire de références. Si vous modifiez manuellement le fichier, il ne sera pas enregistré. Il est vrai que cela n'aura probablement pas d'importance. Mais si vous perdez la trace de certains commits et que vous souhaitez les trouver, vous serez plus heureux si vous n'avez pas simplement "piraté" le fichier.

— qwerty9967

J'ai utilisé la commande. Mais cette réponse a été utile pour comprendre comment cela fonctionne, et, en particulier, pour comprendre que refs / heads est quelque chose de interne et je ne devrais pas le changer, seulement la dernière partie du "chemin". J'ai donc voté parce que je pense que ce sont des informations précieuses après tout.

— Mike Keskinov