Garder à jour un fork de github/gitlab

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.

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

# 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

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

# 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

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

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