---
# System prepended metadata

title: TP Git Compte Rendu

---

# TP Git Compte Rendu
Quang Minh - Julien

## Repo Link
https://github.com/yurihikari/test-repo

## Exercice 5
### Question 1 : Configurer gitignore
On utilise un gitignore afin d'ignorer certains fichiers/dossiers.
- On utilise github.io
- On copie/colle le contenu généré pour la technologie de notre choix. Il peut contenir des extensions de fichier, des noms de fichier et même des routes de dossier. Ils seront tous ignorés lors des commit et push vers le repository distant.
```
*.tar
*.tar.*
*.jar
*.exe
*.msi
*.zip
*.tgz
*.log
*.log.*
*.sig

pkg/
src/
```
.gitignore pour ArchLinuxPackage
- On crée un fichier .gitignore dans la racine
- On le défini globalement pour être pris en compte
```bash
git config-- globalcore.excludesfile ~/.gitignore_global
```
- On peut ensuite commit, push etc. sur le repository en ligne



### Question 2 : placer un tag
Un tag peut être utile pour marquer l'état d'un projet dans le temps, en lui attribuant un numéro de version.
- La première commande à faire seras "git tag -a LaVersion" afin de définir la version que l'on souhaite attribuer.
Nous faisons par exemple ici la version 1.0
![](https://i.imgur.com/105CtVw.png)
- Cela va ensuite nous demander de mettre une description pour le tag. Nous réécrivons simplement le numéro de version, mais on pourrait y mettre une description plus détaillée.
- On pousse ensuite notre tag sur le repository distant
```bash=
git push origin v1.0
```
Tada, nous avons notre tag créé avec sa decription
![](https://i.imgur.com/kFjx2qV.png)



### Question 3 : Identifier le fautif
On a parfois des bugs pouvant survenir d'un fichier, mais nous voulons savoir qui a modifié le fichier en question, générant ce bug.
La commande 
```bash=
git blame nomdufichier
```
va afficher les logs des différents commit réalisés, avec le nom de celui qui l'a effectué ainsi que les modifications précises effectuées.
![](https://i.imgur.com/LsnyeBD.png)
Petit exemple avec le README, où on peut voir que Julien Millaud a modifié la 3ème ligne du fichier avec "ceci est un test".

### Question 4 : Réécrire l'histoire

- Création de la nouvelle branche
On crée la branche test pour cette question.
```bash
git branch test
```


- Création des deux commits
On y réalise 2 commits en modifiant 2 de nos fichiers 
(test.txt et README.md)

![](https://i.imgur.com/M5s5Wnp.png)




- Transplanter la nouvelle branche sur la branche principale 
On transplante ensuite sur la branche principale. Cela nous demande ensuite de squash les les commits. On décide de squash "Test txt" et fusionner sur le "Test readme"
On peut ensuite pousser nos modifications.
![](https://i.imgur.com/mklVPUV.png)


- Historique des manipulations
En regardant l'historique, on peut voir que le rebase s'est bien effectué, et que le squash donne le commit final à "Test readme"
![](https://i.imgur.com/TRgJ6eB.png)
On peut aussi voir sur l'arbre git que un seul commit a été mis, preuve que la fusion s'est bien déroulée.
![](https://i.imgur.com/VhJfmvG.png)
On peut ensuite voir sur notre branche main que cela s'est bien rebase dessus.
![](https://i.imgur.com/WL4wDiT.png)
