Étiquette : git

[Git] Configurer un compte Git sur une install Ubuntu Server et générer une clé SSH d’utilisateur

…dans le cadre, notamment, d’une récupération de VM existante, le compte Git actuellement configuré doit être changé pour celui du développeur qui utilisera la VM.
L’idée ici est de supprimer le compte existant pour en créer un nouveau.

Si le repository est cloné via https

Supprimer le compte existant (le fichier sera regénéré à partir de vos login/mot-de-passe qui vous seront demandés la prochaine fois que vous essayerez d’accéder au Git) :

Si le repository est cloné via SSH

Localiser le dossier ssh sur votre VM. Attention, c’est un dossier caché!

Pour lister les clés existantes (fichiers de type id_rsa):

Supprimer toutes les clés SSH existantes (ce ne sont pas les vôtres; vous ne voulez pas versionner des choses dans Git et que le nom d’utilisateur qui apparaisse dans les logs soit celui de quelqu’un d’autre a.k.a. l’utilisateur précédent de votre VM).

Générer une nouvelle clé. Remarque : pour la génération de la clé SSH par défaut (commande $ ssh-keygen), il vous sera demandé un nom et une passphrase. Laissez ces informations vides.

Copier/coller la nouvelle clé SSH générée (fichier id_rsa.pub). Pour l’afficher :

Dans l’interface Gitlab

  • Profile settings > SSH keys > Add SSH key.
  • Coller la clé SSH récupérée depuis votre VM Ubuntu.
  • Si une clé SSH ne vous appartenant pas est listée, la supprimer pour ne conserver que celle que vous avez ajouté.

Editer la config Git

Stocker vos login/mot-de-passe afin qu’ils ne vous soient pas demandés à chacun de vos accès au Git :

[Git] Les fonctionnalités et commandes utiles

Ne pas versionner un répertoire entier :

Source : Utilisation de .gitignore.

Admettons qu’on souhaite ne pas versionner le répertoire sass-cache/ :

Comment supprimer un fichier de mon repository Git ?

Comment supprimer un répertoire de mon repository Git ?

Source : http://stackoverflow.com/questions/6313126/how-to-remove-a-directory-in-my-github-repository.

Augmenter la taille maximum du volume de données qu’on peut envoyer en un seul git push sur son repository

Il peut arriver qu’on essaye de remonter un volume trop important de données au cours d’un seul et même push. Le message d’erreur obtenu lors du push est le suivant :

Pour pallier à ce problème, il suffit d’augmenter la taille maximum du volume de données qu’on peut remonter, en une seule fois, dans le repository Git.

…où taille maxi est en octets, ce qui nous donne pour 5 Mo :

Un convertisseur Octet, Ko, Mo, Go, Po est disponible ici http://mon-ip.awardspace.com/convertisseur.php.

Merger la branche ‘master’ dans une autre branche :

Se rendre sur la branche ‘master’: $ git checkout master.

Faire un pull: $ git pull.

Se rendre sur la branche dans laquelle on souhaite merger ‘master’ (toto dans mon exemple): $ git checkout toto.

Merger ‘master’ dans ‘toto’: $ git merge master.


Solution alternative (préférer la 1ère ci-dessus). Vous devez être dans la branche dans laquelle vous voulez merger ‘master’ avant de taper la commande:

Merger une branche avec la branche ‘master’ :

Si on veut pusher du code sur le repo, ajouter:

Régler des conflits intervenus lors d’un merge ou d’un pull –rebase

Si vous obtenez des messages de type CONFLIT (contenu) : Conflit de fusion dans sites/all/themes/custom/roederer_main_theme/src/style/_roederer-actualites.scss lors d’un merge:

Faites un git status pour revérifier quels fichiers sont en conflit:

Editer ces fichiers pour résoudre vos conflits. Puis faites en git add de ces fichiers, puis un git ci sans mettre de message de log (« ctrl+x » pour valider le message proposé par git). N’oubliez pas de faire un git push pour envoyer vos modifs.

Si problème fatal: Vous n'êtes actuellement sur aucune branche. après le git push:

Exemple:

Faire un git st qui vous indiquera qu’un rebasage est en cours.

Faire un git rebase --continue, puis un git push.

