Pour nous mettre en situation, nous allons travailler chacun dans notre groupe.
Des groupes de 2 à 4 personnes simulent des équipes de travail, composés d'un
ou plusieurs administrateurs et de développeurs (libre à vous d'assigner les droits
dans *gitlab*). Nous allons tous travailler sur une version du même projet.
Au sein d'un groupe, chacun aura pour mission d'effectuer un ou deux changements et
de gérer les conflits éventuels. Nous tenterons également de soumettre certains changements
à d'autres groupes en utilisant des *merge request*.
## Table des matières
-[Partie I](#partie-i)
-[Groupe gitlab](#a-groupe-gitlab)
-[Créer une copie du projet](#b-cr-er-une-copie-du-projet)
-[Cloner le projet](#c-cloner-le-projet-sur-son-environnement-de-travail)
-[Réécrire plop](#d-r-crire-plop)
-[Reconnaissance](#e-reconnaissance)
-[Branche personnelle](#f-branche-personnelle)
-[License](#g-license)
-[Readme](#h-readme)
-[Merge!](#i-merge)
-[Partie II](#partie-ii)
- ...
# Partie I
Dans ce workflow, tous les développeurs peuvent commiter dans un dépôt centralisé.
## A. Groupe gitlab
> ### Énoncé
> Créer un groupe dans gitlab et lui assigner les membres en tant que *Master* ou *Owner*
> Lui donner le nom *atelier-git-groupeN* (N vous sera assigné)
## B. Créer une copie du projet
La première étape est de *forker* le projet *atelier-git-code*.
Cela permettra d'obtenir une copie parfaite du projet *git*, sur laquelle on aura tous les
droits au sein de son groupe.
> ### Énoncé
> Forker le projet https://gitlab.in2p3.fr/cc-in2p3-atelier-git/atelier-git-code avec le role *atelier-git-groupeN*
> ### Outils nécessaires
> * Un navigateur
### Solution
## C. Cloner le projet sur son environnement de travail
> ### Prérequis
> **ATTENTION** cette étape nécessite un [prérequis](/cc-in2p3-atelier-git/atelier-git-enonce/blob/master/prerequis.md#configuration-clef-ssh): générer une clé ssh et la déposer sur gitlab
C'est la dernière étape nécessaire avant de pouvoir réellement travailler sur le projet en lui-même.
Il s'agit de récupérer une copie du projet sur son poste de travail (laptop ou ccdevli).
Une fois l'opération effectuée, on peut enfin travailler sur les fichiers.
> ### Énoncé
> Cloner le projet sur son poste de travail. L'URL *git* du projet se trouve dans la page d'accueil du projet *gitlab*
> ### Commandes *git* nécessaires
> * clone
### Solution
## D. Réécrire plop
Le projet (très compliqué) comporte quelques fichiers de documentation et une source en C dans le répertoire `src`,
à savoir `plop.c`. Ce programme très complexe, une fois compilé en utilisant `gcc plop.c`, permet d'émettre sur la sortie standard le texte `plop`. Le but de cet exercice est: réimplémenter `plop` dans votre langage favori, et de le placer dans `src` aux côtés de `plop.c`. Ensuite, il faut ajouter le fichier au projet et l'envoyer au serveur afin de permettre à ses collègues de son groupe d'en bénéficier.
* Créer `src/plop.truc`
* l'Ajouter à l'index
* valider et annoter les changements
* propager et partager les changements
> ### Énoncé
> Réimplémenter *plop* dans son langage préféré et le partager
> ### Commandes *git* nécessaires
> * add
> * commit
> * push
> * **pull = fetch + merge**
### Solution
## E. Reconnaissance
Le but de cet exercice est de s'ajouter à la liste de contributeurs du fichier `CONTRIBUTORS.md`.
En effet, nous venons de contribuer au projet *plop*, donc à nous la célébrité.
* S'ajouter à `CONTRIBUTORS.md`
* Ajouter le changement à l'index
* valider et annoter le changement
* propager et partager le changement
> ### Énoncé
> Ajouter son nom à `CONTRIBUTORS.md` et partager
> ### Commandes *git* nécessaires
> * add
> * commit
> * push
> * **pull = fetch + merge**
### Solution
## F. Branche personnelle
Le but de cet exercice est de créer une branche personnelle, qui nous permettra de pousser les changements
sans avoir de risque d'être embêté par les changements des autres membres du groupe (éviter un *pull*).
> ### Énoncé
> * Créer une nouvelle branche issue de la branche *master*
> * Propager la branche sur le serveur gitlab
>
> ### Commandes *git*
> * branch
> * push
### Solution
## G. License
But: ajouter une license au projet - choisissez celle que vous voulez:
* CeCILL
* GNU
* Apache
* Artistic
* WTFPL
* …
Et insérez son contenu récupéré sur le ouaib dans le fichier `LICENSE`
Puis, ajoutez, validez, propagez (AVP) dans la nouvelle branche
> ### Énoncé
> * Se positionner sur la nouvelle branche
> * Compléter le fichier `LICENSE`
> * Ajouter le changement à l'index et partagez
>
> ### Commandes *git*
> * checkout
> * add
> * commit
> * push
### Solution
## H. Readme
Ajoutez une entrée dans la documentation, pour votre implémentation de `plop`.
Puis, AVP!
Ensuite, ajoutez d'autres changements, ce que vous voulez.
> ### Énoncé
> * Modifier la documentation `README.md`
> * Partager les changements
### Solution
## I. Merge!
But: maintenant que l'on a fait des changements dans sa branche personelle, on aimerait les propager au sein du groupe.
Pour ce faire, il va falloir fusionner sa branche personnelle avec la branche *master*
> ### Énoncé
> * Se repositionner dans la branche *master*
> * Vérifier que la branche *master* est synchronisée
> * Merger sa branche personelle dans *master*
> * Partager les changements
> * Gérer les conflits éventuels
> * Partager les changements
>
> ### Commandes *git*
> * checkout
> * merge
> * add
### Solution
# Partie II
Dans ce workflow, les modifications sont soumisent à un mainteneur au moyen de *Merge Requests*.
## A. Forker
> ### Énoncé
> *Forker* le projet https://gitlab.in2p3.fr/cc-in2p3-atelier-git/atelier-git-enonce
### Solution
## B. Cloner
> ### Énoncé
> *Cloner* le projet *forké* sur son poste de travail
### Solution
## C. Brancher
> ### Énoncé
> Créer une nouvelle branche et modifier le fichier `README.md` pour ajouter les solutions à tous les énoncés.
### Solution
## D. *Merge Request*
> ### Énoncé
* Effectuer un *merge request* pour notifier le repository d'origine
Pour nous mettre en situation, nous allons travailler chacun dans notre groupe.
Des groupes de 2 à 4 personnes simulent des équipes de travail, composés d'un
ou plusieurs administrateurs et de développeurs (libre à vous d'assigner les droits
dans *gitlab*). Nous allons tous travailler sur une version du même projet.
Au sein d'un groupe, chacun aura pour mission d'effectuer un ou deux changements et
de gérer les conflits éventuels. Nous tenterons également de soumettre certains changements
à d'autres groupes en utilisant des *merge request*.
## Table des matières
-[Partie I](#partie-i)
-[Groupe gitlab](#a-groupe-gitlab)
-[Créer une copie du projet](#b-cr-er-une-copie-du-projet)
-[Cloner le projet](#c-cloner-le-projet-sur-son-environnement-de-travail)
-[Réécrire plop](#d-r-crire-plop)
-[Reconnaissance](#e-reconnaissance)
-[Branche personnelle](#f-branche-personnelle)
-[License](#g-license)
-[Readme](#h-readme)
-[Merge!](#i-merge)
-[Partie II](#partie-ii)
- ...
# Partie I
Dans ce workflow, tous les développeurs peuvent commiter dans un dépôt centralisé.
## A. Groupe gitlab
> ### Énoncé
> Créer un groupe dans gitlab et lui assigner les membres en tant que *Master* ou *Owner*
> Lui donner le nom *atelier-git-groupeN* (N vous sera assigné)
## B. Créer une copie du projet
La première étape est de *forker* le projet *atelier-git-code*.
Cela permettra d'obtenir une copie parfaite du projet *git*, sur laquelle on aura tous les
droits au sein de son groupe.
> ### Énoncé
> Forker le projet https://gitlab.in2p3.fr/cc-in2p3-atelier-git/code avec le role *atelier-git-groupeN*
> ### Outils nécessaires
> * Un navigateur
### Solution
## C. Cloner le projet sur son environnement de travail
> ### Prérequis
> **ATTENTION** cette étape nécessite un [prérequis](prerequis.md#configuration-clef-ssh): générer une clé ssh et la déposer sur gitlab
C'est la dernière étape nécessaire avant de pouvoir réellement travailler sur le projet en lui-même.
Il s'agit de récupérer une copie du projet sur son poste de travail (laptop ou ccdevli).
Une fois l'opération effectuée, on peut enfin travailler sur les fichiers.
> ### Énoncé
> Cloner le projet sur son poste de travail. L'URL *git* du projet se trouve dans la page d'accueil du projet *gitlab*
> ### Commandes *git* nécessaires
> * clone
### Solution
## D. Réécrire plop
Le projet (très compliqué) comporte quelques fichiers de documentation et une source en C dans le répertoire `src`,
à savoir `plop.c`. Ce programme très complexe, une fois compilé en utilisant `gcc plop.c`, permet d'émettre sur la sortie standard le texte `plop`. Le but de cet exercice est: réimplémenter `plop` dans votre langage favori, et de le placer dans `src` aux côtés de `plop.c`. Ensuite, il faut ajouter le fichier au projet et l'envoyer au serveur afin de permettre à ses collègues de son groupe d'en bénéficier.
* Créer `src/plop.truc`
* l'Ajouter à l'index
* valider et annoter les changements
* propager et partager les changements
> ### Énoncé
> Réimplémenter *plop* dans son langage préféré et le partager
> ### Commandes *git* nécessaires
> * add
> * commit
> * push
> * **pull = fetch + merge**
### Solution
## E. Reconnaissance
Le but de cet exercice est de s'ajouter à la liste de contributeurs du fichier `CONTRIBUTORS.md`.
En effet, nous venons de contribuer au projet *plop*, donc à nous la célébrité.
* S'ajouter à `CONTRIBUTORS.md`
* Ajouter le changement à l'index
* valider et annoter le changement
* propager et partager le changement
> ### Énoncé
> Ajouter son nom à `CONTRIBUTORS.md` et partager
> ### Commandes *git* nécessaires
> * add
> * commit
> * push
> * **pull = fetch + merge**
### Solution
## F. Branche personnelle
Le but de cet exercice est de créer une branche personnelle, qui nous permettra de pousser les changements
sans avoir de risque d'être embêté par les changements des autres membres du groupe (éviter un *pull*).
> ### Énoncé
> * Créer une nouvelle branche issue de la branche *master*
> * Propager la branche sur le serveur gitlab
>
> ### Commandes *git*
> * branch
> * push
### Solution
## G. License
But: ajouter une license au projet - choisissez celle que vous voulez:
* CeCILL
* GNU
* Apache
* Artistic
* WTFPL
* …
Et insérez son contenu récupéré sur le ouaib dans le fichier `LICENSE`
Puis, ajoutez, validez, propagez (AVP) dans la nouvelle branche
> ### Énoncé
> * Se positionner sur la nouvelle branche
> * Compléter le fichier `LICENSE`
> * Ajouter le changement à l'index et partagez
>
> ### Commandes *git*
> * checkout
> * add
> * commit
> * push
### Solution
## H. Readme
Ajoutez une entrée dans la documentation, pour votre implémentation de `plop`.
Puis, AVP!
Ensuite, ajoutez d'autres changements, ce que vous voulez.
> ### Énoncé
> * Modifier la documentation `README.md`
> * Partager les changements
### Solution
## I. Merge!
But: maintenant que l'on a fait des changements dans sa branche personelle, on aimerait les propager au sein du groupe.
Pour ce faire, il va falloir fusionner sa branche personnelle avec la branche *master*
> ### Énoncé
> * Se repositionner dans la branche *master*
> * Vérifier que la branche *master* est synchronisée
> * Merger sa branche personelle dans *master*
> * Partager les changements
> * Gérer les conflits éventuels
> * Partager les changements
>
> ### Commandes *git*
> * checkout
> * merge
> * add
### Solution
# Partie II
Dans ce workflow, les modifications sont soumisent à un mainteneur au moyen de *Merge Requests*.
## A. Forker
> ### Énoncé
> *Forker* le projet https://gitlab.in2p3.fr/cc-in2p3-atelier-git/enonce
### Solution
## B. Cloner
> ### Énoncé
> *Cloner* le projet *forké* sur son poste de travail
### Solution
## C. Brancher
> ### Énoncé
> Créer une nouvelle branche et modifier le fichier `README.md` pour ajouter les solutions à tous les énoncés.
### Solution
## D. *Merge Request*
> ### Énoncé
* Effectuer un *merge request* pour notifier le repository d'origine
