advanced git commands
Ce didacticiel explore les commandes Git utiles telles que Git Stash, Git Reset, Git Cherry Pick, Git Bisect et explique comment intégrer GitHub avec Jira:
Dans nos précédents tutoriels de cette série, nous avons vu la plupart des fonctionnalités de GitHub.
Dans ce didacticiel, nous examinerons les éléments suivants:
- Créer des versions
- Intégration avec Atlassian Jira
- Commandes Git les plus couramment utilisées pour les développeurs
- Git Stash
- Git Cherry Pick
- Réinitialiser Git
- Git Bisect
=> Jetez un œil au guide GitHub ici.
sites Web pour télécharger des vidéos youtube en mp3
Ce que vous apprendrez:
- Créer des versions
- Intégration de GitHub avec Jira
- Commandes Git avancées pour les développeurs
- Conclusion
- lecture recommandée
Créer des versions
Les versions de GitHub sont utilisées pour regrouper votre logiciel, ajouter des notes de version et des binaires (fichiers WAR, EAR, JAR) pour que les clients et les personnes les utilisent.
Pour créer une version, allez sur la page principale du référentiel et cliquez sur le Communiqués onglet sous Gérez les sujets.
Cliquer sur Créez une nouvelle version.
Fournissez une étiquette et un titre de version. Les binaires sont également ajoutés à la version. Une fois terminé, cliquez sur Publier la version.
La version est maintenant prête avec le code source et les binaires.
Intégration de GitHub avec Jira
L'un des aspects importants de la traçabilité est de référencer le problème Jira avec les commits dans GitHub. GitHub peut être intégré à Jira non seulement pour référencer le problème, mais également pour aider à créer des branches et Pull Request à partir de Jira.
Donc typiquement, une fois que le développeur commence à travailler sur la tâche ou les bogues, une branche est créée par lui. Après le développement ou la résolution des bogues, une pull request peut être créée à partir de Jira pour fusionner avec le fichier principal Maître branche. La branche créée par le développeur peut alors être supprimée.
Pour configurer l'intégration, nous avons utilisé un plugin Intégration Git pour Jira. Ceci est un plugin commercial. Le plugin peut être téléchargé depuis Ici
Installez le plugin dans Jira depuis Admin -> Modules complémentaires.
Une fois le plugin installé, accédez à Application -> Dépôts Git et connectez-vous à GitHub.
Saisissez le nom d'utilisateur et le mot de passe GitHub. Cliquez sur Relier .
Les référentiels mentionnés pour le compte utilisateur seront affichés. Cliquer sur Importer des référentiels pour terminer la configuration de l'intégration.
GitHub Commit avec un problème Jira
Dans le cadre du message de validation, entrez comme indiqué ci-dessous. Cliquer sur Valider les modifications .
Exemple 1: Voici un exemple de Commit intelligent qui permet aux développeurs d'effectuer des actions sur les problèmes Jira à partir du message de validation. L'une de ces commandes est la #commenter avec la clé Issue qui ajoute le commentaire au problème Jira comme indiqué ci-dessous.
Section des commentaires mise à jour.
Exemple 2: Attribuer à un utilisateur et mettre à jour le temps passé à 4 h.
Utilisez le #attribuer et #temps commande de validation intelligente dans le message de validation.
Les deux actions sont terminées.
Exemple 3: Remplacez le statut du problème par En cours .
Créer une branche
Lorsque des tâches et des bogues sont attribués aux développeurs, ils doivent commencer à travailler sur le développement. Pour cela, ils créent une branche pour le problème sur lequel ils travaillent, effectuent les activités de développement et lancent une pull request pour fusionner dans la branche principale.
Dans le numéro Jira en bas, cliquez sur Créer une branche.
Cliquer sur Créez une branche.
Dans GitHub, apportez une modification au fichier dans la branche créée ci-dessus et validez le même.
Une fois le développement terminé, l'utilisateur peut alors émettre une Pull Request depuis Jira.
En bas du numéro, cliquez sur Créer une demande d'extraction.
Cliquer sur Créer. La demande de tirage sera affichée comme étant ouverte.
L'étape suivante consiste à fusionner la demande d'extraction dans GitHub.
Le statut est mis à jour en conséquence dans Jira.
Commandes Git avancées pour les développeurs
Dans cette dernière section, nous examinerons certaines des commandes Git couramment utilisées par les développeurs. Rien à voir avec GitHub mais aidera les développeurs avant de pousser les modifications vers GitHub.
Git Stash
Dans la plupart des scénarios de projet, lorsque vous travaillez sur une nouvelle fonctionnalité ou une amélioration, vous devrez soudainement travailler sur un défaut urgent qui a été signalé et qui est un frein. Comme vous êtes à mi-chemin de votre nouveau travail et que vous ne l'êtes pas terminé, il est inutile de valider les changements qui sont à moitié faits.
Il est donc préférable de suspendre ou de sauvegarder temporairement le travail à moitié terminé, de travailler sur le bogue et de revenir travailler sur la nouvelle fonctionnalité ou l'amélioration. Git stash fournit une solution à cela. Vous pouvez facilement changer de contexte pour effectuer des modifications rapidement.
Exemple 1 :Supposons que vous travaillez sur une tâche qui vous est assignée et que lorsque vous regardez l'état, cela montre qu'elle n'est pas suivie pour le moment.
Soudain, un bogue hautement prioritaire vous est assigné. Ainsi, nous devons temporairement sauvegarder ou cacher le travail en cours de travail.
Exécutez la commande suivante.
git stash save 'Message'
À ce moment, le répertoire de travail est propre. Toute nouvelle validation peut être effectuée et s'il y a des bogues, vous pouvez changer de branche pour travailler dessus, etc.
Lorsque vous souhaitez réappliquer les modifications là où vous les aviez laissées, utilisez la commande.
git stash pop
La commande ci-dessus supprimera la réserve de la liste et appliquera le dernier état enregistré.
Vous pouvez aussi utiliser:
git stash apply
La commande ci-dessus conservera les modifications dans la réserve et ne les supprimera pas.
Maintenant, les modifications sont réappliquées et vous pouvez valider les modifications.
Exemple 2: Stockez vos modifications, changez de branche et fusionnez les modifications.
Apportez la modification au fichier Html dans le Maître changements de branche et de réserve.
Ensuite, passez au punaise branchez, apportez des modifications et validez les modifications.
git checkout -b bogue
Apportez des modifications au fichier Html.
git commit -a -m 'Problème de messagerie résolu'
Revenez au Maître branchez et réappliquez les modifications depuis la réserve.
Maintenant, fusionnez du punaise branche à la Maître branche. Validez les modifications après la fusion.
Exemple 3: Travailler avec plusieurs Stash.
Dans le dépôt local, il y a 2 fichiers Html. Ainsi, il est possible que plusieurs développeurs travaillent sur plusieurs fichiers et cachent les modifications au besoin pour travailler sur les demandes urgentes qui se présentent pour corriger les modifications.
Le développeur 1 fonctionne sur hello.html et le développeur 2 sur index.html.
Développeur 1
La liste de réserve a 1 entrée maintenant.
Développeur 2
La liste de réserve a maintenant 2 entrées. La dernière cachette est la première dans la pile qui est la cachette @ {0}. Désormais, les deux développeurs peuvent effectuer d'autres validations de toute urgence ou travailler sur une autre branche, puis revenir au Maître branchez et appliquez les modifications de la réserve.
Pour appliquer la dernière réserve, vous pouvez simplement exécuter
git stash pop
Pour appliquer une réserve spécifique dans la pile, exécutez la commande suivante.
git stash pop stash @ {1}
Appliquons la deuxième réserve qui est cachette @ {1}
De même, l'autre réserve peut être appliquée.
Git Cherry Pick
Aujourd'hui, les développeurs travaillent sur plusieurs branches comme les fonctionnalités, les améliorations, les bogues, etc.
Il existe des situations où seuls quelques commits spécifiques doivent être sélectionnés et non fusionner la branche entière dans une autre branche. C'est ce qu'on appelle un Cherry Pick. Ce processus vous permet de choisir arbitrairement n'importe quel commit Git dans les autres branches et de l'ajouter au HEAD actuel de l'arbre de travail.
Exemple 1:
Dans le référentiel git local, nous avons les 6 fichiers suivants.
Un fichier est supprimé, par exemple file5.txt.
Validez les modifications.
Regardez le journal maintenant. File5.txt est supprimé.
Donc, nous voulons Cherry-Pick le commit où nous avons ajouté file5.txt. Nous devons trouver l'ID de validation de file5.tx et exécuter la commande.
git cherry-pick
Dans ce cas, l'ID de validation du moment où file5.txt a été ajouté est a2f0124
File5.txt est maintenant restauré. Nous avons choisi le commit.
Exemple 2:
Modifions simplement file6.txt et valider les changements dans le Maître branche.
Regardez la deuxième ligne dans file6.txt où l'e-mail n'est pas spécifié correctement.
Créez une branche de bogue et corrigez le problème. En même temps, modifiez également file5.txt afin que nous ayons plusieurs commits effectués dans la branche de bogue, mais Cherry-Pick uniquement le commit fait dans file6.txt.
Fichier6 modifié dans punaise branche.
Donc, dans l'ensemble, nous avons apporté des modifications à file5 et file6 dans la branche Bug.
Revenons maintenant à la Maître branch et Cherry-Choisissez le commit fait pour file6.txt uniquement.
Comme vous pouvez le voir, au lieu de fusionner punaise branche dans le Maître branche, nous venons de sélectionner un commit spécifique et de l'appliquer dans la branche master.
Réinitialiser Git
Git reset est une commande puissante pour annuler les modifications locales. Ainsi, pour désinstaller tous les fichiers intermédiaires, cette commande est utilisée.
Exemple
Modifiez un fichier et ajoutez-le à la préparation. Réinitialisez à l'aide de la commande comme indiqué lorsque les modifications par étapes ne sont pas enregistrées.
Paramètres de git reset commander.
-mou, tendre: Ce paramètre pointera le HEAD vers un autre commit. Tous les fichiers sont modifiés entre le HEAD d'origine et le commit sera mis en scène. Le répertoire de travail est intact.
Regardez l'emplacement actuel de HEAD.
Revenons en arrière sur 5 commits dans l’historique.
Ré-valider les modifications.
-mixte: L'option est similaire au paramètre soft. Habituellement, quand il y a de mauvais commits, vous les supprimez et corrigez le problème plus tard et le validez à nouveau. Donc, essentiellement, nous devons ajouter à l'index en utilisant git ajouter puis git commit. Les modifications sont laissées dans l'arborescence de travail.
Revenons en arrière sur 2 commits dans l'historique et voyons que les fichiers ne sont pas suivis.
Ajoutez maintenant les fichiers à la préparation et validez les modifications.
-difficile: Ce paramètre restera au point où un fichier particulier existait. Les modifications ne seront pas disponibles dans l'arborescence de travail.
En regardant le journal ci-dessus, revenons au point où seul le fichier 1 a été validé, c'est-à-dire la dernière entrée.
En utilisant git reset –hard
Git Bisect
Trouvez le commit exact qui a cassé le code (nous sommes tous des humains après tout). Souvent, lors des tests de l'application, nos testeurs nous disent qu'il y a un bogue ou que la fonctionnalité est cassée et vous, en tant que développeur, direz que cela a fonctionné la semaine dernière. Alors, que s'est-il passé et pourquoi ce bug est-il apparu?
Parfois, une modification de l'autre code a pu avoir un impact sur votre fonctionnalité. Vous devez passer du temps à parcourir l'historique où il y a beaucoup de commits qui prennent du temps et qui sont difficiles à suivre, quel changement a provoqué la rupture du code.
Git Bisect est la commande pour trouver le commit exact lorsque le bogue a été introduit. Avec Git bisect, vous devez choisir deux commits, un bon et un mauvais. Environ à mi-chemin entre les deux commits sera extrait. Vous vérifiez que chaque commit est mauvais ou bon jusqu'à ce que le commit qui a provoqué la rupture du bogue ou du code soit trouvé.
Exemple:
- Créez un nouveau référentiel git local et créez un fichier appelé index.html
- Contenu initial du fichier comme indiqué.
- Ajoutez à la staging et validez dans le référentiel.
- Créez un historique des commits comme indiqué, afin que nous puissions choisir entre les bons et les mauvais commits. Maintenant que la validation initiale est terminée, effectuez les autres modifications comme indiqué et validez la même chose. Au total, nous ferons 7 commits.
Deuxième changement
Troisième changement
Quatrième changement
Cinquième changement
Sixième changement
Septième changement
Arrêtons-nous ici. Donc, nous avons sept commits.
Si vous regardez la page Html, les lignes après «Tous les 4 événements…» sont fausses et donc la documentation n'est pas correcte. Donc, nous devons trouver le commit où l'erreur a été introduite afin que nous puissions reposer notre HEAD sur ce commit.
Examinons le journal et découvrons le mal et bon engagement.
Le dernier commit n'est pas correct, donc ça peut être un mauvais commit. Le commit a été introduit après le troisième commit, donc nous pouvons avoir le Troisième changement comme le bon commettre.
Le processus de coupe en deux commence par git bisect start et se termine par git bisect reset.
git bisect mauvais // Le dernier commit est mauvais. Pas besoin de fournir l'ID de validation.
git bisect bien
Vous pouvez maintenant voir que HEAD est maintenant entre la moitié du mauvais et du bon commit.
Regardez le contenu de index.html et voyez s'il y a un bon commit. Sinon, l'erreur n'est toujours pas trouvée.
Pas vraiment que l'erreur existe toujours. La dernière ligne est fausse. Alors, nous courons ‘ git bisect bad ». Il y a toujours un mauvais commit et le contenu actuel n'est pas acceptable.
Le contenu ci-dessus est correct et acceptable.
Exécutez «git log –oneline» et «git bisect good».
Alors le Cinquième changement était le premier mauvais commit et vraiment. L'erreur est identifiée.
Le contenu actuel doit figurer dans la documentation finale.
Lorsque le mauvais commit est identifié, vous pouvez informer le développeur de corriger les changements qui pourraient être de réinitialiser la tête au quatrième changement qui était le dernier bon commit.
Courir ' git bisect reset »Pour mettre fin au processus.
Conclusion
Dans cette introduction pratique de GitHub, nous avons essayé de couvrir tout ce sur quoi un développeur aurait besoin de travailler, c'est-à-dire du point de vue du contrôle de version et du suivi.
Dans les trois premiers didacticiels de la série GitHub, nous avons découvert les activités de contrôle de version, la création de référentiels, la pull request, les branches, les revues de code, les organisations et les équipes, la création d'un référentiel, les étiquettes, les jalons, les problèmes, les tableaux de projets, les wikis, les versions, l'intégration avec Jira et certaines commandes Git couramment utilisées pour les développeurs.
Nous espérons vraiment que tous les développeurs trouveront cette approche pratique pour GitHub et les commandes Git utiles dans leurs projets.
=> Lisez la série de formations Easy GitHub.
lecture recommandée
- Tutoriel d'intégration GitLab Jira
- Commandes Unix: commandes Unix de base et avancées avec exemples
- Intégration de Selenium avec GitHub à l'aide d'Eclipse
- Tutoriel d'intégration JIRA et SVN
- Git vs GitHub: explorez les différences avec des exemples
- Tutoriel Cucumber Selenium: Intégration Cucumber Java Selenium WebDriver
- Tutoriel GitHub pour les développeurs | Comment utiliser GitHub
- Tutoriel Unix Pipes: Pipes dans la programmation Unix