Instructions de Travail sur les Tickets

Ce document présente la procédure à suivre lors de la création et de la gestion des tickets de développement. Veuillez suivre chaque étape avec attention.

1. Création du Ticket

Titre du Ticket

Le titre doit décrire de manière générale la tâche à réaliser. Soyez précis, mais sans entrer dans les détails techniques. Par exemple :

Ajout d'une nouvelle fonctionnalité de recherche dans l'application

Correction du bug d'affichage sur la page d'accueil

Description du Ticket

La description doit fournir une explication légèrement détaillée des tâches à réaliser. Elle doit inclure les éléments suivants :

Objectif global de la tâche

Étapes spécifiques ou parties du projet concernées

Comportement attendu une fois la tâche accomplie

2. Création de la Branche

Lorsque vous commencez à travailler sur un ticket, créez une nouvelle branche avec un nom particulier qui reflète le ticket en cours. Le format de la branche doit être :

nom-de-la-feature-#numeroduticket

Pour créer une branche :

git checkout -b feature-recherche-#123

3. Commit des Changements

Les commits doivent suivre la convention suivante :

• Le message de commit doit décrire brièvement le changement effectué.

• À la fin du message de commit, vous devez toujours ajouter le numéro du ticket pour faciliter le suivi des tâches.

Exemple de message de commit :

Ajout du champ de recherche sur la page d'accueil #123

4. Push de la Branche

Après avoir effectué vos changements et effectué vos commits, vous devrez pousser la branche sur le dépôt distant. Lors de votre premier git push, vous recevrez un message pour définir l'upstream de la branche.

Exemple de message affiché :

fatal: The upstream branch 'origin/feature-recherche-#123' does not exist
To push the branch and set the upstream, use the following command:
git push --set-upstream origin nom-de-la-feature-#numero 

Vous devez copier et coller la commande dans votre terminal pour effectuer le push. Une fois cette commande exécutée, votre branche sera poussée vers le dépôt distant.

5. Création d'une Pull Request (PR)

Une fois que vous avez poussé votre branche sur Gitea, vous devez ouvrir une pull request pour demander la révision de votre code.

Voici les étapes pour créer une pull request correctement :

• Allez sur Gitea et naviguez vers le projet concerné.

• Cliquez sur "Branches" et vous devriez voir la branche que vous venez de pousser.

• Cliquez sur le bouton "Create Pull Request" à côté de votre branche.

Remplissez les informations nécessaires :

• Titre de la PR : Utilisez le même titre que celui du ticket.

• Description de la PR : Décrivez brièvement ce que votre PR accomplit. Vous pouvez vous baser sur la description du ticket.

• Revues : Assurez-vous de demander une révision par deux membres de l’équipe.

• Cliquez sur "Create Pull Request" pour soumettre.

Une fois la PR ouverte, vous devrez attendre la révision et l’approbation de l’équipe avant de pouvoir fusionner la branche dans main ou develop selon le flux de travail de votre projet.

Résumé des Commandes Git :

Voici un récapitulatif des commandes Git que vous utiliserez fréquemment :

1. Créer une branche

git checkout -b feature-recherche-#123

2. Ajouter les fichiers modifiés :

git add .
git add *
git add <nom_du_fichier>

3. Commit des changements :

git commit -m "Ajout de [...] #numeroticket"

4. Pousser la branche

git push -set-upstream origin <nom-de-la-branche-#numeroticket>

5. Supprimer une branche

git branch -d <nom_de_la_branche>

Comment fonctionne l’algorithme de victoire (idée générale)

Dans Hex, un joueur gagne s’il existe un chemin continu de ses pions connectant ses deux bords :

PLAYER1 : relier gauche → droite

PLAYER2 : relier haut → bas

Un “chemin” = une suite de cases adjacentes sur la grille hexagonale (6 voisins possibles) appartenant au joueur.

Ce que fait l’algo (principe)

L’algo fait un parcours de graphe (DFS avec une pile, ou BFS avec une file c’est pareil pour le résultat) :

On prend toutes les cases du bord de départ du joueur (ex: bord gauche pour PLAYER1).

On ne garde que celles qui contiennent un pion du joueur.

À partir de ces cases, on explore toutes les cases voisines contenant aussi un pion du joueur, et ainsi de suite.

Si pendant l’exploration on atteint l’autre bord, alors il existe un chemin → victoire.

Pourquoi ça marche ?

Parce que ça revient à demander :

“Est-ce qu’il existe une composante connexe de pions du joueur qui touche les deux bords ?”

Le DFS/BFS explore exactement la composante connexe.

Les 6 voisins en Hex (grille hexagonale)

Dans ton code, tu as :

private static final int[][] NEIGHBORS = { {-1, 0}, {+1, 0}, { 0, -1}, { 0, +1}, {-1, +1}, {+1, -1} };

Ça signifie qu’une case (r,c) a jusqu’à 6 voisins : ''' (r-1,c), (r+1,c) : “haut/bas”

(r,c-1), (r,c+1) : “gauche/droite”

(r-1,c+1) et (r+1,c-1) : les 2 diagonales propres au pavage hexagonal ''' Complexité

Au pire, on visite chaque case une seule fois → O(N²) pour un plateau N×N.

Très correct pour Hex.