Pousser les commits et publier une branche

• Inspectez la source et la destination avant de pousser.
• Avancez rapidement une branche derrière uniquement sans validation de fusion.
• Publiez une fonctionnalité nommée et vérifiez-la en amont.
• Distinguer le refus du travail perdu.

Commencez là où la leçon 11 s'est terminée : main/H6 extrait, origin/main/server H7 avec le pied de page de Leo, clean, main six versus récupéré sept commits et 0/1. La fonctionnalité F1 existe uniquement localement sans amont.

La vidéo a été enregistrée avec Git 2.52.0 et GitTree 2.0 sur Ubuntu 24.04 : l'avance rapide, les push et l'amont ont été effectués dans l'application ; les contrôles avant et après et les push refusés se sont déroulés dans le terminal. Rien n'a été exécuté sur macOS ou Windows, et Ubuntu est le seul système Linux enregistré. Le niveau Git source de GitTree est 2.39.0.

GitTree vous demande de vous connecter ; le plan gratuit couvre ensuite chaque étape ici. Aucun compte fournisseur, Pro/essai, identifiant API ou service Internet n'est nécessaire. Une origine locale nue n'est pas GitLab ou CI. Toutes les identités utilisent example.com ; n'exécutez jamais cette leçon dans une extraction de source.

Effectuez des mutations via GitTree ou le chemin natif à des entrées identiques, pas les deux consécutivement. Une vérification en lecture seule peut suivre l'une ou l'autre. Toute préparation décrite comme un travail de terminal est étiquetée préparation native, jamais une fonctionnalité d'application inventée.

Push propose des mises à jour des références distantes sélectionnées. Il ne s'agit pas d'une sauvegarde de chaque fichier, tampon ou branche non suivi. Une destination peut rejeter une mise à jour même lorsqu'une connexion réseau fonctionne.

Le H7 entrant descend du principal/H6. Une avance rapide peut déplacer le principal vers ce descendant sans inventer de validation de fusion. Cette opération d’ascendance étroitement énoncée est introduite ici ; l'intégration divergente fait partie des leçons ultérieures du cours.

La publication de cartes de fonctionnalités/tarifications envoie F1 vers une nouvelle branche de serveur. Dans GitTree, ce push ne choisit pas l'amont : vous le définissez ensuite à partir de la même ligne de branche. Il ne change pas de branche actuelle et ne fusionne pas ses cartes de workflow dans main. Un push principal sans opération réussi n’est pas une nouvelle validation de serveur.

L'avance rapide explicite change main/HEAD, index et work en H7. Push modifie uniquement la référence du serveur sélectionné et le suivi/configuration locale après succès ; il n'enregistre pas le texte non mis en scène. Le principal distant doit conserver le commit de Leo.

Utilisez l'original après la leçon 11, récupérez l'arrière-plan pour un aperçu stable. Aucune nouvelle charge utile de fichier ou bloc-notes n’est ajouté. Le rejet intentionnel derrière le principal est une prise native distincte, et non une instruction pour cliquer sur la poussée forcée de l'application.

Palette : Commande+Maj+P (Ctrl+Maj+P sur Ubuntu) ; tapez la commande exactement nommée et sélectionnez-la. Les actions de référence nommée utilisent le menu contextuel de cette ligne, et non un raccourci de palette sans argument.

