Git Travail parallèle sur le dépôt local

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour. :)

J'ai souvent entendu dire qu'avec Git, on pouvait travailler simultanément sur plusieurs améliorations localement grâce au système de branches. Seulement même en créant des branches, les fichiers modifiés affichés par git status sont visibles depuis n'importe qu'elle branche. Du coup, ça casse un peu le truc du travail parallèle, on ne sait pas quelle modification correspond à la branche courante, celles-ci sont communes. :/

Une commande spéciale, je m'y prends mal ? ^^"

Merci ! ;)

Édité par Maluna34

+0 -0

Je pense que c’est parce que tu n’as pas commité tes changements dans une des branches que tu utilises. À chaque fois que tu veux changer de branche assure toi d’être dans un état propre, c'est à dire

  • de ne pas avoir des fichiers propres à cette branche non trackés
  • de ne pas avoir des fichiers modifiés dans ta staging area non commités

Cette image peut t’aider à comprendre les différents niveaux : Image utilisateur

L’interêt de la staging area est de pouvoir organiser tes commits comme tu le veux. C’est un peu déroutant si tu viens d’un autre VCS — ça impose une étape supplémentaire pour commiter, mais c’est tellement pratique une fois habitué.

Un point qui peut être sujet à débats, mais quand je travaille en local, je n’hesite pas a utiliser plus de branches et de commits que nécessaire pour bien séparer et échelonner mon travail, l’interet de git c’est qu’une fois que je suis satisfait du résultat je peux nettoyer mon repo local à coup de rebase et pusher le tout sur le repo distant.

Édité par nax

+1 -0
Auteur du sujet

Merci pour ta réponse ! :) Pour ce qui est du staging area, pas de soucis ça fait plus d'un an que j'utilise git. Mais là je m'intéresse plus particulièrement au travail parallèle, c'est à dire le travail sur 2 fonctionnalités en même temps par exemple.

À chaque fois que tu veux changer de branche assure toi d’être dans un état propre

Ben justement, on perd tout l'intérêt. Le dépôt devant être propre, le commit doit être fait, donc plus de travail parallèle. :( Ce qui m'intéressait, c'est d'avoir ma branche 1 sur laquelle je travaille une fonctionnalité et qui me dise avec git status "fichiers x et y à indexer". Et puis que je puisse, sans même avoir fini, passer sur ma branche 2 et que le git status me dise "là on a le fichier w à indexer".

Pas possible ? Quand Git dit travail parallèle, c'est uniquement la gestion de l'ordre d'ajout des commits dans la branche à pusher en fait, c'est ça ?

Édité par Maluna34

+0 -0

Cette réponse a aidé l'auteur du sujet

Mais là je m'intéresse plus particulièrement au travail parallèle, c'est à dire le travail sur 2 fonctionnalités en même temps par exemple.

À chaque fois que tu veux changer de branche assure toi d’être dans un état propre

Ben justement, on perd tout l'intérêt. Le dépôt devant être propre, le commit doit être fait, donc plus de travail parallèle. :(

Oui tu es obligé de commiter avant de changer de branche, il n’y a pas de moyen d’indiquer à git que les modifications que tu as faites appartiennent à telle ou telle branche sans commiter. Il existe cependant bien un moyen de contourner ce problème avec l’utilisation du stashing qui permet justement de sauvegarder tes modifs dans une stash que tu peux récupérer plus tard. Le problème est de ne pas mélanger les stash (attention les fichiers non trackés — les nouveaux fichiers par exemple — ne seront pas stashés.

Si tu utilises git régulièrement tu peux lire le cours « git book » qui couvre bien l’usage que l’on peut faire de git (disponible en français aussi mais je ne sais pas ce que vaut la traduction).

Source:Maluna34

Édité par nax

+1 -0
Auteur du sujet

Ok merci, c'est beaucoup plus clair maintenant.

Une autre petite question : lors d'un travail sur une autre branche, quelle la différence entre un merge local avant de pusher et un push de la nouvelle branche avec merge sur github au moment du pull request ?

+0 -0
Staff

Cette réponse a aidé l'auteur du sujet

N'hésite pas a faire de petits commits dans tes branches. Ainsi tu n'aura pas de scrupule à basculer. Si un morceau n'est pas fini tu peux effectivement utilisé le stashing mais c'est pas le plus propre.

Au pire du pire une autre solution est de faire un commit, même si ce n'est pas complet, basculer sur ta deuxieme branche pour faire ta deuxieme fonctionnalité, et quand tu revient sur la premiere finir tes modifs, commiter et re-écrire l'historique en combinant les deux commits en un seul. Utilise par exemple git rebase -i qui va te permettre de fusionner ou supprimer certains commits.

lors d'un travail sur une autre branche, quelle la différence entre un merge local avant de pusher et un push de la nouvelle branche avec merge sur github au moment du pull request ?

Je ne suis pas surs d'avoir bien compris. Une PR sur Git Hub correspond à une demande de merge. Tout l'interet est quand tu dev a plusieurs car cela permet de commenter et faire des codes review. Apres que tu merge au final par le bouton sur github (qui n'est pas dispo si il y a des conflits) ou en local+push, cela ne change rien. Quand tu dev seul, le seul interet des PR est probablement pour avoir un lieu qui résume toutes les modifs qui ont été apportés plutot que de décortiqués les commits qui peuvent être nombreux pour une seule fonctionnalités.

+4 -0

Au pire du pire une autre solution est de faire un commit, même si ce n'est pas complet, basculer sur ta deuxieme branche pour faire ta deuxieme fonctionnalité, et quand tu revient sur la premiere finir tes modifs, commiter et re-écrire l'historique en combinant les deux commits en un seul. Utilise par exemple git rebase -i qui va te permettre de fusionner ou supprimer certains commits.

Kje

À noter que git commit --amend permet d'"ajouter" les nouvelles modifications (celles du staging) au précédent commit (ce qui est plus simple que de rebaser après coup, si tu as fait un commit partiel). Attention si le commit précédent avait déjà été push sur le repo distant, il faudra forcer le push suivant (git push -f).

+0 -0

À noter que git commit --amend permet d'"ajouter" les nouvelles modifications (celles du staging) au précédent commit (ce qui est plus simple que de rebaser après coup, si tu as fait un commit partiel). Attention si le commit précédent avait déjà été push sur le repo distant, il faudra forcer le push suivant (git push -f).

AlexRNL

Oui et non. Il faut penser à ajouter les fichiers etc avant. Et c'est le même principe que git rebase -i "HEAD^2" plus edit du commit précédent. :)

Voir même, mieux : git reset "HEAD^". Tu dépiles le dernier commit, tu fais ta tambouille, et tu push force si jamais t'as pushé avant. ;)

Au pire du pire une autre solution est de faire un commit, même si ce n'est pas complet, basculer sur ta deuxieme branche pour faire ta deuxieme fonctionnalité, et quand tu revient sur la premiere finir tes modifs, commiter et re-écrire l'historique en combinant les deux commits en un seul. Utilise par exemple git rebase -i qui va te permettre de fusionner ou supprimer certains commits. Source:Kje

Le stash est aussi fait pour ca, mais faut faire attention en le manipulant, certes… faut aussi préciser qu'on peut même split un commit avec cette commande. :)

Édité par Talus

"Meh." Outil de diff PHP : Totem

+0 -0
Staff

A noter que même si le force permet de passer si le push a déjà été fait, il vaut mieux éviter de pushet avant. La raison est que les commits re-ecrits ne seront pas effacé sur le serveur distant. Vous pourrissez donc le dépôt avec des commits dont aucune branche ne pointe.

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte