# Passage à Git
## Git c'est quoi ?
Git est de loin le système de contrôle de version le plus largement utilisé aujourd'hui. Git est un projet open source avancé, qui est activement maintenu. À l'origine, il a été développé en 2005 par Linus Torvalds, le créateur bien connu du noyau du système d'exploitation Linux. De plus en plus de projets logiciels reposent sur Git pour le contrôle de version, y compris des projets commerciaux et en open source. Les développeurs qui travaillent avec Git sont bien représentés dans le pool de talents disponible, et la solution fonctionne bien sur une vaste gamme de systèmes d'exploitation et d'environnements de développement intégrés (IDE).
Par sa structure décentralisée, Git illustre parfaitement ce qu'est un système de contrôle de version décentralisé (DVCS). Plutôt que de consacrer un seul emplacement pour l'historique complet des versions du logiciel comme c'était souvent le cas dans les systèmes de contrôle de version ayant fait leur temps, comme CVS et Subversion (également connu sous le nom de SVN), dans Git, chaque copie de travail du code est également un dépôt qui contient l'historique complet de tous les changements.
En plus d'être décentralisé, Git a été conçu pour répondre à trois objectifs : performances, sécurité et flexibilité.
___
___
## Git à RHD sur la GPAO ?
### Structure de développement actuelle
```mermaid
graph BT
A[Daenerys]
B(Stef) --> A
C(Julien) --> A
D(Orel) --> A
```
Actuellement, chacun code directement sur le meme code, celui de production directement.
En plus de compliquer les choses pour les dev, qui doivent eviter de coder les memes fichiers en meme temps, c'est assez dangereux de travailler sur le serveur de production.
___
### Structure de développement avec GIT (Windowsien avec Docker sous WSL)
```mermaid
graph BT
D[Daenerys]
G{Serveur Git}
S(Stef - Docker/WSL)
J(Julien - Docker/WSL)
O(Orel - Docker)
M(LAMP Merge-tester)
G --> M
G ===> D
S --> G
J --> G
O --> G
```
Cette version est idéale.
Chacun aillant son propre LAMP sur son PC, il peut coder de n'importe où, meme sans reseau.
Mais elle nécessite d'etre au minimum sous Windows 10, et idealement sous Windows 11.
___
### Structure de développement avec GIT (Windowsien avec une copie de Daenerys)
```mermaid
graph BT
D[Daenerys]
G{Serveur Git}
S(Stef)
J(Julien)
O(Orel - Docker)
M(LAMP Merge-tester)
JS(LAMP Julien)
SS(LAMP Stef)
G --> M
G ===> D
O --> G
S --> SS
J --> JS
SS --> G
JS --> G
```
Dans le cas où la version de Windows n'est pas suffisante, les Windowsiens devront passer par un serveur LAMP perso.
Les Windowsiens monte le folder WWW de leur LAMP perso en lieu et place du folder WWW de Daenerys.
___
### Exemple de "flow" Git pour RHD
___
### Point importants
- On ne travaille JAMAIS sur main/master.
- On ne travaille jamais sur dev directement (normalement).
- Depuis dev on lance une nouvelle branche, qu'on modifie autant que l'on souhaite. Ces modifications ne sont PAS apparentes sur dev, ni main/master.
- Une fois la modif terminé, on merge sur dev. Tous les merges arrive sur dev, pour constater que le travail des differents coders ne ruine pas le travail des autres. dev est une "merge place", sur laquelle on peut avoir le code qui sera bientot en prod, sur main/master.
- Une fois les merge realisés, testés... on peu merger sur main/master (avec un tag de version pour se reperer par exemple).
- Dans nos graph de structure avec Git, il faudra manuellement aller sur Daenerys et recuperer la nouvelle version de main/master.
- Cette etape peut etre automatisé de differentes manieres si besoin (GIT CI, Ansible, Bash script...).
___
___
## Procedure Git a utiliser sur la GPAO
### Point de départ
Je considere que la branche main/master et dev sont créées et au même stade, soit :
___
### Création d'une nouvelle branche
Orel se lance dans les maintPrev, il va donc :
```bash=
git fetch
git pull
git switch dev
git branch maintPrev
```
1. Verifier si des changements ont eu lieu sur le depot distant. Le git fetch va recuperer sur le depot distant par defaut (origin) la liste de tout les changement opéré depuis notre dernier update (fetch ou pull)
2. Si oui, les rapatrier pour etre a jour. le git pull fait un fetch, puis rapatrie les changement, et enfin les merge. Il faut mieux d'abord faire un fetch pour voir ce qui a changé, et s'il est necessaire de git pull ou pas. exemple :
* Stef a bossé sur le commercial, et n'a toché a rien d'autre, inutile de pull.
* Stef a bossé sur le commercial, et a modifié les classes de base de la GPAO (machine, user...), le pull est préferable, pour eviter de defaire ce que fait Stef, et de reinventer la roue...
3. Se placer sur la branche dev
4. Creer une nouvelle branche maintPrev a partir de dev. A noter que lors d'un creation de branche, git nous bascule automatiquement dessus. Pas besoin d'un git switch maintPrev ici.
___
### Création de commit
A partir d'ici, Orel peut modifier son code a loisir, en faisant des commit quand il le souhaite.
:::info
**INFO :**
Les commits sont des "checkpoints" (ou en language Windowsien : un point de restoration) du code à un moment donné. C'est ce qui permettra de revenir en arriere si besoin, de voir l'historique...
:::
Par exemple, Orel fait ceci :
* Creation du fichier maintPrev.php
* Edit de maintPrev.php : ajout du minclude(header), le HTML de base...
Ici il veux faire un commit, if fait donc ceci :
```bash=
git status
git add maintPrev.php
git commit -m "Creation de maintPrev.php avec minclude et HTML"
```
1. Check les fichiers qui ont changé (pas obligatoire)
2. Ajout de maintPrev.php dans le prochain commit
3. Commit ! Le -m permet de mettre un commentaire court. Si on veut mettre un commentaire plus long, avec des retours ligne par exemple, ne pas mettre le -m "MESSAGE...", l'editeur de texte par defaut s'ouvrira pour ecrire le commentaire. Sauver et quitter l'editeur et voila, commit done !
[](https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqNjz0LwjAQhv9KuLmUumYWXAU3yXIm1ybYJCVeClL6302ogiiIt70fzwu3gI6GQIIoNzg-JJysClXp6L1jwThIoWAWu7ZrOwVbeEkYtBWG5mfZkr7GzG_OH7hHF_iYvkY-_V9TWwgNeEqFM-WXpSYK2JInBZUx1GMeuTJrqWLmeLoHDZJTpgbyZJBp73BI6EH2ON6KO2E4x_jS6wP00F86)
___
### Merger 2 branches
Orel continu de coder les maintPrev, en faisant des commits reguliers, puis une fois qu'il a terminé il peut merger son trvail sur la branch dev.
```bash=
git switch dev
git merge maintPrev
```
1. Retourne sur la branche sur laquel on veux merge, ici dev
2. On indique quelle branche est rapatriée pour etre mergée a la branche active, ici maintPrev
[](https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqdUEsKwjAQvUqcdZG67VpwJQjuJJsxGdtgk5Q4KUjpgTyHFzPBLwoizmrem_cJGUB5TVCBSFMbXgTsGukyUt5aw4KxroSEXsym5bSUcD1uAzrVCE39TdyQ2vvIL8wPdovG8Sp8hLzz36Kuxz_3j1dbCjU9-4XRuXL5wEzBGnc-iUnuhwKSIal1-sEhJ0jghixJyDZNO4wtZ-WYpBjZr49OQcUhUgGx08g0N1gHtFDtsD0ktkO38f6OxwtiM4a0)
___
### Supprimer une branche
Les bonnes pratiques de git nous disent qu'il faut supprimer une branche lorsqu'on a fini de bosser dessus. Cela évite d'avoir un arbre/historique trop enorme et illisible.
```bash=
git branch -d maintPrev
```
Sans oublier de la supprimer aussi sur le depot distant (origin), si nous l'avion poussé précédement.
```bash=
git push origin --delete maintPrev
```
:::danger
**ATTENTION :**
On ne supprime jamais la branche dev !
C'est notre fils rouge du developpement de la GPAO, son historique. Ce qui nous permet de voir les évolution, de revenir en arriere si besoin. Donc pas touche !
Et bien entendu on n'essait meme pas delete la branche main/master (je ne sais meme pas si c'est possible !)
:::
___
### Pousser vers un repot distant (origin généralement)
Une fois ce code validé par ces pairs, nous allons pouvoir merger avec la branche main/master, puis aller la tirer depuis Daenerys.
```bash=
git switch main
git merge dev
git push --all origin
```
1. Retourne sur la branche sur laquel on veux merge, ici main
2. On indique quelle branche est rapatriée pour etre mergée a la branche active, ici dev
3. On pousse toutes (--all) les branches sur le depots origin
:::info
**INFO :**
Le dépot **origin** sera dans notre cas le serveur Git mis en place sur une VM, un GitLab **privé**.
:::
[](https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqdUcsKwjAQ_JW4ZxF77VnwJAjeJJc1WdugSUrcFKT4QX6HP2ZCfRQLIuaUmZ2dmZAOlNcEJYh0KsPLgE0tXUbKW2tYMFalkNCKYjafzSX0w11Ap2qhqX2Ia1IHH3nA_LBu0Theh5HJJ__Nqh_-eR-1thQqeucLo3Pk6oWZgjXudhWTV_6w9NBEZ_m7cpErj_zaon8JTCFtJQud_qLLNhK4JksS8oKmPcYjZ-UlSTGy35ydgpJDpCnERiPTwmAV0EK5x-MpsQ26rfdPfLkDfQadBg)
:::info
**INFO :**
Pour pousser une seule branche vers origin, ici maintPrev :
```bash=
git push origin maintPrev
```
:::
___
### Tirer les changements
Et enfin depuis Daenerys (sauf si une automatisasion a ete mise en place avec Bash scripts, Ansible, Gitlab CI...)
```bash=
git pull
```
1. Daenerys sera toujours sur main/master, puisque c'est la branche de production. Il suffit donc d'aller chercher la derniere version sur le serveur Git.
Sign in with Wallet
Connect another wallet