Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 66 additions & 6 deletions book/06-github/sections/2-contributing.asc
Original file line number Diff line number Diff line change
Expand Up @@ -37,12 +37,14 @@ Il est centré sur le processus de travail par branches thématiques (voir <<ch0

Le principe général est le suivant :

1. création d'une branche thématique à partir de la branche `master`,
2. validation de quelques améliorations (_commit_),
3. poussée de la branche thématique sur votre projet GitHub (_push_),
4. ouverture d'une requête de tirage sur GitHub (_Pull Request_),
5. discussion et éventuellement possibilité de nouvelles validations (_commit_).
6. Le propriétaire du projet fusionne (_merge_) ou ferme (_close_) la requête de tirage.
1. Duplication du projet.
2. Création d'une branche thématique à partir de la branche `master`,
3. validation de quelques améliorations (_commit_),
4. poussée de la branche thématique sur votre projet GitHub (_push_),
5. ouverture d'une requête de tirage sur GitHub (_Pull Request_),
6. discussion et éventuellement possibilité de nouvelles validations (_commit_).
7. Le propriétaire du projet fusionne (_merge_) ou ferme (_close_) la requête de tirage.
8. Synchronisation de la branche master mise à jour avec celle de votre propre dépôt.

C'est essentiellement le processus de gestion par gestionnaire d'intégration traité dans <<ch05-distributed-git#s_integration_manager>>, mais au lieu d'utiliser des courriels pour communiquer et faire une revue des modifications, les équipes utilisent les outils Web de GitHub.

Expand Down Expand Up @@ -479,3 +481,61 @@ image::images/markdown-08-drag-drop.png[Glisser-déposer d'images]

Si vous regardez à nouveau l'image <<ch06-github#s_pr_references>>, vous y verrez une petite indication ``Parsed as Markdown'' (Traitement Markdown) en haut de la zone de texte.
En cliquant dessus, vous serez redirigé vers une page (en anglais) affichant un aide-mémoire de référence vous résumant tout ce que vous pouvez faire avec Markdown sur GitHub.

[[s_tirer_et_pousser_sur_differents_depots]]
==== Garder votre dépôt GitHub public à jour

Une fois que vous avez dupliqué un dépôt GitHub, votre dépôt (votre « copie ») existe indépendamment de l'original.
En particulier, lorsque le dépôt original a de nouveaux _commits_, GitHub vous en informe avec un message comme :
[source,text]
----
This branch is 5 commits behind progit:master.
----

Mais votre dépôt GitHub ne sera jamais mis à jour automatiquement par GitHub ; c'est quelque chose que vous devez faire vous-même.
Heureusement, cela est très facile à faire.

Une possibilité pour faire ça ne requiert aucune configuration.
Par exemple, si vous avez dupliqué depuis `https://github.com/progit/progit2-fr.git`, vous pouvez garder votre branche `master` à jour comme ceci :
[source,console]
----
$ git checkout master <1>
$ git pull https://github.com/progit/progit2-fr.git <2>
$ git push origin master <3>
----

<1> Si vous étiez sur une autre branche, basculer sur `master`.
<2> Récupérer les modifications depuis `https://github.com/progit/progit2-fr.git` et les fusionner dans `master`.
<3> Pousser votre branche `master` sur `origin`.

Cela fonctionne, mais c'est un peu fastidieux d'avoir à épeler l'URL de récupération à chaque fois.
Vous pouvez automatiser ce travail avec un peu de configuration :

[source,console]
----
$ git remote add progit https://github.com/progit/progit2-fr.git <1>
$ git branch --set-upstream-to=progit/master master <2>
$ git config --local remote.pushDefault origin <3>
----

<1> Ajouter le dépôt source et lui donner un nom.
Ici, j'ai choisi de l'appeler `progit`.
<2> Paramétrer votre branche `master` pour suivre la branche `master` du dépôt distant `progit`.
<3> Définir le dépôt de poussée par défaut comme étant `origin`.

Une fois que cela est fait, le flux de travail devient beaucoup plus simple :

[source,console]
----
$ git checkout master <1>
$ git pull <2>
$ git push <3>
----

<1> Si vous étiez sur une autre branche, basculer sur `master`.
<2> Récupérer les modifications depuis `progit` et les fusionner dans `master`.
<3> Pousser votre branche `master` sur `origin`.

Cette approche peut être utile, mais elle n'est pas sans inconvénient.
Git fera ce travail pour vous gaiement et silencieusement, mais il ne vous avertira pas si vous faites un _commit_ sur `master`, tirez et fusionnez depuis `progit`, puis poussez sur `origin` -- toutes ces opérations sont valides dans cette configuration.
Vous devrez donc prendre garde à ne jamais faire de _commit_ directement sur `master`, puisque cette branche appartient effectivement au dépôt en amont.
6 changes: 6 additions & 0 deletions book/10-git-internals/sections/refspec.asc
Original file line number Diff line number Diff line change
Expand Up @@ -122,6 +122,12 @@ Si elle veut que Git le fasse automatiquement à chaque exécution de `git push

De même, cela fera que, par défaut, `git push origin` publiera la branche locale `master` sur la branche distante `qa/master`.

[NOTE]
====
Vous ne pouvez pas utiliser la _refspec_ pour récupérer les modifications depuis un dépôt et pousser sur un autre.
Pour voir un exemple de comment faire cela, référez-vous à <<ch06-github#s_tirer_et_pousser_sur_differents_depots>>.
====

=== Supprimer des références

Vous pouvez aussi utiliser les _refspecs_ pour supprimer des références sur le serveur distant en exécutant une commande comme :
Expand Down