Discussion :

[azerzen]

Bonjour à tous,
Je suis nouveau en développement C++ et j'utilise GIT mais je me mélange les pinces.
Voilà mon problème, je ne sais pas comment gérer quand j'ai différentes versions. Par exemple, j'ai fait une grosse MAJ de mon interface graphique et ça sera pas forcément distribué à tous les clients.
Donc pour l'instant j'ai un dossier par version car je ne suis pas sûr de moi mais j'aimerais utiliser les possibilités de GIT pour faire les choses bien.
Du coup, comment vous faites quand vous avez différentes versions du même logiciel avec GIT?
Merci pour vos retours.
Azerzen

[Obsidian]

Bonjour et bienvenue,
En effet, il te faut un logiciel de versioning (préférablement Git, en ce qui me concerne) et c'est le bon moment pour s'y mettre.

Tu peux déjà jeter un œil à la FAQ Git : https://alm.developpez.com/faq/git/
Ainsi qu'à : https://djibril.developpez.com/tutor...marrage-rapide

Du coup, comment vous faites quand vous avez différentes versions du même logiciel avec GIT?

Pour faire court, avec tous les logiciels de versioning depuis au moins RCS en 1982, on développe sur au moins une « branche », qui est en fait l'historique de chaque modification apportée à ton dépôt. En général on la représente à peu près comme ça dans le temps :

  ↑
  o 07/01/2021 Début de la phase de débogage
  | 
  o 06/01/2021 Suite de la rédaction du module concerné…
  | 
  o 05/01/2021 Début de la rédaction du prochain module
  | 
  o 04/01/2021 <V1.0> Release client de la version 1.0 - version stable
  | 
  o 03/01/2021 Correction d'un bug signalé sur une classe en particulier
  | 
  o 02/01/2021 Ajout d'un module supplémentaire
  | 
  o 01/01/2021 Commit initial : enregistrement de l'état du projet

C'est donc le logiciel lui-même qui va se charger d'enregistrer pour toi les différentes versions de ton projet à chaque fois que tu vas lui demander (plutôt que créer plusieurs dossiers parallèles).

Pour ce faire, il va « suivre » l'état des fichiers que tu auras ajouté à la liste (le fameux index, avec git add). Lorsque tu auras besoin de changer de version, il va remplacer dans ton répertoire de travail tous les fichiers indiqués par ceux correspondant à ta version et laisser inchangés les autres.

L'idée première est donc de faire avancer le projet de quelques pas, d'atteindre quelque chose de suffisamment stable, d'enregistrer cet état comme une version auprès de Git, puis de poursuivre le travail. Lorsque l'on atteint un état particulier ou remarquable, il est possible d'ajouter des « étiquettes » (ou tags) à certaines versions. Ces étiquettes y resteront associées et cela permettra de les retrouver facilement ensuite. Dans l'exemple ci-dessus, on a posé une étiquette nommée « V1.0 » pour la retrouver facilement et savoir ce que l'on doit déployer en clientèle, par exemple.

Ensuite, en TRÈS résumé :

• git add pour sélectionner des nouveautés à intégrer au prochain commit (parce que l'on est pas obligé d'enregistrer l'état de tout le dépôt à chaque fois) ;
• git commit pour enregistrer tout ce que l'on vient de sélectionner. Cela donnera naissance à une nouvelle étape sur la branche décrite ci-dessus ;
• git checkout pour se promener sur la branche et ramener le répertoire de travail à ce qu'il était à une version donnée de cette branche.

Après cela, il est possible de développer plusieurs branches :

  ↑
  o
  |
  o
  | ↑
  o o 04/01/2021 Débogage et préparatifs pour intégration
  | |
  o o 03/01/2021 Poursuite du développement de la fonctionnalité annexe
  | |
  o o 02/01/2021 Développement d'une fonctionnalité annexe pas encore prête, à intégrer plus tard dans la branche principale
  |/
  o 02/01/2021 Ajout d'un module supplémentaire
  |
  o 01/01/2021 Commit initial : enregistrement de l'état du projet

Voilà pour le principe.
Je te suggère de commencer à t'entraîner un peu avec avant que l'on développe les concepts sous-jacents.