forks.md 4.3 KB
title: "Tutoriel git
introduction | installation | dépôt local | dépôt distant | branches | forks
"
output:
toc: true
Forks
Imaginons que Julien propose un dépôt public, visible par tout le monde, mais 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 le dépôt de Julien (fork), 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).
Le fork est un mode de fonctionnement très répandu dans le monde de l'open-source (github entre autres). Le serveur gogs du SCOSI possède également une partie publique mais visible après connexion (donc réservée aux étudiants et personnels de l'université).
Attention : 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 comme collaborateurs (les deux systèmes sont complémentaires).
Forker un dépôt distant
Le dépôt de Julien est déjà sur le serveur, dans la partie publique. Fabien se connecte sur le site gogs du SCOSI.
Il explore la zone publique et sélectionne le dépôt de Julien.
Il demande de forker le projet.
Ce qui lui crée un nouveau dépôt...
... qui est une copie du dépôt initial.
Fabien peut ensuite cloner son nouveau dépôt...
... y faire ses modifications, de préférence dans une nouvelle branche, ...
... et les pusher sur son dépôt distant.
Envoyer un pull request
Un pull request est une demande d'intégrer une modification d'un dépôt 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 à son dépôt et clique sur le bouton pull request.
Il met un message pour Julien, expliquant ses modifications (ou pas).
Puis le pull request est envoyé à Julien.
Gérer un pull request
De son côté, Julien reçoit le pull request de Fabien, pour le dépôt initial.
Il peut alors regarder les modifications proposées, échanger des messages avec Fabien puis finalement accepter (ou refuser) les modifications.
Si le pull request est accepté, la modification est fusionné dans le dépôt.
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 fusionner dans la branche master sur le dépôt upstream.
Mettre à jour un dépôt forké
Après un fork, les deux dépôts (fork et upstream) peuvent évoluer indépendamment. Pour récupérer les modifications du dépôt initial dans le dépôt forké, on l'ajoute comme "remote" (sous le nom "upstream") puis on peut récupérer les évolutions de upstream (fetch) et les fusionner dans le dépôt forké (merge).
git remote add upstream https://gogs.univ-littoral.fr/jdehos/tutoriel_git
git fetch upstream
git merge upstream/master
Gérer manuellement un pull request
Pour gérer un pull request manuellement, il suffit, dans le dépôt principal, d'ajouter le dépôt forké comme remote puis de synchroniser avec fetch et merge. L'avantage de cette méthode est que l'on peut fusionner dans une branche différente que celle du pull request.
git remote add fork_fabien https://gogs.univ-littoral.fr/fteytaud/tutoriel_git
git fetch fork_fabien
git merge fork_fabien/master
Résumé et méthode de travail
Résumé des commandes git précédentes :
---|---|
git remote add ... | TODO |
git fetch ... | |
git merge ... | |
Quelques conseils de méthode de travail :
- TODO
Exercice
TODO
Dernière mise à jour : 2016-03-05