|
@@ -18,7 +18,7 @@ choisira ou non de les intégrer dans le dépôt initial (upstream).
|
|
|
Le fork est un mode de fonctionnement très répandu dans le monde de
|
|
|
l'open-source (github entre autres). Le serveur gogs de l'université possède
|
|
|
également une partie publique propice aux forks (cette partie publique est
|
|
|
-cependant réservée aux personnes ayant des identifiants à l'université).
|
|
|
+cependant réservée aux personnes identifiées à l'université).
|
|
|
|
|
|
Remarque : pour les intervenants réguliers et de confiance, il est plus simple
|
|
|
de les autoriser à modifier directement le dépôt principal, en les ajoutant
|
|
@@ -52,7 +52,7 @@ Fabien peut ensuite cloner son nouveau dépôt...
|
|
|
|
|
|
![](forks_06a.png)
|
|
|
|
|
|
-... y faire ses modifications, **de préférence dans une nouvelle branche**, ...
|
|
|
+... y faire ses modifications (si possible dans une nouvelle branche), ...
|
|
|
|
|
|
![](forks_06b.png)
|
|
|
|
|
@@ -75,7 +75,7 @@ Il met un message pour Julien, expliquant ses modifications (ou pas d'ailleurs).
|
|
|
|
|
|
![](forks_08.png)
|
|
|
|
|
|
-Puis le pull request est envoyé à Julien.
|
|
|
+Le pull request est alors enregistré.
|
|
|
|
|
|
![](forks_09.png)
|
|
|
|
|
@@ -101,15 +101,18 @@ Elle apparait alors dans la liste des commits.
|
|
|
Si les modifications du fork ont été faites dans une nouvelle branche, il ne
|
|
|
faut pas oublier de la fusionner dans le master, sur le dépôt upstream.
|
|
|
|
|
|
-En cas de conflit, le pull request doit être intégré manuellement (voir section
|
|
|
-suivante).
|
|
|
+En cas de conflit, le pull request doit être intégré manuellement (voir ci-dessous).
|
|
|
|
|
|
## Mettre à jour un dépôt forké, spécifier manuellement les dépots distants
|
|
|
|
|
|
Après un fork, les deux dépôts (fork et upstream) peuvent évoluer
|
|
|
indépendamment. Pour récupérer les nouvelles modifications du dépôt initial
|
|
|
dans le dépôt forké, il suffit de l'ajouter comme dépôt distant (généralement,
|
|
|
-on utilise le nom "upstream") :
|
|
|
+on utilise le nom "upstream").
|
|
|
+
|
|
|
+Par exemple, Fabien peut ajouter le dépôt initial (de Julien) sous le nom
|
|
|
+"upstream" avec la commande suivante (normalement, c'est déjà fait
|
|
|
+grâce au fork).
|
|
|
|
|
|
```
|
|
|
git remote add upstream https://gogs.univ-littoral.fr/jdehos/tutoriel_git
|
|
@@ -127,8 +130,10 @@ Cette gestion des dépôts distants est très puissante. Elle permet, par exempl
|
|
|
de créer, pour un même projet, un dépôt distant public et un dépôt distant privé
|
|
|
(éventuellement sur des serveurs différents) et de les synchroniser.
|
|
|
|
|
|
-Ainsi, pour gérer un pull request manuellement (par
|
|
|
-exemple pour fusionner dans une branche différente que celle du pull request) :
|
|
|
+Autre exemple, Julien peut gérer manuellement un pull request de Fabien dans
|
|
|
+une branche spéciale. Pour cela, il lui suffit d'ajouter et de récupérer le
|
|
|
+dépôt distant de Fabien (par exemple sous le nom "fork_fabien") et de créer une
|
|
|
+branche ("pull_request_fabien") pour y merger le master de fork_fabien.
|
|
|
|
|
|
```
|
|
|
git remote add fork_fabien https://gogs.univ-littoral.fr/fteytaud/tutoriel_git
|
|
@@ -155,8 +160,8 @@ Quelques conseils de méthode de travail :
|
|
|
|
|
|
## Exercice 1
|
|
|
|
|
|
-- Associez-vous à un ou deux collègues : l'un d'entre vous va créer un dépôt
|
|
|
- public, les autres vont le forker et soumettre des pull-requests.
|
|
|
+- Associez-vous à un ou deux collègues : l'un d'entre vous doit créer un dépôt
|
|
|
+ public, les autres doivent le forker et soumettre des pull-requests.
|
|
|
|
|
|
## Exercice 2
|
|
|
|