-
1. DĂ©marrage rapide
-
2. Les bases de Git
-
3. Les branches avec Git
-
4. Git sur le serveur
- 4.1 Protocoles
- 4.2 Installation de Git sur un serveur
- 4.3 Génération des clés publiques SSH
- 4.4 Mise en place du serveur
- 4.5 DĂ©mon (Daemon) Git
- 4.6 HTTP intelligent
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git hébergé
- 4.10 Résumé
-
5. Git distribué
-
6. GitHub
-
7. Utilitaires Git
- 7.1 SĂ©lection des versions
- 7.2 Indexation interactive
- 7.3 Remisage et nettoyage
- 7.4 Signer votre travail
- 7.5 Recherche
- 7.6 RĂ©Ă©crire lâhistorique
- 7.7 Reset démystifié
- 7.8 Fusion avancée
- 7.9 Rerere
- 7.10 DĂ©boguer avec Git
- 7.11 Sous-modules
- 7.12 Empaquetage (bundling)
- 7.13 Replace
- 7.14 Stockage des identifiants
- 7.15 Résumé
-
8. Personnalisation de Git
- 8.1 Configuration de Git
- 8.2 Attributs Git
- 8.3 Crochets Git
- 8.4 Exemple de politique gérée par Git
- 8.5 Résumé
-
9. Git et les autres systĂšmes
- 9.1 Git comme client
- 9.2 Migration vers Git
- 9.3 Résumé
-
10. Les tripes de Git
- 10.1 Plomberie et porcelaine
- 10.2 Les objets de Git
- 10.3 Références Git
- 10.4 Fichiers groupés
- 10.5 La refspec
- 10.6 Les protocoles de transfert
- 10.7 Maintenance et récupération de données
- 10.8 Les variables dâenvironnement
- 10.9 Résumé
-
A1. Annexe A: Git dans dâautres environnements
- A1.1 Interfaces graphiques
- A1.2 Git dans Visual Studio
- A1.3 Git dans Visual Studio Code
- A1.4 Git dans IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git dans Sublime Text
- A1.6 Git dans Bash
- A1.7 Git dans Zsh
- A1.8 Git dans PowerShell
- A1.9 Résumé
-
A2. Annexe B: Embarquer Git dans vos applications
- A2.1 Git en ligne de commande
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Commandes Git
- A3.1 Installation et configuration
- A3.2 Obtention et création des projets
- A3.3 Capture dâinstantanĂ© basique
- A3.4 Création de branches et fusion
- A3.5 Partage et mise Ă jour de projets
- A3.6 Inspection et comparaison
- A3.7 DĂ©bogage
- A3.8 Patchs
- A3.9 Courriel
- A3.10 SystĂšmes externes
- A3.11 Administration
- A3.12 Commandes de plomberie
6.2 GitHub - Contribution Ă un projet
Contribution Ă un projet
AprÚs avoir configuré votre compte, examinons comment contribuer à un projet existant.
Duplication des projets
Si vous souhaitez contribuer Ă un projet existant sur lequel vous nâavez pas le droit de pousser, vous pouvez dupliquer (fork) ce projet. Cela signifie que GitHub va faire pour vous une copie personnelle du projet. Elle se situe dans votre espace de nom et vous pouvez pousser dessus.
Note
|
Historiquement, le terme « fork » transmet une idĂ©e nĂ©gative, qui sâapparente Ă lâidĂ©e que quelquâun mĂšne un projet open-source vers une direction diffĂ©rente, crĂ©ant un projet concurrent de lâoriginal et divisant les forces de contributions. Au sein de GitHub, un « fork » constitue une simple copie dâun projet au sein de votre espace de nom personnel, ce qui vous permet dây apporter publiquement des modifications, câest donc tout simplement un moyen de contribuer de maniĂšre plus ouverte. |
Ainsi, les gestionnaires de projets nâont pas Ă se soucier de devoir ajouter des utilisateurs comme collaborateurs pour leur accorder un accĂšs en poussĂ©e. Les personnes peuvent dupliquer un projet eux-mĂȘmes, pousser sur leur copie personnelle et fournir leur contribution au dĂ©pĂŽt originel en crĂ©ant une requĂȘte de tirage (Pull Request), concept qui sera abordĂ© par la suite. Ceci ouvre un fil de discussion avec possibilitĂ© de revue de code, pour que le propriĂ©taire et le contributeur puissent discuter et modifier le code proposĂ© jusquâĂ ce que le propriĂ©taire soit satisfait du rĂ©sultat et le fusionne dans son dĂ©pĂŽt.
Pour dupliquer un projet, visitez la page du projet et cliquez sur le bouton « Fork » en haut à droite de la page.
Quelques secondes plus tard, vous serez redirigé vers la page de votre nouveau projet, contenant votre copie modifiable du code.
Processus GitHub
GitHub est construit autour dâune certaine organisation de la collaboration, centrĂ©e autour des requĂȘtes de tirage (Pull Request). Ce processus de travail fonctionne aussi bien avec une petite Ă©quipe soudĂ©e collaborant sur un dĂ©pĂŽt unique partagĂ© quâavec une sociĂ©tĂ© Ă©clatĂ©e Ă travers le monde ou un rĂ©seau dâinconnus contribuant sur un projet au moyen de dizaines de projets dupliquĂ©s. Il est centrĂ© sur le processus de travail par branches thĂ©matiques (voir Les branches thĂ©matiques traitĂ© dans le Les branches avec Git).
Le principe général est le suivant :
-
Duplication du projet.
-
CrĂ©ation dâune branche thĂ©matique Ă partir de la branche
master
, -
validation de quelques améliorations (commit),
-
poussée de la branche thématique sur votre projet GitHub (push),
-
ouverture dâune requĂȘte de tirage sur GitHub (Pull Request),
-
discussion et éventuellement possibilité de nouvelles validations (commit).
-
Le propriĂ©taire du projet fusionne (merge) ou ferme (close) la requĂȘte de tirage.
-
Synchronisation de la branche master mise à jour avec celle de votre propre dépÎt.
Câest essentiellement le processus de gestion par gestionnaire dâintĂ©gration traitĂ© dans Mode du gestionnaire dâintĂ©gration, mais au lieu dâutiliser des courriels pour communiquer et faire une revue des modifications, les Ă©quipes utilisent les outils Web de GitHub.
Détaillons un exemple illustrant une proposition de modification à un projet open-source hébergé sur GitHub.
Astuce
|
Vous pouvez utiliser lâoutil officiel de ligne de commande GitHub CLI au lieu de lâinterface web GitHub pour la plupart des actions. Lâoutil peut ĂȘtre utilisĂ© sous Windows, MacOS et Linux. Rendez-vous sur GitHub CLI homepage pour les instructions dâinstallation et le manuel. |
CrĂ©ation dâune requĂȘte de tirage
Tony recherche un programme à faire tourner sur son micro-contrÎleur Arduino et a trouvé un programme génial sur GitHub à https://github.com/schacon/blink.
Le seul problĂšme est que le clignotement est trop rapide, nous pensons quâil serait mieux dâattendre 3 secondes au lieu dâune entre chaque changement dâĂ©tat. AmĂ©liorons donc le programme et soumettons cette amĂ©lioration au projet initial.
PremiÚrement, nous cliquons sur le bouton « Fork » comme mentionné ci-dessus pour obtenir une copie du projet.
Notre nom dâutilisateur ici est « tonychacon » donc notre copie de ce projet est Ă https://github.com/tonychacon/blink
et câest ici que nous pouvons la modifier.
Nous pouvons aussi la cloner localement, créer une branche thématique, modifier le code et pousser finalement cette modification sur GitHub.
$ git clone https://github.com/tonychacon/blink (1)
Clonage dans 'blink'...
$ cd blink
$ git checkout -b slow-blink (2)
Switched to a new branch 'slow-blink'
$ sed -i '' 's/1000/3000/' blink.ino # (MacOSX) (3)
# Si vous ĂȘtes sur un systĂšme Linux, faites plutĂŽt ceci :
# $ sed -i 's/1000/3000/' blink.ino (3)
$ git diff --word-diff (4)
diff --git a/blink.ino b/blink.ino
index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
[-delay(1000);-]{+delay(3000);+} // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
[-delay(1000);-]{+delay(3000);+} // wait for a second
}
$ git commit -a -m 'three seconds is better' (5)
[master 5ca509d] three seconds is better
1 file changed, 2 insertions(+), 2 deletions(-)
$ git push origin slow-blink (6)
Username for 'https://github.com': tonychacon
Password for 'https://tonychacon@github.com':
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/tonychacon/blink
* [new branch] slow-blink -> slow-blink
-
Clone notre copie du projet localement
-
Crée un branche thématique avec un nom descriptif
-
Modifie le code
-
VĂ©rifie si la modification est bonne
-
Valide les modifications dans la branche thématique
-
Pousse notre branche thématique sur notre dépÎt dupliqué GitHub
Maintenant, si nous allons sur notre projet dupliquĂ© sur GitHub, nous pouvons voir que GitHub a remarquĂ© que nous avons poussĂ© une nouvelle branche thĂ©matique et affiche un gros bouton vert pour vĂ©rifier nos modifications et ouvrir une requĂȘte de tirage sur le projet original.
Vous pouvez aussi vous rendre à la page « Branches » à https://github.com/<utilisateur>/<projet>/branches
pour trouver votre branche et ouvrir une requĂȘte de tirage Ă partir de lĂ .
Si nous cliquons sur le bouton vert, une fenĂȘtre nous permet de crĂ©er un titre et une description de la modification que nous souhaitons faire intĂ©grer pour que le propriĂ©taire du projet trouve une bonne raison de la prendre en considĂ©ration. Câest gĂ©nĂ©ralement une bonne idĂ©e de passer un peu de temps Ă Ă©crire une description aussi argumentĂ©e que possible pour que le propriĂ©taire sache pourquoi la modification est proposĂ©e et en quoi elle apporterait une amĂ©lioration au projet.
Nous voyons aussi une liste de soumissions (commits) dans notre branche thématique qui sont « en avance » (ahead) par rapport à la branche master
(ici, un seul uniquement) et une visualisation unifiée de toutes les modifications (unified diff) qui seraient intégrées en cas de fusion.
Quand vous cliquez sur le bouton « Create pull request » sur cet Ă©cran, le propriĂ©taire du projet que vous avez dupliquĂ© reçoit une notification lui indiquant que quelquâun suggĂšre une modification et qui renvoie Ă la page contenant toutes les informations correspondantes.
Note
|
Bien que les requĂȘtes de tirage soient souvent utilisĂ©es de cette façon pour des projets publics quand un contributeur propose une modification complĂšte, elles sont aussi souvent utilisĂ©es dans les projets internes au dĂ©but dâun cycle de dĂ©veloppement. Comme on peut continuer Ă pousser sur la branche thĂ©matique mĂȘme aprĂšs lâouverture de la requĂȘte de tirage, on ouvre une requĂȘte de tirage trĂšs tĂŽt et cela permet de travailler en Ă©quipe dans un contexte, plutĂŽt que de lâouvrir Ă la toute fin du processus. |
ItĂ©rations sur une requĂȘte de tirage
Ă prĂ©sent, le propriĂ©taire du projet peut regarder les modifications suggĂ©rĂ©es et les fusionner ou les rejeter ou encore les commenter. Supposons quâil apprĂ©cie lâidĂ©e mais prĂ©fĂ©rerait un temps dâextinction de la lumiĂšre lĂ©gĂšrement plus long que le temps dâallumage.
Alors que cette conversation a lieu par échange de courriel dans les flux de travail présentés dans Git distribué, ici elle a lieu en ligne sur GitHub. Le propriétaire du projet peut faire une revue des différences en vue unifiées et laisser un commentaire en cliquant sur une des lignes.
Une fois que le mainteneur a commentĂ©, la personne qui a ouvert la requĂȘte de tirage (et en fait toute personne surveillant le dĂ©pĂŽt) recevra une notification. Nous verrons comment personnaliser ce comportement plus tard, mais si la notification par courriel est activĂ©e, Tony recevra un courriel comme celui-ci :
Nâimporte qui peut aussi laisser un commentaire global sur la requĂȘte de tirage. Sur Page de discussion dâune requĂȘte de tirage, nous pouvons voir un exemple oĂč le propriĂ©taire du projet commente une ligne de code puis laisse un commentaire gĂ©nĂ©ral dans la section de discussion. Vous pouvez voir que les commentaires de code sont aussi publiĂ©s dans la conversation.
Maintenant, le contributeur sait ce quâil doit faire pour que ses modifications soient intĂ©grĂ©es. Heureusement, ici câest une chose facile Ă faire. Alors que par courriel, il faudrait retravailler les sĂ©ries de commit et les soumettre Ă nouveau Ă la liste de diffusion, avec GitHub il suffit de soumettre les correctifs sur la branche thĂ©matique et de la repousser.
Le propriĂ©taire du projet sera notifiĂ© Ă nouveau des modifications du contributeur et pourra voir que les problĂšmes ont Ă©tĂ© rĂ©glĂ©s quand il visitera la page de la requĂȘte de tirage. En fait, comme la ligne de code initialement commentĂ©e a Ă©tĂ© modifiĂ©e entre temps, GitHub le remarque et fait disparaĂźtre la diffĂ©rence obsolĂšte.
Un point intĂ©ressant Ă noter est que si vous cliquez sur lâonglet « Files Changed » (fichiers modifiĂ©s), vous obtenez la diffĂ©rence sous forme unifiĂ©eâââcâest-Ă -dire la diffĂ©rence totalement agrĂ©gĂ©e qui serait introduite dans votre branche principale si cette branche thĂ©matique Ă©tait fusionnĂ©e.
En Ă©quivalent git diff
, cela montre automatiquement la mĂȘme chose que la commande git diff masterâŠâ<branche>
pour la branche sur laquelle vous avez ouvert la requĂȘte de tirage.
RĂ©fĂ©rez-vous Ă DĂ©terminer les modifications introduites pour plus dâinformations sur ce type de diffĂ©rence.
Lâautre point Ă noter est que GitHub vĂ©rifie si la requĂȘte de tirage peut ĂȘtre fusionnĂ©e proprement et fournit un bouton pour rĂ©aliser la fusion sur le serveur. Ce bouton nâapparaĂźt que si vous avez accĂšs en Ă©criture au dĂ©pĂŽt et si une fusion peut sâeffectuer simplement. Si vous cliquez dessus, GitHub rĂ©alise une fusion sans avance rapide (non-fast-forward), ce qui signifie que mĂȘme si la fusion pouvait se faire en avance rapide (fast-forward), il va tout de mĂȘme crĂ©er une soumission de fusion (merge commit).
Si vous préférez, vous pouvez simplement tirer la branche et la fusionner localement.
Si vous fusionnez cette branche dans master
et poussez le tout sur GitHub, la requĂȘte de tirage sera fermĂ©e automatiquement.
Câest le processus de travail de base que la plupart des projets GitHub utilisent. Des branches thĂ©matiques sont crĂ©Ă©es, des requĂȘtes de tirage sont ouvertes dessus, une discussion sâengage, du travail additionnel peut ĂȘtre ajoutĂ© sur la branche et Ă la fin, la requĂȘte est soit fermĂ©e, soit fusionnĂ©e.
Note
|
Pas seulement avec des dépÎts dupliqués
Il est important de noter que vous pouvez aussi ouvrir une requĂȘte de tirage entre deux branches du mĂȘme dĂ©pĂŽt.
Si vous travaillez sur une fonctionnalitĂ© avec quelquâun et que vous avez tous deux accĂšs en Ă©criture au projet, vous pouvez pousser une branche thĂ©matique sur le dĂ©pĂŽt et ouvrir une requĂȘte de tirage dessus vers la branche |
RequĂȘtes de tirage avancĂ©es
AprĂšs avoir prĂ©sentĂ© les bases de la contribution Ă un projet sur GitHub, voyons quelques trucs et astuces concernant les requĂȘtes de tirage afin dâamĂ©liorer votre efficacitĂ© .
RequĂȘtes de tirage comme patchs
Il est important de comprendre que pour de nombreux projets, les requĂȘtes de tirage ne sont pas vues comme des files dâattente de patchs parfaits qui doivent sâappliquer correctement dans lâordre, comme le conçoivent la plupart des projets basĂ©s sur des listes de diffusion qui fonctionnent par sĂ©rie de patchs envoyĂ©s par courriel. La plupart des projets GitHub voient les branches de requĂȘte de tirage comme des conversations itĂ©ratives autour dâune modification proposĂ©e, aboutissant Ă une diffĂ©rence unifiĂ©e qui est appliquĂ©e par fusion.
Câest une distinction importante, car gĂ©nĂ©ralement la modification est soumise Ă revue avant que le code ne soit considĂ©rĂ© comme parfait, ce qui est bien plus rare avec les contributions par sĂ©rie de patchs envoyĂ©es sur une liste de diffusion. Cela permet une conversation prĂ©coce avec les mainteneurs de sorte que lâon atteint une solution correcte par un travail plus collectif. Quand du code est proposĂ© par requĂȘte de tirage et que les mainteneurs ou la communautĂ© suggĂšrent une modification, la sĂ©rie de patchs nâest gĂ©nĂ©ralement pas rĂ©gĂ©nĂ©rĂ©e mais la diffĂ©rence est poussĂ©e comme nouvelle soumission (commit) Ă la branche, permettant ainsi dâavancer dans la discussion, tout en conservant intact le contexte du travail passĂ©.
Par exemple, si vous regardez Ă nouveau la figure RequĂȘte de tirage finale, vous noterez que le contributeur nâa pas rebasĂ© sa soumission et envoyĂ© une nouvelle requĂȘte de tirage. Au lieu de cela, il a ajoutĂ© de nouvelles soumissions (commit) et les a poussĂ© dans la branche existante. De cette maniĂšre, si on examine cette requĂȘte de tirage dans le futur, on peut aisĂ©ment retrouver la totalitĂ© du contexte qui a amenĂ© aux dĂ©cisions prises. Lâutilisation du bouton « Merge » sur le site crĂ©e Ă dessein un « commit de fusion » (merge) qui rĂ©fĂ©rence la requĂȘte de tirage pour quâil reste facile de revenir sur celle-ci et dây rechercher la discussion originale si nĂ©cessaire.
Se maintenir à jour avec le développement amont
Si votre requĂȘte de tirage devient obsolĂšte ou ne peut plus ĂȘtre fusionnĂ©e proprement, vous voudrez la corriger pour que le mainteneur puisse la fusionner facilement. GitHub testera cela pour vous et vous indique Ă la fin de la requĂȘte de tirage si la fusion automatique est possible ou non.
Si vous voyez quelque chose comme sur la figure La requĂȘte de tirage ne peut pas ĂȘtre fusionnĂ©e proprement, vous voudrez corriger votre branche pour quâelle ait un statut vert et que le mainteneur nâait pas Ă fournir de travail supplĂ©mentaire.
Vous avez deux options.
Vous pouvez soit rebaser votre branche sur le sommet de la branche cible (normalement, la branche master
du dépÎt que vous avez dupliqué), soit fusionner la branche cible dans votre branche.
La plupart des dĂ©veloppeurs sur GitHub choisiront cette derniĂšre option, pour la mĂȘme raison que celle citĂ©e Ă la section prĂ©cĂ©dente. Ce qui importe est lâhistorique et la fusion finale, donc le rebasage nâapporte pas beaucoup plus quâun historique lĂ©gĂšrement plus propre avec en prime une plus grande difficultĂ© dâapplication et lâintroduction possible dâerreurs.
Si vous voulez fusionner la branche cible pour rendre votre requĂȘte de tirage fusionnable, vous ajouterez le dĂ©pĂŽt original comme nouveau dĂ©pĂŽt distant, rĂ©cupĂ©rerez la branche cible que vous fusionnerez dans votre branche thĂ©matique, corrigerez les erreurs et finalement pousserez la branche thĂ©matique sur la mĂȘme branche thĂ©matique pour laquelle vous avez ouvert la requĂȘte de tirage.
Par exemple, considĂ©rons que dans lâexemple « tonychacon » que nous avons utilisĂ©, lâauteur original a fait des modifications qui crĂ©ent un conflit dans la requĂȘte de tirage. Examinons ces Ă©tapes.
$ git remote add upstream https://github.com/schacon/blink (1)
$ git fetch upstream (2)
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From https://github.com/schacon/blink
* [new branch] master -> upstream/master
$ git merge upstream/master (3)
Auto-merging blink.ino
CONFLICT (content): Merge conflict in blink.ino
Automatic merge failed; fix conflicts and then commit the result.
$ vim blink.ino (4)
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
into slower-blink
$ git push origin slow-blink (5)
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/tonychacon/blink
ef4725c..3c8d735 slower-blink -> slow-blink
-
Ajoute le dépÎt original comme dépÎt distant sous le nom « upstream ».
-
RécupÚre les derniers travaux depuis ce dépÎt distant.
-
Fusionne la branche principale dans la branche thématique.
-
Corrige le conflit créé.
-
Pousse sur la mĂȘme branche thĂ©matique.
Quand vous faites cela, la requĂȘte de tirage est automatiquement mise Ă jour et un nouveau contrĂŽle est effectuĂ© pour vĂ©rifier la possibilitĂ© de fusion.
Une des grandes forces de Git est que vous pouvez faire ceci rĂ©guliĂšrement. Si vous avez un projet Ă trĂšs long terme, vous pouvez facilement fusionner depuis la branche cible de nombreuses fois et nâavoir Ă gĂ©rer que les conflits apparus depuis la derniĂšre fusion, rendant ainsi le processus rĂ©alisable.
Si vous souhaitez absolument rebaser la branche pour la nettoyer, vous pouvez toujours le faire, mais il vaut mieux ne pas pousser en forçant sur la branche sur laquelle la requĂȘte de tirage est dĂ©jĂ ouverte. Si dâautres personnes lâont dĂ©jĂ tirĂ©e et ont travaillĂ© dessus, vous vous exposez aux problĂšmes dĂ©crits dans Les dangers du rebasage. Ă la place, poussez cette branche rebasĂ©e vers une nouvelle branche sur GitHub et ouvrez une nouvelle requĂȘte de tirage qui rĂ©fĂ©rence lâancienne requĂȘte, puis fermez lâoriginale.
Références
Votre prochaine question pourrait ĂȘtre : « Comment faire pour rĂ©fĂ©rencer lâancienne requĂȘte de tirage ? ». En fait, il y a de trĂšs trĂšs nombreuses maniĂšres de faire rĂ©fĂ©rence Ă dâautres choses dans GitHub depuis Ă peu prĂšs toutes les zones textuelles.
Commençons par la maniĂšre de faire rĂ©fĂ©rence Ă une autre requĂȘte de tirage ou Ă une anomalie (Issue).
Toutes les requĂȘtes de tirage et toutes les anomalies sont identifiĂ©es par des numĂ©ros qui sont uniques au sein dâun projet.
Par exemple, vous ne pouvez avoir une requĂȘte de tirage numĂ©ro 3 et une anomalie numĂ©ro 3.
Si vous voulez faire rĂ©fĂ©rence Ă nâimporte quelle requĂȘte de tirage ou anomalie depuis lâune ou lâautre du mĂȘme projet, il vous suffit dâinsĂ©rer #<numĂ©ro>
dans nâimporte quel commentaire ou nâimporte quelle description.
Vous pouvez aussi rĂ©fĂ©rencer une requĂȘte ou une anomalie dâun autre dĂ©pĂŽt dupliquĂ© du dĂ©pĂŽt actuel en utilisant la syntaxe <utilisateur>#<numĂ©ro>
, ou mĂȘme un autre dĂ©pĂŽt indĂ©pendant avec la syntaxe <utilisateur>/<dĂ©pĂŽt>#<numĂ©ro>
.
Voyons cela sur un exemple. Disons que nous avons rebasĂ© la branche de lâexemple prĂ©cĂ©dent, crĂ©Ă© une nouvelle requĂȘte de tirage et nous souhaitons maintenant faire rĂ©fĂ©rence Ă lâancienne requĂȘte de tirage depuis la nouvelle. Nous souhaitons aussi faire rĂ©fĂ©rence Ă une anomalie dans un dĂ©pĂŽt dupliquĂ© de celui-ci et Ă une anomalie soumise dans un projet complĂštement diffĂ©rent. Nous pouvons saisir une description comme sur la figure RĂ©fĂ©rences croisĂ©es dans une requĂȘte de tirage..
Quand nous soumettons cette requĂȘte de tirage, nous voyons tout ceci mis en forme comme sur la figure RĂ©fĂ©rences croisĂ©es mises en forme dans une requĂȘte de tirage..
Notez bien que lâURL GitHub complĂšte que nous avons indiquĂ©e a Ă©tĂ© raccourcie pour ne contenir que lâinformation nĂ©cessaire.
Ă prĂ©sent, si Tony retourne sur la requĂȘte de tirage originale et la ferme, nous pouvons voir que du fait de son rĂ©fĂ©rencement dans la nouvelle, GitHub a crĂ©Ă© automatiquement un Ă©vĂ©nement de suivi dans le journal de la nouvelle requĂȘte de tirage. Cela signifie quâune personne qui visitera cette requĂȘte de tirage et verra quâelle est fermĂ©e, pourra facilement se rendre sur celle qui lâa remplacĂ©e. Le lien ressemblera Ă quelque chose comme sur la figure RĂ©fĂ©rences croisĂ©e dans une requĂȘte de tirage fermĂ©e..
En plus des numĂ©ros dâanomalies, vous pouvez aussi faire rĂ©fĂ©rence Ă une soumission (commit) spĂ©cifique par son SHA-1. Vous devez spĂ©cifier la totalitĂ© des 40 caractĂšres du SHA-1, mais si GitHub rencontre cette chaĂźne, il crĂ©era un lien direct vers la soumission. Vous pouvez aussi faire rĂ©fĂ©rence Ă des commits dans des dĂ©pĂŽts dupliquĂ©s ou dâautres dĂ©pĂŽts de la mĂȘme maniĂšre que nous lâavons fait pour les anomalies.
Markdown, saveur GitHub
Faire des liens vers les autres anomalies nâest que le dĂ©but des choses intĂ©ressantes que vous pouvez faire dans presque toutes les boĂźtes de saisie dans GitHub. Dans les descriptions dâanomalies et de requĂȘtes de tirage, les commentaires, les commentaires de code et plus, vous pouvez utiliser ce quâon appelle le « Markdown, saveur GitHub » (GitHub Flavored Markdown). Markdown, câest comme Ă©crire du texte simple mais celui-ci est rendu plus richement.
RĂ©fĂ©rez-vous Ă lâexemple sur la figure Un exemple de Markdown Ă©crit et rendu. pour savoir comment les commentaires ou le texte peuvent ĂȘtre Ă©crits puis rendus en utilisant Markdown.
La saveur GitHub de Markdown permet de rĂ©aliser encore plus de choses au-delĂ de la syntaxe Markdown basique. Celles-ci peuvent ĂȘtre vraiment utiles pour la crĂ©ation de requĂȘtes de tirage, de commentaires dâanomalies ou de descriptions.
Listes de tĂąches
La premiĂšre spĂ©cificitĂ© vraiment utile du Markdown de GitHub, particuliĂšrement dans le cadre de requĂȘtes de tirage, est la crĂ©ation de listes de tĂąches. Une liste de tĂąches est une liste de cases Ă cocher pour chaque action Ă accomplir. Dans une anomalie ou une requĂȘte de tirage, cela indique les choses qui doit ĂȘtre faites avant de pouvoir considĂ©rer lâĂ©lĂ©ment comme fermĂ©.
Vous pouvez créer une liste de tùches comme ceci :
- [X] Ăcrire le code
- [ ] Ăcrire tous les tests
- [ ] Documenter le code
Si nous incluons ceci dans la description de notre requĂȘte de tirage ou de notre anomalie, nous le verrons rendu comme sur la figure Rendu dâune liste de tĂąches dans un commentaire Markdown.
Câest trĂšs utilisĂ© dans les requĂȘtes de tirage pour indiquer tout ce que vous souhaitez voir accompli sur la branche avant que la requĂȘte de tirage ne soit prĂȘte Ă ĂȘtre fusionnĂ©e. Le truc vraiment cool est que vous pouvez simplement cliquer sur les cases Ă cocher pour mettre Ă jour le commentaireâââil est inutile de modifier directement le Markdown pour cocher les cases.
De plus, GitHub surveille la prĂ©sence de listes de tĂąches dans vos anomalies et vos requĂȘtes de tirage et les affiche comme mĂ©tadonnĂ©es sur les pages qui en donnent la liste. Par exemple, si vous avez une requĂȘte de tirage contenant des tĂąches et que vous regardez la page de rĂ©sumĂ© de toutes les requĂȘtes de tirage, vous pouvez y voir lâĂ©tat dâavancement. Cela aide les gens Ă dĂ©couper les requĂȘtes de tirage en sous-tĂąches et aide les autres personnes Ă suivre le progrĂšs sur la branche. Vous pouvez voir un exemple de cette fonctionnalitĂ© sur la figure RĂ©sumĂ© de listes de tĂąches dans la liste des requĂȘtes de tirage..
Câest incroyablement utile quand vous ouvrez tĂŽt une requĂȘte de tirage et les utilisez pour suivre votre progrĂšs au cours du dĂ©veloppement de la fonctionnalitĂ©.
Extraits de code
Vous pouvez aussi ajouter des extraits de code dans les commentaires. Câest particuliĂšrement utile si vous souhaitez montrer quelque chose que vous pourriez essayer de faire avant de les dĂ©velopper rĂ©ellement dans votre branche sous la forme dâune soumission. Câest aussi souvent utilisĂ© pour ajouter un exemple de code de ce qui ne fonctionne pas ou de ce que cette requĂȘte de tirage pourrait mettre en Ćuvre.
Pour ajouter un extrait de code, vous devez le délimiter par des guillemets simples inversés.
```java
for(int i=0 ; i < 5 ; i++)
{
System.out.println("i is : " + i);
}
```
Si de plus vous ajoutez un nom de langage comme nous lâavons fait avec 'java', GitHub essaye de colorer syntaxiquement lâextrait. Dans le cas ci-dessus, cela donnerait le rendu sur la figure Exemple de rendu dâun code dĂ©limitĂ©.
Citation
Si vous rĂ©pondez Ă une petite partie dâun long commentaire, vous pouvez citer la partie concernĂ©e de lâautre commentaire de maniĂšre sĂ©lective en faisant prĂ©cĂ©der chaque ligne par le caractĂšre >
.
En rĂ©alitĂ©, câest mĂȘme tellement courant et utile quâil existe un raccourci clavier pour cela.
Si vous sélectionnez un texte dans un commentaire auquel vous voulez directement répondre et que vous appuyez sur la touche r
, ce texte sera automatiquement cité pour vous dans votre boßte de commentaire.
Les citations ressemblent à quelque chose comme ça :
> Whether 'tis Nobler in the mind to suffer
> The Slings and Arrows of outrageous Fortune,
How big are these slings and in particular, these arrows?
Une fois rendu, le commentaire ressemble Ă quelque chose comme sur la figure Exemple de rendu de citation.
ĂmoticĂŽne (Emoji)
Enfin, vous pouvez Ă©galement utiliser des Ă©moticĂŽnes dans vos commentaires.
Câest en rĂ©alitĂ© utilisĂ© assez largement dans les commentaires que vous pouvez voir pour de nombreuses anomalies et requĂȘtes de tirage GitHub.
Il existe mĂȘme un assistant pour Ă©moticĂŽnes dans GitHub.
Lorsque vous saisissez un commentaire et que vous commencez Ă saisir le caractĂšre :
, un outil pour lâauto-complĂ©tion vous aide Ă trouver ce que vous recherchez.
Les Ă©moticĂŽnes apparaissent sous la forme :<nom>:
nâimporte oĂč dans le commentaire.
Par exemple, vous pourriez écrire quelque chose comme cela :
I :eyes: that :bug: and I :cold_sweat:.
:trophy: for :microscope: it.
:+1: and :sparkles: on this :ship:, it's :fire::poop:!
:clap::tada::panda_face:
Une fois rendu, cela ressemblerait à quelque chose comme sur la figure Commentaire trÚs chargé en émoticÎnes..
Bien que cela ne soit pas indispensable, cela ajoute une touche dâhumour et dâĂ©motion Ă un moyen de communication avec lequel il est difficile de transmettre des Ă©motions.
Note
|
Il y a en fait un assez grand nombre de services Web qui emploient maintenant des Ă©moticĂŽnes. Un formidable aide mĂ©moire de rĂ©fĂ©rence pour trouver des Ă©moticĂŽnes qui expriment ce que vous souhaitez dire peut ĂȘtre trouvĂ© ici : |
Images
Ce nâest pas Ă proprement parler du Markdown, saveur GitHub, mais câest incroyablement utile. En plus de lâajout de liens images aux commentaires (dont il peut ĂȘtre difficile de trouver et dâintĂ©grer les URL), GitHub vous permet de faire un glisser-dĂ©poser de vos images sur les zones de texte pour les intĂ©grer.
Si vous regardez Ă nouveau lâimage RĂ©fĂ©rences croisĂ©es dans une requĂȘte de tirage., vous y verrez une petite indication ``Parsed as Markdown'' (Traitement Markdown) en haut de la zone de texte. En cliquant dessus, vous serez redirigĂ© vers une page (en anglais) affichant un aide-mĂ©moire de rĂ©fĂ©rence vous rĂ©sumant tout ce que vous pouvez faire avec Markdown sur GitHub.
Garder votre dépÎt GitHub public à jour
Une fois que vous avez dupliquĂ© un dĂ©pĂŽt GitHub, votre dĂ©pĂŽt (votre « copie ») existe indĂ©pendamment de lâoriginal. En particulier, lorsque le dĂ©pĂŽt original a de nouveaux commits, GitHub vous en informe avec un message comme :
This branch is 5 commits behind progit:master.
Mais votre dĂ©pĂŽt GitHub ne sera jamais mis Ă jour automatiquement par GitHub ; câest quelque chose que vous devez faire vous-mĂȘme. Heureusement, cela est trĂšs facile Ă faire.
Une possibilité pour faire ça ne requiert aucune configuration.
Par exemple, si vous avez dupliqué depuis https://github.com/progit/progit2-fr.git
, vous pouvez garder votre branche master
à jour comme ceci :
$ git checkout master (1)
$ git pull https://github.com/progit/progit2-fr.git (2)
$ git push origin master (3)
-
Si vous Ă©tiez sur une autre branche, basculer sur
master
. -
Récupérer les modifications depuis
https://github.com/progit/progit2-fr.git
et les fusionner dansmaster
. -
Pousser votre branche
master
surorigin
.
Cela fonctionne, mais câest un peu fastidieux dâavoir Ă Ă©peler lâURL de rĂ©cupĂ©ration Ă chaque fois. Vous pouvez automatiser ce travail avec un peu de configuration :
$ git remote add progit https://github.com/progit/progit2-fr.git (1)
$ git branch --set-upstream-to=progit/master master (2)
$ git config --local remote.pushDefault origin (3)
-
Ajouter le dĂ©pĂŽt source et lui donner un nom. Ici, jâai choisi de lâappeler
progit
. -
Paramétrer votre branche
master
pour suivre la branchemaster
du dépÎt distantprogit
. -
Définir le dépÎt de poussée par défaut comme étant
origin
.
Une fois que cela est fait, le flux de travail devient beaucoup plus simple :
$ git checkout master (1)
$ git pull (2)
$ git push (3)
-
Si vous Ă©tiez sur une autre branche, basculer sur
master
. -
Récupérer les modifications depuis
progit
et les fusionner dansmaster
. -
Pousser votre branche
master
surorigin
.
Cette approche peut ĂȘtre utile, mais elle nâest pas sans inconvĂ©nient.
Git fera ce travail pour vous gaiement et silencieusement, mais il ne vous avertira pas si vous faites un commit sur master
, tirez et fusionnez depuis progit
, puis poussez sur origin
âââtoutes ces opĂ©rations sont valides dans cette configuration.
Vous devrez donc prendre garde Ă ne jamais faire de commit directement sur master
, puisque cette branche appartient effectivement au dépÎt en amont.