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

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 !

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 :

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.

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 ?

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 ?

Merci beaucoup pour les précisions !

À 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).

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.

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.

Et surtout après ca peut être une merde sans nom (aka un gros bordel, car git est hyper puissant… voir même parfois trop :D) pour un type qui utilise votre boulot.