1. Sur l'écran principal, inspectez la source/destination réelle et les comptes 0/1 ; ne poussez pas l'ancien principal en premier dans la prise canonique.
2. Dans le groupe Distant du panneau latéral, cliquez avec le bouton droit sur origin/main → Merge origin/main into main. Dans Record it as, choisissez Fast-forward only, puis Merge. Attendez-vous à principal en H7 avec le pied de page de Leo, un parent et une ligne droite dans le graphique.
3. Exécutez les relectures d’ascendance/nettoyage ci-dessous ; si le principal diverge, annulez plutôt que de choisir un mode de réécriture.
4. Cliquez sur la barre d'outils Push sur la page principale. L'avis indique « Tout était déjà à jour. » : il ne s'agit pas d'un nouveau commit.
5. Sous Local, ouvrez le dossier feature et cliquez avec le bouton droit sur pricing-cards → Push feature/pricing-cards. Avec une seule télécommande, il n'y a pas de dialogue : l'avis indique "Cartes de fonctionnalité/tarification poussées vers l'origine/caractéristique/cartes de tarification".
6. Le push n'a pas défini d'amont (la branche n'en avait pas). Faites un clic droit sur la même ligne → Upstream → Set Upstream…, dans What should feature/pricing-cards track? choisissez origin/feature/pricing-cards, puis Track. Vérifiez la fonctionnalité du serveur F1 et l'amont.
7. Sélectionnez les étiquettes des graphiques principaux et caractéristiques sans paiement ; confirmez qu'ils restent des astuces différentes et qu'aucune fusion n'est apparue.
8. Laissez le serveur principal extrait, propre et les deux branches de serveur nommées vérifiées. Ne sélectionnez pas Force Push… et ne publiez pas chaque réf.

Pour chaque commit ordinaire : le résumé est le sujet indiqué ; Description vide ; Modifier la validation précédente, ignorer les crochets, ajouter une signature par un auteur différent, appuyer après la validation et autoriser la validation vide ; pas de co-auteurs. Mettez en scène uniquement les fichiers nommés, puis validez les modifications dans N fichiers une fois (fichier pour un) ou Commande+Entrée comme alternative. Attendez le vrai résultat. Une leçon qui modifie explicitement ne change que cette option indiquée.

À partir de la démo originale, alternative native :

git rev-list --left-right --count main...origin/main
git merge --ff-only --quiet origin/main
git push --quiet origin main
git push --quiet --set-upstream origin feature/pricing-cards
git rev-list --left-right --count main...origin/main
git rev-parse --abbrev-ref 'feature/pricing-cards@{upstream}'
git symbolic-ref --short HEAD
git status --short

Premier compte0/1 ; avance rapide et pousse silencieusement la sortie 0. Les relectures finales s'impriment, dans l'ordre :

0	0
origin/feature/pricing-cards
main

Le statut est silencieux. Comparez indépendamment les SHA réels du serveur/local principal et des fonctionnalités avec git ls-remote --heads origin ; les ID de variable doivent correspondre aux astuces locales prévues. Prise négative séparée avant l'avance rapide : git push --quiet origin main exited1 avec l'extrait de diagnostic réel :

 ! [rejected]        main -> main (non-fast-forward)

Le diagnostic complet nomme l’URL du fichier local mesuré et les astuces Git. Aucune référence distante n'a changé sur ce refus ; ne fabriquez pas l’URL et ne réparez pas de force.

Where you end: principal avancé rapidement vers H7 et toujours extrait/propre ; le serveur principal reste H7. La fonctionnalité F1 est désormais publiée sous forme de cartes d'origine/fonctionnalité/tarification et elle est suivie ; main et feature n’ont pas été fusionnés.

• Publier le principal actuel lorsque vous parliez de la fonctionnalité nommée.
• Traiter un refus derrière seulement comme une autorisation d’écraser Leo.
• En supposant que le push définisse la fonctionnalité en amont, ou que ce paramètre fusionne quoi que ce soit : l'application a besoin de l'étape distincte Définir en amont….

Après refus, récupérez et inspectez l’ascendance/destination avant de réessayer. Pour cette entrée exacte en arrière-plan, utilisez l'avance rapide explicite. Un push à distance n'a pas d'application générique Annuler ; coordonner toute correction ultérieure à distance.

Répondez à chaque question, puis lisez pourquoi. Les questions marquées « Obligatoire » comptent pour terminer la leçon.

1. Question 1 de 6

   Question 1 de 6

   A quoi sert la publication de F1 ?

   Choisissez une réponse.

   Crée la branche distante sélectionnée

   Enregistre les tampons non suivis

   Fusionne F1 dans le principal

   Vérifier la réponse
2. Question 2 de 6

   Question 2 de 6

   Quels faits sont valables après le succès canonique ?

   Choisissez chaque réponse qui s'applique.

   La fonctionnalité a son propre amont

   HEAD est passé automatiquement à la fonctionnalité

   Restes principaux H7

   Vérifier la réponse
3. Question 3 de 6

   Question 3 de 6Obligatoire

   Avance rapide principal/H6 vers le descendant H7 : nouveau commit de fusion ?

   Choisissez une réponse.

   La F1 disparaît

   Oui, deux parents

   Non

   Vérifier la réponse
4. Question 4 de 6

   Question 4 de 6Obligatoire

   Modifier l'entrée : poussez l'ancien H6 sur le serveur H7 avant l'alignement.

   Choisissez une réponse.

   Refusé sans force

   Le serveur rembobine en toute sécurité

   La force est requise par le cours

   Vérifier la réponse
5. Question 5 de 6

   Question 5 de 6

   Push dit déjà à jour. La F1 est-elle publiée ?

   Choisissez une réponse.

   Seulement si sa référence de serveur nommée vérifie

   Jamais

   Toujours

   Vérifier la réponse
6. Question 6 de 6

   Question 6 de 6Obligatoire

   Quelle preuve finale est nécessaire ?

   Choisissez chaque réponse qui s'applique.

   Fonctionnalité en amont et caisse principale propre

   Un bouton vert seul

   Faire correspondre les conseils serveur/local prévus

   Vérifier la réponse

Prouvez l’égalité H7 principal/serveur, l’égalité fonctionnalité/serveur F1, la fonctionnalité en amont, l’extraction principale inchangée et l’état propre. Dans une ancienne copie principale séparée, prédisez et observez le refus sans perdre H7.

• Inspectez la destination exacte.
• Intégrez explicitement un descendant derrière uniquement.
• Publiez une branche sans la fusionner.

• Récupérer la modification d'un coéquipier sans remplacer votre page (leçon 11)
• Connecter une télécommande sans la confondre avec une amont (leçon 10)
• Télécharger GitTree

Pousser — دفع; branche de publication — نشر فرع ; en amont — الفرع المتتبَّع; avance rapide — تقديم سريع.