|
|
@@ -9,7 +9,7 @@ non modifiable (pour éviter que n'importe qui y fasse n'importe quoi). Si
|
|
|
Fabien (à qui il arrive parfois de faire n'importe quoi) veut proposer une
|
|
|
modification, il peut alors copier (forker) le dépôt de Julien, faire ses
|
|
|
modifications dans son dépôt, puis les soumettre à Julien (pull request), qui
|
|
|
-choisira ou non de les intégrer dans le dépôt initial (upstream).
|
|
|
+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
|
|
|
@@ -59,7 +59,7 @@ Fabien peut ensuite cloner son nouveau dépôt...
|
|
|
## Envoyer un pull request
|
|
|
|
|
|
Un pull request permet de demander d'intégrer d'une modification d'un dépôt
|
|
|
-forké dans le dépôt initial (upstream).
|
|
|
+forké dans le dépôt initial (`upstream`).
|
|
|
|
|
|
Jusqu'ici, Fabien a forké le dépôt de Julien et fait des modifications sur son
|
|
|
dépôt forké. Pour soumettre ses modifications, il va sur la page correspondant
|
|
|
@@ -95,7 +95,7 @@ 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.
|
|
|
+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 ci-dessous).
|
|
|
|
|
|
@@ -104,17 +104,17 @@ En cas de conflit, le pull request doit être intégré manuellement (voir ci-de
|
|
|
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
|
|
|
+`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
|
|
|
```
|
|
|
|
|
|
-On peut ensuite récupérer les évolutions du dépôt upstream et les fusionner
|
|
|
+On peut ensuite récupérer les évolutions du dépôt `upstream` et les fusionner
|
|
|
dans le dépôt forké :
|
|
|
|
|
|
```
|
|
|
@@ -129,7 +129,7 @@ de créer, pour un même projet, un dépôt distant public et un dépôt distant
|
|
|
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.
|
|
|
+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
|
|
|
@@ -164,9 +164,9 @@ Quelques conseils de méthode de travail :
|
|
|
- Créez deux dépôts distants, l'un publique, l'autre privé.
|
|
|
- Clonez le dépôt privé, faites-y quelques commits et pushez le tout.
|
|
|
- Toujours dans le dépôt privé local, créez une branche "public", fusionnez-y
|
|
|
- le master et pushez-la sur le dépôt distant privé et sur le dépôt distant
|
|
|
+ le `master` et pushez-la sur le dépôt distant privé et sur le dépôt distant
|
|
|
public.
|
|
|
-- Faites un nouveau commit dans le master, fusionnez-le dans la branche
|
|
|
+- Faites un nouveau commit dans le `master`, fusionnez-le dans la branche
|
|
|
"public" et pushez le tout.
|
|
|
- Clonez le dépôt public et mettez-le à jour avec la branche "public" du dépôt
|
|
|
distant privé.
|
Julien Dehos