Régler des conflits intervenus lors d’un merge (autre méthode qui jongle entre l’interface de gitlab, de PHPStorm et la ligne de commande)

Un peu d’aide externe: On undoing, fixing, or removing commits in git.

  • Contexte #1: au secours, il y a un conflit sur la branche staging intervenu après une tentative de merge et j’ai lamentablement foiré ma tentative de résolution du conflit. Commencer ici.
  • Contexte #2: au secours, il y a un conflit sur la branche staging intervenu après une tentative de merge mais je n’ai pas encore tenté de résoudre quoi que ce soit. Commencer là.

[Interface de GitLab] Commencer par recréer une nouvelle branche

…dans laquelle on va redéposer le code à merger sur staging. ATTENTION: conservez votre ancienne branche pour le moment; votre nouvelle branche doit avoir un nom unique, proche de celui de la branche qu’on essaye de merger dans staging de préférence.

[Interface de PHPStorm]

Depuis l’interface:

On récupère l’info sur la création de notre nouvelle branche: Top menu horizontal > Git > Fetch

On se place sur notre nouvelle branche: Tout en bas à droite, via l’indicateur de la branche courante > dans « Remote Branches » > choisir origin/ma_nouvelle_branche

Depuis GitLab et PHPStorm (jonglage):

Aller dans la Merge Request foireuse (URL de type: https://gitlab.ma-boite.com/client/projet/-/merge_requests/6377/commits). Vous devriez voir un listing des commits liés à la branche que vous souhaites merge dans staging:

En partant du commit le plus ancien (normalement celui le plus en bas de la liste) copier les uns après les autres les hash des commit qu’on souhaite récupérer dans notre nouvelle branche et retourner dans la partie Terminal de PHPStorm pour…

Puis, à partir de là, depuis le terminal bash de l’interface:

…effectuer des cherry-pick en tapant la commande suivante:

(Répéter autant de fois que nécessaire). Une fois tous les commits souhaités récupérés, taper:

Faire une nouvelle Merge Request dans GitLab

Nous allons de nouveau avoir les mêmes conflits, mais l’idée est de les résoudre proprement cette fois-ci…

Depuis PHPStorm

On se place sur la branche staging! Puis, pour vérifier qu’on est dans la bonne branche:

Normalement, le git status devrait vous donner le message suivant:

On branch staging
Your branch is up to date with 'origin/staging'..

On merge (localement) notre nouvelle branche dans staging:

Onb obtient logiquement un conflit:

Dans l’interface, dans la partie arborescence projet, se placer d’un click sur la racine du dossier projet et faire un click droit.

Git > Resolve conflict.

Bouton « Merge »

On arrive sur l’interface à 3 colonnes qui nous permet de corriger le conflit. La colonne du milieu est celle qui doit contenir le code corrigé. On peut se servir des croix « X » (supprimer du code non souhaité dans la colonne de gauche ou de droite) et des flèches « >> » ou « <<" (reporter du code dans la colonne du milieu). On peut également saisir à la main du code dans la colonne du milieu qui sera pris en compte.

Bouton « Apply » lorsque les correction sont finies.

Un petit git status devrait afficher en vert le(s) fichier(s) pour lesquels les conflits ont été résolus. Taper:

Le log de résolution du conflit s’affiche. Pour quitter l’édition:

Puis enfin:

Vous pouvez retourner sur la page de la MR dans l’interface de Gitlab pour vérifier que le merge est passé.

On retourne dans l’interface de Gitlab pour finaliser la merge request

Le mieux est d’en profiter pour supprimer la branche qu’on a souhaité mergé initialement dans staging (celle qu’on a refaite) et qui posait problème. Ne pas oublier de la supprimer également en local!

Créer une nouvelle branche à partir de la branche ‘release’ :

En premier lieu s’assurer que la branche ‘release’ (ou ‘release’ est le nom de la branche à partir de laquelle vous voulez créer votre nouvelle branche) est à jour avec les derniers devs consignés sur le repository en lançant depuis celle-ci la commande :

Ensuite, toujours depuis la branche à partir de laquelle on souhaite créer une nouvelle branche :

Faire un premier pull

Et pour le premier push dans la nouvelle branche :

Mettre une branche à jour à partir de la branche ‘release’

Je travaille sur du debug ou une feature que je versionne dans une branche à part. Du code à été versé sur la branche ‘release’ dont je pourrais avoir besoin. Je dois donc récupérer ce code. Au lieu de merger, je lance la commande suivante:

Supprimer un ensemble de fichiers ajoutés depuis le dernier pull et encore non-versionnés

Cette commande peut s’avérer pratique (mais dangereuse) lorsqu’on a effectué des modifications sur un certain nombre de fichiers et qu’on ne souhaite pas les conserver.

x pour les dossiers, f pour les fichiers.

J’ai créé une nouvelle branche et le git status m’affiche tous les fichiers qui sont normalement ignorés

Taper git checkout . pour réinitialiser en l’état de ce qui est versé sur la branche Master distante. Un git status ne devrait plus montrer les chemins et fichiers consignés dans le .gitignore.

J’ai modifié un fichier et je ne dois pas le versionner, mais pour l’instant il est surveillé

Source : Stop tracking and ignore changes to a file in Git.

tu peux faire :

par contre, si un jour tu veux commiter un changement que t’as fait sur un fichier ou tu a utiliser cette commande, il faudra faire :

Réinitialiser le code d’une branche à l’état de celui se trouvant sur le repository distant

Solution préférée

Supposons que la branche qu’on souhaite réinitialiser s’appelle: feature/ma_branche.

  1. Retourner sur la branche master avec un $ git co master.
  2. Supprimer la branche qu’on souhaite réinitialiser du repo local en tapant: $ git branch -D feature/ma_branche.
  3. Refaire un checkout de la branche pour la récupérer depuis le repo distant: $ git checkout feature/ma_branche.

Autre solution

Voir toutes les branches existantes, y-compris celles du repo distant

Bonus: rechercher dans toutes les branches existantes, y-compris celles du repo distant, une branche en particulier via un mot clé.

J’ai add et commit (-m) plusieurs fois sur la branche master sans avoir pushé. Comment revenir sur une base propre?

Premièrement, faire un git log pour vérifier le nombre exact de commits qui ont été faits sur la branche master (/Frank, où « Frank » est votre Git username, pour mettre en surbrillance vos commits, n pour les passer en revue l’un après l’autre et q pour quitter).

Ensuite, créer une nouvelle branche à partir de master pour sauvegarder vos commits: $ git checkout -b <nom_de_votre_nouvelle_branche> master.

Puis revenir sur master: $ git checkout master et exécuter la commande $ git reset --hard HEAD^ autant de fois que vous aviez effectué de commits sur master.

Lister les nouvelles branches disponibles uniquement en remote repository et les récupérer en local

How do I list remote branches in Git?

git checkout a Remote Branch

Revenir à un commit précédent en local avec git revert

Source: How to With Git: Rollback Commit.

Pour afficher l’index des commits en local: $ git reflog

Pour revenir en arrière sur tous les commits depuis “1a890e7” jusqu’à “HEAD,”: $ git revert 1a890e7..HEAD

Autre solution:

Il est également possible de faire un simple checkout: $ git checkout 1a890e7.

Debug: la recherche dichotomique avec git bisect start / good / bad / reset

Source: Utilitaires Git – Deboguer avec Git – La recherche dichotomique.

Annoter un fichier peut aider si vous savez déjà où le problème se situe. Si vous ne savez pas ce qui a cassé le code, il peut y avoir des douzaines, voire des centaines de commits depuis le dernier état où votre code fonctionnait et vous aimeriez certainement exécuter git bisect pour vous aider.

Configuration de Git: formatage et espaces blancs

Source: https://git-scm.com/ – 8.1 Personnalisation de Git – Configuration de Git – Formatage et espaces blancs.

Les problèmes de formatage et de blancs sont parmi les plus subtils et frustrants que les développeurs rencontrent lorsqu’ils collaborent, spécifiquement d’une plate-forme à l’autre. Il est très facile d’introduire des modifications subtiles de blancs lors de soumission de patchs ou d’autres modes de collaboration, car les éditeurs de texte les insèrent silencieusement ou les programmeurs Windows ajoutent des retours chariot à la fin des lignes qu’ils modifient. Git dispose de quelques options de configuration pour traiter ces problèmes.

Si vous utilisez un système Linux ou macOS qui utilise les fins de ligne LF, vous ne souhaitez sûrement pas que Git les convertisse automatiquement lorsque vous extrayez des fichiers. Cependant, si un fichier contenant des CRLF est accidentellement introduit en gestion de versions, vous souhaitez que Git le corrige. Vous pouvez indiquer à Git de convertir CRLF en LF lors de la validation mais pas dans l’autre sens en fixant core.autocrlf à input :

Récupérer une branche distante encore non suivie en local

Lister l’ensemble des branches distantes:

J’obtiens par exemple:

Pour récupérer la branche qui nous intéresse (par exemple: remotes/origin/feature/VC-32_integration_detail_produit):

Supprimer une branche local alors qu’on a des conflits de merge en cours

[RBS Cooking] Mettre à jour les URLs Git de vos projets

Procédure à mettre en oeuvre pour RBS Cooking et le dossier /projects pour chaque projet Change en local.

Manipulations à n’effectuer qu’une seule fois pour tous vos projets

Changer l’origin de /rbscooking

Dans /home/intlangf/rbscooking :

(Vous trouverez cette URL dans le dossier netapsys.rbs-change/interne.projects sur https://gitlab.netapsys.fr/)

Changer l’origin de /projects

Dans home/intlangf/projects (le repository qui détient tous les settings de tous les projets – à ne faire qu’une fois, donc…) :

(Vous trouverez cette URL dans le dossier netapsys.rbs-change/interne.projects sur https://gitlab.netapsys.fr/)

Manipulations à répéter pour chacun de vos projets

Rebrancher votre repository local vers le nouveau repository distant (https://gitlab.netapsys.fr)

Dans le dossier local qui contient votre projet (exemple : /home/intlangf/change30/accastillage) :

Vérifier l’intégrité des URLs dans le change.xml de votre projet

Pour les modules versionnés sous GIT

Remplacer :

par le nouvel URL que vous trouverez dans le dossier netapsys/rbs-change/ sur le repository distant https://gitlab.netapsys.fr/ :

/!\ SUPPRIMER VOTRE LOGIN de l’URL :

Pour les modules versionnés sous SVN

Remplacer :

par le nouvel URL se présentant sous la forme https://svn.netapsys.fr/webedit4/wfrepo/modules//branches/ :

/!\ Pour l’ensemble des modules versionnés sous SVN, rajouter un attribut vcs= »svn »

  • ch compile-config
  • git status
  • git add change.xml
  • git commit -m « « 
  • git push origin master

Changer les settings par défaut du projet

Opération à effectuer obligatoirement

Ouvrir le fichier defaults.py relatif à votre projet dans un éditeur :

et remplacer :

par le nouvel URL du projet que vous trouverez sur le repository distant https://gitlab.netapsys.fr/ :

/!\ SUPPRIMER VOTRE LOGIN DE L’URL

Commiter les modifs :

  • git pull
  • git status
  • git add
  • git commit -m
  • git push

Opération facultative

L’opération suivante est facultative. Elle vous servira éventuellement pour d’anciens projets si votre mise en intégration/production bloque sur les modules concernés, mais c’est normalement dans le change.xml (voir https://wiki.netapsys.fr/grand-est/web/interne/rbscooking/start/update_git_urls#verifier_l_integrite_des_urls_dans_le_changexml_de_votre_projet) que ces informations doivent être consignées et seront prises en compte par cook.

Pour info :

  • la mise en intégration du projet Accastillage qui sert d’exemple dans cette doc est passée alors que j’ai supprimé les lignes ci-dessous du fichier defaults.py.
  • pour visualiser un sample des infos que doit contenir un fichier defaults.py, allez dans default/sample/settings/.

ATTENTION : les URLs dans les deux bouts de code ci-dessous ne sont pas forcément justes. Les vérifier depuis votre navigateur.

AVANT :

APRES :

Commiter les modifs :

  • git pull
  • git status
  • git add + fichier settings.py modifié
  • git commit -m
  • git push

Mise en intégration

Les URLs d’intégration de vos projets ont changé également.

Dans projects//settings ouvrir int.py.

Remplacer l’URL sous « hostname » : « «  par l’adresse IP du site en intégration.
(pour obtenir l’IP d’un site à partir de son URL, taper « dig « ).

Pour accastillage :