Pourquoi dois-je pousser explicitement une nouvelle twig?

Je suis nouveau et je pratique. J’ai créé une twig locale, mais j’ai vu que lorsque j’ai git push ma twig n’a pas été téléchargée dans le référentiel. Je devais vraiment faire: git push -u origin --all .
Pourquoi est-ce? Une twig n’est-elle pas un nouveau changement à imposer par défaut? Pourquoi dois-je exécuter la deuxième commande?

La raison réelle est que, dans un nouveau repo (git init), il n’y a pas de twig (pas de master , pas de twig du tout, zéro twig)

Ainsi, lorsque vous lancez pour la première fois un référentiel en amont vide (généralement un serveur nu ), ce référentiel en amont n’a pas de twig du même nom.

Et:

  • la politique de push par défaut était ” match ” (poussez toutes les twigs du même nom, en les créant si elles n’existent pas),
  • la politique push par défaut est maintenant ‘ simple ‘ (ne poussez que la twig courante et seulement si elle a une twig de suivi distante nommée de la même manière en amont, depuis git 1.7.11 )

Dans les deux cas, puisque le référentiel vide en amont n’a pas de twig:

  • il n’y a pas encore de twig nommée correspondante
  • il n’y a pas de twig en amont du tout (avec ou sans le même nom! Tracking ou pas)

Cela signifie que votre premier appel local n’a aucune idée:

  • où pousser
  • quoi pousser (puisqu’il ne trouve aucune twig en amont enregistrée en tant que twig de suivi à distance et / ou portant le même nom)

Il faut donc au moins faire un:

 git push origin master 

Mais si vous ne faites que cela, vous:

  • créera une twig master amont sur l’amont (maintenant repo non vide): good.
  • n’enregistre pas que la twig locale ‘ master ‘ doit être poussée en amont ( origin ) ‘ master ‘ (twig en amont): bad.

C’est pourquoi il est recommandé, pour la première fois, de faire un:

 git push -u origin master 

Cela enregistrera l’ origin/master tant que twig de suivi à distance , et activera la poussée suivante pour pousser automatiquement le master vers l’ origin/master .

 git checkout master git push 

Et cela fonctionnera aussi avec les politiques de poussée « current » ou «en upstream ».
Dans tous les cas, après le git push -u origin master initial, une simple pression sur git sera suffisante pour continuer à pousser le maître vers la twig en amont droite.

Vous ne voyez pas ci-dessous

Je trouve cette fonctionnalité plutôt ennuyeuse car je n’essaie pas de lancer des fusées sur la lune, il suffit de pousser ma foutue twig. Vous faites probablement aussi ou sinon vous ne seriez pas là!

Voici le correctif: si vous voulez qu’il pousse implicitement pour la twig en cours, peu importe si cette twig existe à l’origine, émettez simplement cette commande une seule fois et vous n’aurez plus jamais à la réutiliser:

 git config --global push.default current 

Donc, si vous faites des twigs comme ceci:

 git checkout -b my-new-branch 

et ensuite faire des commits et ensuite faire un

 git push -u 

pour les sortir à l’origine (étant sur cette twig) et cela créera cette twig pour vous si elle n’existe pas.

Notez que le bit -u s’assure qu’ils sont liés si vous devez extraire plus tard de cette twig. Si vous ne prévoyez pas de retirer la succursale plus tard (ou si vous faites un autre doublage si vous le faites), -u n’est pas nécessaire.

Sortie de git push en poussant une nouvelle twig

 > git checkout -b new_branch Switched to a new branch 'new_branch' > git push fatal: The current branch new_branch has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin new_branch 

Un simple git push suppose qu’il existe déjà une twig distante que la twig locale actuelle suit. Si aucune twig distante n’existe et que vous souhaitez la créer, vous devez spécifier celle-ci à l’aide de l’indicateur -u (forme abrégée de --set-upstream ).

Pourquoi c’est comme ça? Je suppose que les développeurs ont estimé que créer une twig sur la télécommande était une action tellement importante qu’il devrait être difficile de le faire par erreur. git push est quelque chose que vous faites tout le temps.

“Une twig n’est-elle pas un nouveau changement à apporter par défaut?” Je dirais que “un changement” dans Git est un engagement. Une twig est un pointeur sur un commit. Pour moi, cela a plus de sens de penser à une poussée comme quelque chose qui pousse les commits vers les autres référentiels. Les commits sont déterminés par la twig sur laquelle vous vous trouvez et la relation de suivi de cette twig avec les twigs de la télécommande.

Vous pouvez en savoir plus sur le suivi des succursales dans le chapitre Branches distantes du livre Pro Git .

Je n’ai pas pu trouver une justification rapide pour les développeurs originaux, mais je peux vous donner une estimation éclairée basée sur quelques années d’expérience de Git.

Non, toutes les succursales ne sont pas quelque chose que vous voulez pousser vers le monde extérieur. Cela pourrait représenter une expérience privée.

De plus, où git push devrait git push envoyer toutes les twigs? Git peut fonctionner avec plusieurs télécommandes et vous pouvez avoir différentes séries de twigs sur chacune. Par exemple, un repo de projet central GitHub peut avoir des twigs de publication; un fork GitHub peut avoir des twigs de sujet à revoir; et un serveur Git local peut avoir des twigs contenant une configuration locale. Si git push poussait toutes les twigs vers la télécommande que la twig actuelle suit, ce type de schéma serait facile à bousiller.

HEAD est l’abréviation de la twig actuelle, donc git push -u origine HEAD fonctionne. Maintenant, pour éviter cette saisie à chaque fois que j’utilise un alias:

git config –global alias.pp ‘push -u origine HEAD’

Après cela, chaque fois que je veux pousser une twig créée via la twig git -b, je peux la pousser en utilisant:

git pp

J’espère que cela fait gagner du temps à quelqu’un!

Au premier contrôle

Étape 1: git remote -v
// si git initialise puis supprime ou ignore l’étape 2

Étape 2: git remote rm origin
// Configurez ensuite votre adresse e-mail globalement

Étape 3: git config --global user.email "[email protected]"

Étape 4: git initial

Étape 5: git commit -m "Initial Project"
// Si déjà append un repository de projet, ignorez l’étape 6

Étape 6: git remote add origin %repo link from bitbucket.org%

Étape 7: git push -u origin master