Skip to content

Construire des logiciels, ensemble, avec Git 🔗

Préambule : Cet article est la traduction français de « Building software together with Git« , écrit en anglais par le développeur Eliot BERRIOT (qui développe notamment Funkwhale, un serveur de musique moderne auto-hébergé et open-source -licence AGPLv3-, inspiré par Grooveshark. Une version démo est disponible ici).

La traduction française et relecture Ă  Ă©tĂ© rĂ©alisĂ©e par @Alice, @Elanndelh, @Lapineige et @Gordon. Le texte est mis Ă  disposition sous licence Creative Commons CC-0. Vous ĂȘtes encouragé·es Ă  la partager, la traduire, et la rĂ©utiliser. Si la lecture de cet article vous a intĂ©ressĂ©, abonnez-vous au blog de l’auteur via son flux RSS, oui suivez-le sur Mastodon (:


En tant que dĂ©veloppeuses ou dĂ©veloppeurs, nous avons tendance Ă  oublier que nous utilisons un jargon obscur qui nous fait ressembler Ă  d’occultes sorciĂšres ou sorciers. Il peut y avoir une forme d’élitisme derriĂšre cela, bien sĂ»r, mais je pense que cela arrive aussi parce que le dĂ©veloppement logiciel est vraiment un domaine bizarre, avec ses propres problĂ©matiques et solutions. De plus la terminologie obscure dĂ©crit souvent un concept vraiment spĂ©cifique et complexe qu’il serait difficile de dĂ©crire autrement.

Il n’y a pas beaucoup de ressources disponibles en ligne qui introduisent Git, GitHub, le concept de commits, branches, gestion de version, forks, pull requests et autres termes liĂ©s au dĂ©veloppement, qui apparaissent comme du jargon auprĂšs d’une audience non-technique.

Ce texte est une tentative d’amĂ©liorer la situation. Je tiens Ă  remercier vivement @Ginny pour l’idĂ©e originale, @Hush pour la relecture et les corrections, et toutes les personnes qui ont aidĂ© Ă  la rĂ©daction en partageant leurs retours.

đŸ€ Comment collaborons-nous sur du logiciel ?

Comme pour tout projet, un projet de dĂ©veloppement logiciel rencontre plus de succĂšs lorsque de multiples personnes travaillent sur plusieurs tĂąches en parallĂšle. Dans une organisation typique, on s’attend Ă  trouver comptables, gestionnaires, secrĂ©taires, commerciales et commerciaux, et finalement, tout le monde travaille sur ses propres tĂąches en mĂȘme temps, sans problĂšmes. On veut Ă©viter le plus possible les situations oĂč quelqu’un a besoin d’attendre une autre personne pour pouvoir avancer. On appelle ces situations des goulots d’étranglement. Un exemple de tel goulot serait d’avoir un seul tĂ©lĂ©phone dans une entreprise de 100 personnes : tout le monde devrait attendre son tour pour pouvoir passer un appel, ce qui serait une perte de temps.

Le dĂ©veloppement logiciel fonctionne de maniĂšre semblable : des dĂ©veloppeur·ses, graphistes, traducteur·ices — quasiment tout le monde — souhaitent travailler sans avoir Ă  se prĂ©occuper du travail des autres, en particulier lorsque le projet grossit et attire des dizaines, voire des centaines, de contributeur·ices. Pour gĂ©rer cela, les personnes impliquĂ©es dans le dĂ©veloppement logiciel se reposent habituellement sur quelques outils et procĂ©dĂ©s que je vais dĂ©crire ci-dessous.

đŸ€” Qu’est-ce qu’un logiciel ?

Ce qu’on appelle logiciel, dans sa forme la plus courante, n’est rien d’autre qu’un ensemble de fichiers texte, Ă©galement appelĂ©e une base de code (ou codebase, en anglais). Ces fichiers texte contiennent des instructions pouvant ĂȘtre exĂ©cutĂ©es par un ordinateur. Oui, le travail de dĂ©veloppement consiste seulement Ă  Ă©crire des choses.

Bien sĂ»r, en tant que dĂ©veloppeuse ou dĂ©veloppeur, vous devez penser Ă  ce que vous Ă©crivez. Comme un·e Ă©crivain·e 😉 . Si vous avez dĂ©jĂ  travaillĂ© sur une thĂšse, ou sur toute forme de rĂ©daction longue, vous avez rencontrĂ© de nombreux problĂšmes rencontrĂ©s lorsque des dĂ©veloppeur·euses cherchent Ă  travailler sur le mĂȘme logiciel.

Lorsque vous ĂȘtes en pleine rĂ©daction, vous aurez besoin assez souvent de :

  • Relecture (Reviewing en anglais) : vous voulez que quelqu’un d’autre lise votre travail, et Ă©ventuellement puisse y faire des corrections ou modifications
  • Collaboration : vous voulez que quelqu’un puisse travailler sur une partie de la documentation, pendant que vous travaillez sur une autre
  • Gestion de versions (Versioning en anglais) : la possibilitĂ© d’accĂ©der Ă  une prĂ©cĂ©dente version du document (par exemple parce que vous avez supprimĂ© quelque chose par accident)

Vous pouvez mettre en place de la relecture et de la collaboration en envoyant par e-mail des copies de votre travail Ă  d’autres personnes, puis en intĂ©grant leurs retours dans votre propre copie, par de simples opĂ©rations de copier-coller. Pour la gestion de versions, les fonctionnalitĂ©s « annuler/refaire » de votre Ă©diteur de texte peuvent aider, de mĂȘme que sauvegarder des copies entiĂšres de votre document sur un autre support de temps Ă  autre.

Cependant, si vous avez dĂ©jĂ  travaillĂ© Ă  plus d’une ou deux personnes sur le mĂȘme document, vous savez que c’est particuliĂšrement pĂ©nible Ă  gĂ©rer, et est source de nombreuses erreurs. Avez-vous vraiment envoyĂ© la derniĂšre version Ă  vos ami·es ? Avez-vous bien intĂ©grĂ© tous leurs retours ? Comment faire pour revenir Ă  la version d’hier de votre travail, alors que la derniĂšre sauvegarde complĂšte date de la semaine derniĂšre ?

Le dĂ©veloppement logiciel rencontre exactement les mĂȘmes problĂšmes. Mais en gĂ©nĂ©ral, il y a encore plus de personnes impliquĂ©es.

Et un jour, linus torvalds crĂ©a git 😉

Git, et les plateformes associĂ©es, telles que GitHub, sont une tentative pour rĂ©soudre les problĂšmes mentionnĂ©s dans la section prĂ©cĂ©dente. Git permet Ă  des personnes de contribuer Ă  une mĂȘme base de code d’une façon saine et efficace. NĂ©anmoins, pour pouvoir le faire, il est nĂ©cessaire de repenser la façon dont on devrait collaborer, et introduire de nouveaux concepts. Tout cela reprĂ©sente du jargon pour toute nouvelle personne, et c’est particuliĂšrement difficile Ă  assimiler, c’est pourquoi je vais tenter de dĂ©mystifier tout ça.

Commits et gestion de version

Au cƓur de Git se trouve un mĂ©canisme permettant de gĂ©rer les versions d’une base de code. (le versioning en anglais)

Chaque version de la base de code est, pour faire simple, un instantanĂ© de la base de code, associĂ© Ă  sa date de crĂ©ation. C’est ce qui donne une gestion de version, parce qu’il est possible de remonter dans le temps, pour retrouver n’importe quel instantanĂ©.

Ces instantanĂ©s sont appelĂ©s commits. Cependant, faire une copie intĂ©grale du projet pour chaque commit nĂ©cessiterait un espace disque phĂ©nomĂ©nal. Git est plus malin que ça 😉, et il fait en sorte de ne stocker que les diffĂ©rences (appelĂ©es diffs) entre chaque commit

💡 Prenons un exemple simple :

  1. Alice débute son projet logiciel, crée un fichier texte contenant 10 lignes, puis crée le premier commit.
  2. 3 jours plus tard, elle modifie la ligne 7, et crée un second commit. Ce dernier contiendra le fait que la ligne 7 a été modifiée.
  3. 5 jours plus tard, elle supprime la ligne 3, et crĂ©e un nouveau commit. Ce commit contiendra le fait qu’une ligne a Ă©tĂ© supprimĂ©e.nenenene

Tous ces commits crĂ©ent un historique de tout ce qui s’est passĂ© sur le projet (on parle de logs) :

  • Jour 1 : Alice a ajoutĂ© 10 lignes
  • Jour 4 : Alice a modifiĂ© la ligne 7
  • Jour 9 : Alice a supprimĂ© la ligne 3

Et si nous voulons revenir au jour 1, il est possible de demander Ă  Git de dĂ©faire les changements du jour 9, puis du jour 4, dans cet ordre, ce qui nous ramĂšnera la base de code telle qu’elle Ă©tait au jour 1. Puis nous pouvons rejouer le commit suivant, celui du jour 4, pour atteindre la version suivante du projet, et enfin rejouer le commit du jour 9 pour obtenir notre derniĂšre version.

Vous vous rappelez sans doute que j’ai mentionnĂ© trois fonctionnalitĂ©s souhaitĂ©es : gestion de version, collaboration et relecture. Les commits nous apportent la gestion de version, mais Ă©galement la possibilitĂ© d’auditer : qui a fait quoi, et quand. Ça apporte un bonus apprĂ©ciable.

Branches et parallélisation

Git Branches – (CC BY 2.5 AU)

Le dixiĂšme jour, Alice dĂ©cide de tenter une expĂ©rience avec quelque chose de nouveau 🆕, mais elle n’est pas certaine que ça fonctionne. Pour commencer Ă  bidouiller son idĂ©e, elle crĂ©e ce que git appelle une branche. Vous pouvez vous reprĂ©senter les branches comme des routes, se sĂ©parant parfois en deux. Au bout du compte, deux routes peuvent se rejoindre, mais ce n’est pas obligatoire.

Dans git, tous les commits se dĂ©roulent sur une branche, par dĂ©faut sur celle nommĂ©e master. Donc, si on se reprĂ©sente l’état actuel du projet avec ça en tĂȘte, voici Ă  quoi ça pourrait ressembler :

| branche master
|
* Commit du jour 1 : Alice a ajouté 10 lignes
|
* Commit du jour 4 : Alice a modifié la ligne 7
|
* Commit du jour 9 : Alice a supprimé la ligne 3

Donc, si Alice crée sa nouvelle branche, nommée expérimentation, à partir de la branche master, cela donne quelque chose comme :

| branche master
|
* Commit du jour 1 : Alice a ajouté 10 lignes
|
* Commit du jour 4 : Alice a modifié la ligne 7
|
* Commit du jour 9 : Alice a supprimé la ligne 3
|
|\
| \
|  | branche expérimentale

La branche master existe toujours, sur la gauche, mais Alice est maintenant en train de travailler sur la branche expérimentale, sur la droite.

Elle est trÚs productive, et crée quelques commits sur cette branche :

| branche master
|
* Commit du jour 1 : Alice a ajouté 10 lignes
|
* Commit du jour 4 : Alice a modifié la ligne 7
|
* Commit du jour 9 : Alice a supprimé la ligne 3
|
|\
| \
|  | branche expérimentale
|  |
|  * Commit du jour 11 : Alice a ajouté 10 nouvelles lignes
|  |
|  * Commit du jour 13 : Alice a modifié les lignes 5 à 9

Puisqu’elle est satisfaite par ses changements, elle dĂ©cide de fusionner (merge, en anglais) la branche expĂ©rimentale au sein de la branche master.

C’est la façon de git d’appliquer les changements d’une branche sur une autre. Vous vous rappelez de l’analogie des routes que j’ai faite ? C’est comme ça qu’une fusion peut ĂȘtre reprĂ©sentĂ©e :

|    Route principale (branche master)
|
|\   La route se sépare en deux
| \
|  | Route secondaire (branche expérimentale)
|  |
|  |
|  |
|  |
| /
|/   Les deux routes se rejoignent
|
|    La route principale continue son cours

Lorsque la fusion est faite, la branche expérimentale est supprimée, et ses commits sont maintenant présents sur la branche master :

| branche master
|
* Commit du jour 1 : Alice a ajouté 10 lignes
|
* Commit du jour 4 : Alice a modifié la ligne 7
|
* Commit du jour 9 : Alice a supprimé la line 3
|
* Commit du jour 11 : Alice a ajouté 10 nouvelles lignes (depuis la branche expérimentale)
|
* Commit du jour 13 : Alice a modifié les lignes 5 à 9 (depuis la branche expérimentale)

Si, pour une quelconque raison, Alice n’était pas satisfaite par son expĂ©rience, elle aurait pu la supprimer sans la fusionner, et la branche master n’aurait pas Ă©tĂ© affectĂ©e.Les branches sont un concept puissant, mais Ă©galement difficile Ă  apprĂ©hender dans git.

Elles sont utiles pour expérimenter sans risques, mais permettent aussi la collaboration, ce que nous allons voir dans la section suivante.

DĂ©pĂŽts et collaboration

Dans le scĂ©nario prĂ©cĂ©dent, Alice Ă©tait seule. Mais au 14Ăšme jour, son ami Bob vient l’aider sur son nouveau projet đŸ’Ș. Comment cela fonctionne avec git ?

Lorsqu’Alice a commencĂ© Ă  travailler sur le projet, elle utilisait sa propre copie locale, ce que nous appellerons un dĂ©pĂŽt (repository, en anglais). Vous pouvez penser Ă  un dĂ©pĂŽt comme un espace de travail, appartenant Ă  quelqu’un (Alice, dans ce cas).

Vu que Bob veut pouvoir contribuer, il aura besoin de son propre dĂ©pĂŽt. L’une des façons de faire ça est qu’Alice pousse, ou publie (push, en anglais) son dĂ©pĂŽt sur une plateforme telle que GitHub ou GitLab, de demander ensuite Ă  Bob de s’y crĂ©er un compte et d’utiliser le bouton fork. Cette opĂ©ration (fourchage en français, mais on utilise gĂ©nĂ©ralement le terme anglais) consiste simplement Ă  crĂ©er une copie du dĂ©pĂŽt de quelqu’un d’autre.

Git et GitHub ont beau avoir des noms similaires, ce sont des choses trĂšs diffĂ©rentes, et leur diffĂ©rence devient visible dĂšs lors que l’on commence Ă  parler de collaboration. Si je reviens Ă  mon analogie du document texte, git est similaire Ă  un Ă©diteur de texte, comme Microsoft Word ou LibreOffice. C’est un outil que vous installez sur votre ordinateur pour pouvoir travailler sur vos documents (hors-ligne). D’un autre cĂŽtĂ©, GitHub et les plateformes similaires comme GitLab ou Bitbucket sont plus proches de Google Docs : ce sont des services web qui hĂ©bergent votre travail, et le rendent visible et modifiable par d’autres. (en ligne)

Vous n’avez pas besoin d’utiliser GitHub si vous utilisez git, mais les deux tendent Ă  ĂȘtre utilisĂ©s ensemble car ils se complĂštent et ont des objectifs diffĂ©rents.

Lorsque Bob forke le dĂ©pĂŽt d’Alice, sur GitHub, il se retrouve avec une copie exacte de son dĂ©pĂŽt. C’est l’équivalent git d’« envoyer votre thĂšse par e-mail Ă  un·e ami·e ».

Donc, Bob dispose d’un dĂ©pĂŽt fonctionnel, et commence Ă  ajouter ses propres commits sur la branche master :

| Espace de travail de Bob / branche Master
|
| (les précédents commits ont été omis)
|
* Commit du jour 11 : Alice a ajouté 10 nouvelles lignes (depuis la branche expérimentale)
|
* Commit du jour 13 : Alice a modifié les lignes 5 à 9 (depuis la branche expérimentale)
|
* Commit du jour 14 : Bob a modifié la ligne 8
|
* Commit du jour 15 : Bob a supprimé la ligne 12
|

Bob a ajoutĂ© deux commits lors des jours 14 et 15. Il aimerait que cela soit intĂ©grĂ© dans le dĂ©pĂŽt d’Alice. Une façon d’y arriver en utilisant une plateforme telle que GitHub ou GitLab est de crĂ©er une demande d’intĂ©gration (pull request, ou merge request en anglais selon la plateforme). Ces demandes de collaboration sont souvent abrĂ©viĂ©es PRs.

Est-ce que vous vous souvenez quand Alice a fusionnĂ© sa branche expĂ©rimentale dans la branche master dans la section prĂ©cĂ©dente ? Une demande d’intĂ©gration consiste simplement Ă  demander Ă  quelqu’un de fusionner une branche provenant de notre dĂ©pĂŽt, au sein d’une branche sur son dĂ©pĂŽt.

Donc, Bob crĂ©e une demande d’intĂ©gration (Pull Request) :

Bonjour Alice !

J’aimerais fusionner la branche amĂ©liorations de mon dĂ©pĂŽt au sein de la branche master de ton dĂ©pĂŽt.

J’ai crĂ©Ă© un commit qui corrige une faute de frappe, et un autre qui amĂ©liore les performances.

N’hĂ©site pas Ă  me rĂ©pondre si tu as des questions.

Bob

Lorsqu’Alice reçoit cette Pull Request, elle peut relire les commits de Bob (les modifications, ajouts etc.), et dĂ©cider s’ils lui conviennent ou pas. C’est ce que l’on appelle une relecture de code (code review en anglais). Lors de la relecture de code, Alice va lire les changements apportĂ©s par les commits de Bob, y suggĂ©rer des modifications, et lorsqu’elle sera satisfaite du rĂ©sultera, acceptera la Pull Request.

Accepter cette demande fusionnera la branche amĂ©liorations de Bob dans la branche master du dĂ©pĂŽt d’Alice.

| Alice's workspace / master branch
|
| (previous commits ommited)
|
* Commit from day 11: Alice added 10 new lines (from experiment branch)
|
* Commit from day 13: Alice edited lines 5 to 9 (from experiment branch)
|
* Commit from day 14: Bob edited lines 8 (from bob/improvements branch)
|
* Commit from day 15: Bob deleted line 12 (from bob/improvements branch)
|
| Espace de travail d’Alice / branche Master
|
| (les précédents commits ont été omis)
|
* Commit du jour 11 : Alice a ajouté 10 nouvelles lignes (depuis la branche expérimentale)
|
* Commit du jour 13 : Alice a modifié les lignes 5 à 9 (depuis la branche expérimentale)
|
* Commit du jour 14 : Bob a modifié la ligne 8 (depuis la branche bob/améliorations)
|
* Commit du jour 15 : Bob a supprimé la ligne 12 (depuis la branche bob/améliorations)
|

Bien sĂ»r, elle aurait Ă©galement pu refuser la Pull Request, auquel cas sa branche master n’aurait pas Ă©tĂ© modifiĂ©e. Par ailleurs, la branche de Bob et sa Pull Request n’empĂȘchent pas Alice de travailler sur ses propres branches pendant ce temps : elle peut continuer Ă  ajouter des commits sur sa branche master, et ils seraient prĂ©servĂ©s avec la fusion de la branche de Bob dans la sienne.

En utilisant les branches, dĂ©pĂŽts et Pull Requests, Alice et Bob ont rĂ©ussi Ă  collaborer sur le mĂȘme logiciel. C’est gĂ©nial !

Bonus : Conflits, tickets, et versions

Si vous avez tout lu jusqu’ici, les choses devraient ĂȘtre un peu moins effrayantes pour vous. Cependant, il y a plusieurs autres choses Ă  savoir au sujet du dĂ©veloppement logiciel, et sur la façon dont on collabore tout en travaillant sur le logiciel.

Conflits

Dans la terminologie de git, un conflit est une situation oĂč deux changements qui concernent les mĂȘmes lignes du mĂȘme fichier sont faits sur des branches diffĂ©rentes, et que vous essayez de fusionner ces branches.

Examinons une situation typique de conflit :

  • Bob crĂ©e un dĂ©pĂŽt dĂ©rivĂ© de celui d’Alice, comme dĂ©crit dans la section prĂ©cĂ©dente sur le fourchage
  • Bob remarque une coquille quelque part et ajoute un commit Ă  la branche master de son dĂ©pĂŽt pour corriger la coquille. Il oublie d’ouvrir une pull request immĂ©diatement.
  • En mĂȘme temps, Alice remarque la mĂȘme coquille et ajoute un commit Ă  la branche master de son dĂ©pĂŽt pour corriger la coquille.
  • Quelques jours plus tard, Bob se souvient d’ouvrir une pull request pour fusionner sa branche master dans celle d’Alice
  • Malheureusement, puisque la branche master d’Alice a un commit en lien avec la mĂȘme ligne, git ne peut pas faire la fusion automatiquement et se plaindra vertement: « Alice et toi avez Ă©ditĂ© cette ligne en mĂȘme temps, quel changement dois-je garder ? »

En rĂ©sumĂ©, comme dans la vraie vie, les conflits se produisent gĂ©nĂ©ralement quand des gens travaillent exactement sur la mĂȘme chose en mĂȘme temps. Deux personnes qui offrent le mĂȘme livre Ă  une fĂȘte d’anniversaire sont l’équivalent, dans le monde physique, de ce que git appelle un conflit.

Quand ils se produisent, les conflits exigent une rĂ©solution humaine et manuelle. Quelqu’un doit lire et comprendre les deux changements en conflit puis gĂ©nĂ©ralement choisir celui qui a le plus de sens.

Les moyens simples d’éviter les conflits dans git comprennent :

  • La fusion frĂ©quente de vos branches : Plus vous attendez, plus il y a de chance que quelqu’un d’autre ait commitĂ© un changement qui pourrait interfĂ©rer avec votre propre travail
  • La coordination avec les autres personnes qui contribuent : partagez le travail en petites tĂąches indĂ©pendantes, et attribuez ces tĂąches Ă  des personnes prĂ©cises. Les tickets, comme il est mis en Ă©vidence ci-dessous, peuvent aider !

Les conflits ne sont pas toujours un signe d’un manque de coordination, et ils se produiront vraisemblablement de temps Ă  autres dans n’importe quel projet. Cependant, minimiser les situations de conflits est nĂ©cessaire pour rĂ©ussir Ă  parallĂ©liser efficacement votre travail.

Tickets (« issues »)

Les tickets sont une partie importante du dĂ©veloppement logiciel. Vous avez peut-ĂȘtre dĂ©jĂ  entendu ces phrases: « Veuillez ouvrir un ticket » ou « Veuillez ouvrir un bug dans notre outil de suivi des tickets ». Mais qu’est-ce qu’un ticket ?

Les tickets, Ă©galement appelĂ©s « rapports de bugs » ou « demande d’ajout de fonctionnalitĂ© » sont des messages postĂ©s sur l’outil de suivi de tickets d’un projet. Les dĂ©veloppeur·ses, contributeur·ices et utilisateur·ices de logiciel ouvrent gĂ©nĂ©ralement des tickets pour :

  • Garder une trace d’un nouveau bug dans le logiciel
  • SuggĂ©rer une amĂ©lioration ou une nouvelle fonctionnalitĂ©
  • Poser une question sur le comportement du logiciel

Les tickets sont extrĂȘmement utiles, parce qu’ils constituent la mĂ©moire d’un projet, et fournissent aussi un aperçu des dĂ©veloppements futurs, des demandes populaires et des problĂšmes habituels que rencontre une communautĂ©.

Les autres personnes peuvent généralement ajouter des commentaires sur les tickets, discuter des solutions possibles et des écueils à éviter, fournir des solutions de contournement, etc. Quand un développement est nécessaire pour résoudre un ticket ou ajouter une fonctionnalité, un·e développeur·se créera généralement une branche, travaillera sur une solution, puis soumettra une pull request avec les changements. Une fois cette pull request acceptée, le ticket en lien est généralement fermé.

En rĂ©sumĂ©, voici le cycle de vie typique d’un ticket:

  1. Bob rencontre un problĂšme dans le logiciel
  2. Bob ouvre un ticket qui décrit le bug
  3. Maria, qui rencontre le mĂȘme problĂšme, ajoute un commentaire sur le ticket et dĂ©crit une solution possible
  4. Alice décide de travailler sur le ticket
  5. Elle s’attribue la responsabilitĂ© du ticket, crĂ©e une branche, commite les changements qui rĂ©pondent au problĂšme soulevĂ© dans le ticket et ouvre une pull request avec cette branche
  6. La pull request est mergée dans la branche master
  7. Le ticket de Bob est fermé

Au quotidien, les personnes qui contribuent Ă  un projet ont tendance Ă  rĂ©soudre des tickets distincts, pour s’assurer qu’ils ou elles travaillent sur des problĂšmes diffĂ©rents et rĂ©ussir Ă  parallĂ©liser le travail sans conflits.

Vous souvenez-vous du conflit qui s’est produit quand Alice et Bob ont tous deux essayĂ© de corriger la mĂȘme coquille dans le code source ? Si Bob avait ouvert un ticket dĂšs qu’il avait remarquĂ© la coquille, Alice l’aurait remarquĂ© et ils auraient pu dĂ©cider ensemble qui devrait proposer un correctif.

Version (« releases »)

Les versions, également appelées « tags », sont la derniÚre piÚce manquante du processus de développement type. La plupart des projets ont tendance à suivre des cycles similaires :

  1. Les mainteneur·ses du projet ou les communautés choisissent un ensemble de tickets jugés prioritaires
  2. Les contributeur·ices traitent ces tickets
  3. Une fois les tickets sélectionnés traités, une version est publiée
  4. Les utilisateur·ices mettent à jour vers la nouvelle version
  5. Retour Ă  l’étape 1.

Une version est un Ă©tat d’un logiciel qui est distribuĂ© au grand-public et sensĂ© amĂ©liorer ou remplacer les versions prĂ©cĂ©dentes.

Généralement, les versions sont nommées en utilisant un motif précis, comme version 1.2.3, version 1.2.4 et version 1.3.

Conclusion

J’espĂšre que ce texte vous a plu et que les explications vous ont donnĂ© une vue plus claire de ce qui se passe en dĂ©veloppement logiciel.

Il faut quelques efforts pour tout dĂ©mĂȘler et montrer l’utilitĂ© de tout ceci d’une maniĂšre non-technique. Si vous pensez que j’ai Ă©chouĂ© quelque part ou qu’il manque quelque chose, n’hĂ©sitez pas Ă  me le faire savoir !

Liens complémentaires :

Creative Commons License AttributionRepublish
Published inLes Internets

Be First to Comment

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

×

đŸ‡ș🇾 🇬🇧 REPUBLISHING TERMS : You may republish this content online or in print under the Creative Commons license of original content.

đŸ‡ȘđŸ‡ș đŸ‡«đŸ‡·Â  CONDITIONS DE PARTAGE : Vous pouvez republier ce contenu en ligne ou sous forme imprimĂ©e est respectant la licence Creative Commons en vigueur.

 

License

Creative Commons License AttributionCreative Commons Attribution
Construire des logiciels, ensemble, avec Git 🔗