Garder à jour un fork de github/gitlab

Les développeurs de la communauté R sont ouverts à tout type de soutien dans le développement de leurs packages. Vous pouvez ouvrir des issues mais aussi proposer des pull/merge requests pour améliorer le code et/ou la documentation. Mais une fois que vous avez fork le dépôt principal, comment être sûr de travailler sur la dernière version du code ? On va voir quelques lignes de code pour garder vos fork à jour.

Gérez vos fork

Si vous avez fork un dépôt github ou gitlab pour proposer des pull/merge requests, vous devrez peut-être travailler sur la dernière version à jour du dépôt original. Les interfaces graphiques ne vous permettent pas de rester à jour avec exactement les mêmes commits. Si vous avez déjà essayé graphiquement, vous avez probablement dû inclure différents merge commit.
De fait, pour pouvoir continuer à participer au développement, ou garder à jour votre propre fork avec les dernières modifications du dépôt d’origine, vous devrez le gérer localement avec quelques lignes de commande. Toutes les lignes de commande ci-dessous doivent être exécutées dans un Terminal. Souvenez-vous que vous avez une interface “Terminal” dans votre IDE Rstudio pour gérer votre système en lignes de commande.

Issu de https://happygitwithr.com

Figure 1: Issu de https://happygitwithr.com

Ajouter un fork dans votre dépôt local

upstream sera le nom du dépôt distant original sur votre ordinateur, par contraste avec origin, le nom du dépôt de votre propre fork.

# Liste serveurs distants
git remote -v
# Ajouter upstream
git remote add upstream https://github.com/ThinkR-open/attachment.git
# Liste serveurs distants pour vérifier l'ajout de upstream
git remote -v
# Récupère les commits du upstream
git fetch upstream

Le code ci-dessus permet d’obtenir une copie du dépôt distant. Ce n’est pas une branche sur laquelle travailler.

Gérer les branches master

Lorsque je travaille avec un fork, je recommande de ne pas modifier le master, en particulier si vous avez fait un fork uniquement pour participer au développement du dépôt d’origine. Par conséquent, vous ne jouez qu’avec des branches.
Pour rester à jour, ce que je fais, c’est de gérer une branche locale pour le upstream/master que je peux comparer à mes propres branches. Vous pouvez gérer votre master pour qu’il soit la copie du dépôt original si vous voulez, mais personnellement, je préfère lire l’origine des branches dans le nom des branches.

Créer une branche locale synchronisée avec le dépôt d’origine

# Créer une branch nommée upstream_master et l'ouvrir
git checkout -b upstream_master upstream/master
# Mettre à jour son contenu
git pull

Si pour une raison quelconque vous avez créé la branche sans la lier au dépôt distant, vous pouvez utiliser la ligne de commande suivante :

# version précédentes de git
# git branch --set-upstream=upstream/master upstream_master
# version récente de git
git branch --set-upstream-to=upstream/master upstream_master

Mettez à jour les branches de votre fork

N’utilisez rebase que si vous savez ce que vous faites et si vos modifications n’ont pas déjà été envoyées sur un dépôt distant. Sinon, vous préférerez utiliser merge.

Récupèrer les modifications dans le upstream de votre branche.
_Si vous êtes sûr que vous n’avez pas push de changements sur le serveur distant

git checkout my-branch
git pull
git rebase upstream_master
# ou directement depuis le (local) distant
git rebase upstream/master

Si vous pensez que vous avez envoyé des modifications sur le serveur distant

git checkout my-branch
git pull
git merge upstream_master

Gérez vos branches

Avec plusieurs développeurs qui travaillent sur le même projet, vous pouvez adopter un comportement similaire avec votre branche principale (master ou dev selon vos choix d’architecture git).

Mon fonctionnement personnel est :

  • Travailler localement

  • rebase chaque fois que le gestionnaire de dépôt m’informe que la branche principale a été mise à jour, de façon à réduire les résolutions de conflits

    # be sure to be on your branch
    git checkout my-branch
    # update the local-distant server part
    git fetch
    # Stash your current work
    git stash
    # Rebase if you know what your are doing
    git rebase origin/dev
    # Un-stash your current work and solve potential conflicts
    git stash apply
  • Envoyer sur le serveur seulement quand je souhaite que mon travaille soit merge avec la branche principale :

    # git add your-files
    # git commit your changes
    # Push to distant server
    git push
  • Ouvrir une pull/merge request pour informer les autres développeurs et le gestionnaire des modifications

Je me doute que ce fonctionnement n’est pas viable pour la totalité des projets git, mais si ça peut vous donner des idées, ce sera déjà ça de partagé. Après ça, vous pourrez toujours comparer à d’autres mode de gestion de projets git.


Ce court article de blog est plus un rappel pour moi, pour que je puisse retrouver ces informations rapidement. Si vous voulez en savoir plus sur git, en particulier pour du développement avec R, je vous recommande https://happygitwithr.com. De fait, il y a aussi un chapitre sur les fork : https://happygitwithr.com/upstream-changes.html



Citation :

Merci de citer ce travail avec :
Rochette Sébastien. (2019, May. 12). "Garder à jour un fork de github/gitlab". Retrieved from https://statnmap.com/fr/2019-05-12-garder-a-jour-fork-github-gitlab/.


Citation BibTex :
@misc{Roche2019Garde,
    author = {Rochette Sébastien},
    title = {Garder à jour un fork de github/gitlab},
    url = {https://statnmap.com/fr/2019-05-12-garder-a-jour-fork-github-gitlab/},
    year = {2019}
  }
Commentaires
comments powered by Disqus