Discussion :

[Tamari444]

Bonsoir, je me permets de poster ce message car j'aimerais mieux comprendre l'utilisation de Git.
Je suis étudiant en BTS Services informatiques aux organisations et j'utilise Git dans la plupart de mes projets pour la gestion des versions et pour pouvoir travailler de chez moi lorsque les cours sont terminés. Cependant, pour certaines actions, je ne sais pas comment m'y prendre et je ne sais pas s'il existe de meilleures façons de faire ou des façons plus pratiques que celles que j'utilise actuellement. Voici quelques exemples concrets :

J'ai cru voir qu'il était possible de faire plusieurs commits avant de pousser une branche sur le dépôt distant, mais je ne comprends pas l'utilité d'avoir recours à plusieurs commits. (Si je pouvais avoir un petit exemple, je comprendrais peut-être mieux). Dans mon cas précis, chaque soir, j'avance sur mon projet C# qui utilise des Windows Forms et dès qu'il est tard, je fais un commit et je pousse sur la branche distante de ma fonctionnalité. Cependant, je progresse à mon rythme et je ne termine pas forcément une fonctionnalité en une seule soirée, ce qui signifie que je me retrouve avec plusieurs commits successifs sur ma branche distante. Est-ce que cela peut poser problème ? Lorsque j'ai enfin terminé ma fonctionnalité et que je fais mon dernier push sur ma branche distante, je décide de fusionner ma branche de développement distante avec ma branche principale, et jusqu'à présent, je n'ai pas eu de problème.

Faut-il conserver ses branches de développement distantes pour garder une trace des anciens changements ? (J'ai vu que c'était une option à cocher lors de la fusion de ma branche de développement avec ma branche principale, donc je me posais la question).

Concernant les branches de fonctionnalités, une branche correspond dans mon projet à une Windows Form, mais je ne sais pas si je dois encore plus découper mes fonctionnalités et créer plusieurs branches pour chaque petite fonctionnalité de ma Windows Form, ou si cela suffit.

Je ne comprends pas bien l'utilisation de la commande "fetch". J'ai l'habitude de faire un "git clone" au démarrage de mon projet sur un PC, puis de travailler avec des "git add", "git commit" et "git push", et ensuite sur un autre PC de faire "git pull" et de répéter les commandes pour pousser de nouveaux commits après avoir ajouté du code. Faut-il que j'intègre "fetch" dans ma routine de développement ?

Quelle est l'utilité de la commande "stash" ?

Voilà mes questions pour le moment, j'en ai sûrement d'autres mais elles ne me viennent pas à l'esprit pour l'instant. J'attends avec impatience vos réponses et je remercie ceux qui prendront le temps de lire et de répondre à mes questions.

[binarygirl]

Bonjour,

Je ne vais pas répondre à toutes les questions mais:

BJ'ai cru voir qu'il était possible de faire plusieurs commits avant de pousser une branche sur le dépôt distant, mais je ne comprends pas l'utilité d'avoir recours à plusieurs commits. (Si je pouvais avoir un petit exemple, je comprendrais peut-être mieux). Dans mon cas précis, chaque soir, j'avance sur mon projet C# qui utilise des Windows Forms et dès qu'il est tard, je fais un commit et je pousse sur la branche distante de ma fonctionnalité. Cependant, je progresse à mon rythme et je ne termine pas forcément une fonctionnalité en une seule soirée, ce qui signifie que je me retrouve avec plusieurs commits successifs sur ma branche distante. Est-ce que cela peut poser problème ?

Non, c'est normal qu'une branche aie plusieurs commits.
Moi-même je ne pushe pas après chaque commit. Ca m'arrive parfois de vouloir réviser le dernier commit, et si on a déjà fait un push entretemps ça peut coincer car ça peut être une source de conflits potentiels.
Il ne faut pas avoir peur de faire des commits à chaque fois qu'on a effectué un changement notable dans le code (un jalon). Dans certaines organisations, on mentionne même un numéro d'issue Redmine, Jira ou autre dans le commit pour faire le lien avec les issues. Et pour chaque issue, il peut y avoir plus qu'un commit car on ne fait pas toujours le travail en une fois.

Accessoirement, le push sur un remote repo constitue un backup en soi: si par malchance votre PC crashe, au moins vous ne perdrez pas ce qui a déjà été pushé.

Faut-il conserver ses branches de développement distantes pour garder une trace des anciens changements ? (J'ai vu que c'était une option à cocher lors de la fusion de ma branche de développement avec ma branche principale, donc je me posais la question).

Il n'y a pas de bonne réponse à mon avis. Et si en plus vous êtes seul à travailler sur le repo, vous êtes libre d'en décider. Vous pouvez au contraire décider que c'est de la pollution et que garder l'historique du contexte n'est pas utile.

Concernant les branches de fonctionnalités, une branche correspond dans mon projet à une Windows Form, mais je ne sais pas si je dois encore plus découper mes fonctionnalités et créer plusieurs branches pour chaque petite fonctionnalité de ma Windows Form, ou si cela suffit.

En général je raisonne en terme de fonctionnalité ou de demande client (=issue). Concrètement, une demande ou un feature ne correspond pas forcément à un form, ça peut être plusieurs (et aussi des fichiers liés). Là encore c'est du cas par cas, ça dépend de ce que vous êtes en train de développer. Mais d'habitude je n'ai que un ou deux branches de dév en parallèle, à côté de la branche master, et je merge dès que c'est bon. Il n'est pas utile d'avoir une multitude de branches ouvertes, surtout si elles portent sur la même demande.

Quelle est l'utilité de la commande "stash" ?

Pour faire simple, c'est de mettre de côté du code ou des changements que vous ne voulez pas committer, mais vous pouvez les ressortir plus tard.

[sevyc64]

mais je ne comprends pas l'utilité d'avoir recours à plusieurs commits.

En simplifiant, un commit est un instantané de ton code que tu "grave dans le marbre" à l'instant t. Quoique tu fasse par la suite dans ton code, tu as sauvegardé l'état de ton code à cet instant t. Et si les modifs que tu as faites depuis ne conviennent pas tu peux les annulées en revenant à ce commit.
Pousser ton(es) commit(s) sur le serveur distant, c'est essentiellement pour partager ce code là avec tes collègues. Accessoirement aussi ça sert de copie de secours si tu venais à crasher ton dépôt local, ou ta machine (à condition que le dépôt distant soit pas sur la même machine).
Evidemment tu peux avoir plusieurs commit sur ton dépot local si tu veux te sauvegarder des étapes dans l'avancement de ton développement, pour pouvoir revenir en arrière facilement si besoin.
Evidemment, tu n'as pas forcément besoin/envie que chacune des étapes soient partagées avec tes collègues surtout si le code, en l'état n'est pas terminé et ne leur apporte rien.

Par contre perso je m'applique une règle de base, pas forcément respectée dans toutes les structures, je ne commit jamais, sauf si c'est expressément nécessaire (absence prévue, collègue qui reprend le dev, etc...) un code qui ne compile pas.

chaque soir, [...] je fais un commit et je pousse sur la branche distante de ma fonctionnalité. [...] je me retrouve avec plusieurs commits successifs sur ma branche distante. Est-ce que cela peut poser problème ?

Non, il n' y a pas de raison.
Tu travaille seul tu fais ce que tu veux. Quand tu travaille en équipe, tu applique les règles de l'équipe. Et beaucoup d'équipes mettent en place une règle de base qui est de systématiquement pousser son travail de la journée sur le dépot distant car on ne sait pas de quoi sera fait le lendemain.

Faut-il conserver ses branches de développement distantes pour garder une trace des anciens changements ?

Pas de règles, c'est selon le besoin tes règles, les règles de ton équipe, etc...
Si tu te moque de l'historique, tu peux supprimer les branches, si l'historique est important tu conserve les branches. Tu peux aussi généralement supprimer les branches mais vouloir en conserver certaines sur des dev particuliers. Tu peux aussi les conserver un certain temps puis les supprimer au bout de x jours, x mois, ou x versions.

mais je ne sais pas si je dois encore plus découper mes fonctionnalités et créer plusieurs branches pour chaque petite fonctionnalité de ma Windows Form,

Rien en t’empêche d'avoir une branche avec plusieurs fonctionnalités, tu gère comme tu veux (ou selon les règles de l'équipe si tu es en équipe).
Pour moi, perso, la granularité la plus fine d'une branche est que lorsque le dev de la branche est terminé, c'est à dire que tu peux fusionner, fermer, supprimer ta branche, le résultat doit être livrable.
Après perso, j'aime bien ne pas mélanger les dev dans une même branche. Je fais, par exemple, une branche par bug que je corrige.

Je ne comprends pas bien l'utilisation de la commande "fetch".

Fetch vs Pull : en fait Pull = Fetch + Merge.
Fetch récupère les commits du dépôts distants que tu n'as pas encore dans ton dépôt local, mais ne les appliquent pas au code que tu es en train de modifier. Pour les appliquer, il faut faire en plus un merge et gérer les éventuels conflits.
Pull fait les 2 à la suite en une seule commande.
Généralement Pull est plus utilisé que Fetch.

[Obsidian]

Bonjour et bienvenue

Bonsoir, je me permets de poster ce message car j'aimerais mieux comprendre l'utilisation de Git.

C'est le bon endroit pour le faire. :-)

J'ai cru voir qu'il était possible de faire plusieurs commits avant de pousser une branche sur le dépôt distant, mais je ne comprends pas l'utilité d'avoir recours à plusieurs commits.

En fait, comme expliqué par binarygirl, le fait de pousser ou tirer une branche vers un serveur effectue de fait une copie d'une machine vers l'autre mais ce n'est pas l'objet premier de Git. Git est avant tout un logiciel de versioning comme il en existe de nombreux autres (rcs, cvs, svn, Mercurial, Bitkeeper, Fossil, Monotone, darcs…).

L'objectif principal d'un tel outil est de tenir la trace des différentes versions d'un document ou d'un projet donné, le plus souvent le développement un logiciel (pour lesquels ces outils ont été conçus). Cela signifie que tu peux très bien te servir de Git uniquement en local, sans jamais faire de push/pull vers un serveur distant. Il restera tout autant pertinent de pouvoir retrouver facilement l'état de ton logiciel à tous les stades de son développement, spécialement lorsque tu sortiras des versions stables, que tu marqueras alors avec des tags spéciaux comme « v1.0 », « v1.1 », « v2.0 », « release_speciale », ou n'importe quoi d'autre.

Cela signifie également que tu n'es pas obligé d'utiliser des branches en soi. Il y en a forcément au moins une, la branche principale, nommée main, master, default ou quelque chose d'assimilé, mais tu peux tout-à-fait t'y tenir si tu développes tout seul et que tu n'as pas besoin de partager ton travail. Si tu utilises git pull / git push pour synchroniser ton dépôt local avec un site distant où tu travailles pendant la journée, cela marchera fort bien mais Git ne le verra que comme « un dépôt distant » (car il peut y en avoir plusieurs…) et ne fera pas la différence entre un dépôt censée être « une copie officielle à synchroniser » et le site officiel d'un projet collaboratif que tu aurais cloné et auquel tu souhaiterais contribuer. Cela fonctionnera de la même façon.

C'est pour cela que tu te retrouves avec une branche locale et une branche distante. Elles vivent toutes les deux leur vie propre de chaque côté. On peut les paramétrer pour indiquer à Git que l'une est officiellement faite pour suivre l'autre, ce qui lui permettra de savoir où chercher les informations lors de pushs ou pulls implicites si le dépôt distant n'est pas indiqué, mais synchroniser deux branches revient toujours in fine à fusionner une branche dans une autre.

C'est aussi légèrement différent de l'approche adoptée par d'autres logiciels, spécialement CVS et Mercurial. Donc, si tu as déjà travaillé avec ceux-là, on pourra peut-être s'y attarder dans le prochain post.

Quoi qu'il en soit, même en développant de cette façon, tu vas de fait te retrouver avec une série de plusieurs commits sur ta branche si tu en dépose un chaque soir et que tu ne fusionne ta branche qu'à intervalles réguliers. Par contre, Git va être particulièrement souple de ce côté car c'est exactement ce pourquoi il a été conçu, et c'est en partie pour cela qu'il a fini par être unanimement adopté au dépit de pratiquement tous les autres :

Si tu travailles sur un gros projet collaboratif, dans lequel des centaines voire des milliers de développeurs sont déjà impliqués — au hasard le noyau Linux, car c'est pour lui que Git a été développé, et par le même auteur — tes contributions seront en fait des amendements portés à un projet déjà fonctionnel. Par conséquent, on exigera que chacune d'elle soit non seulement testée, mais parfaitement documentée car elle t'engagera (ce qui est d'ailleurs la définition du mot « commit ») mais parce que l'on aura besoin de la localiser facilement en cas de problème, et de comparer les versions si un bug a été introduit et que l'on ne sait pas encore par quelle révision.

Pour cela, depuis 1991, le projet Linux fonctionne en utilisant une (immense) mailing list sur laquelle on communique, mais où l'on envoie également des patches, générés avec diff et proprement formatés, à raison d'un mail par patch. Lorsque l'on veut soumettre un changement assez conséquent, on soumet une série de patches numérotés par exemple « [1/4], [2/4], [3/4], [4/4] », chacun modifiant une notion propre, indépendamment des autres patches et des fichiers qu'ils ciblent (par exemple « tous les commentaires », ou « remplacement d'une clé », ou « renommage d'une série de fonctions », etc). Ceci permet au mainteneur du sous-système visé d'accepter ces patches ou de les refuser s'ils ont besoin d'être améliorés. Si ces patches sont bien distincts entre eux, cela permet au mainteneur d'en accepter la plupart tout en refusant ceux qui posent problème. Sinon, le bloc entier sera rejeté.

Et c'est là que Git entre en scène : on va d'une part te demander de préparer tes commits aussi proprement que le seraient ces patches pour la bonne raison que ces patches vont effectivement devenir des commits lorsqu'ils seront acceptés et intégrés dans l'historique, mais également parce que tu vas toi-même les recevoir au prochain git pull, comme tous les autres développeurs. Et là, en parcourant l'historique, chaque commit indiquera clairement ce qu'il change et tu sauras que le changeset qui lui sera associé concernera intégralement et uniquement ce changement. C'est aux antipodes d'avoir un seul commit avec un tas de changement en vrac simplement marqués « travail du jour », même si c'est malheureusement comme ça que travaillent encore la plupart des équipes de développement.

Et pour cela, il faut avoir un logiciel qui nous permette de faire cette opération facilement. Et il se trouve que la plupart des autres logiciels de versioning n'en étaient pas capables. Depuis CVS, le modèle consistait surtout à marquer un fichier comme suivi en l'ajoutant à la liste avec « add », moment à partir duquel la totalité de ses changements étaient systématiquement enregistrées en même temps que ceux de tous les autres fichiers suivis à chaque commit.

C'est pour cela que Git, au contraire, va te demander de faire un git add sur chaque fichier à chaque commit, même s'il sont déjà suivis : pour te demander ce que tu comptes enregistrer précisément dans chacun des commits. Tu peux même, à terme, utiliser git add -p pour te permettre de sélectionner précisément, dans chaque fichier ou dans l'ensemble des développement du jour, ce que tu veux sélectionner, le reste restant en suspens. Il est même possible, ensuite, d'amender le dernier commit en date si l'on a oublié quelque chose (proposé par la plupart des autres SCM également) mais également de fusionner plusieurs commits, d'en sélectionner certains ailleurs, de ré-agencer ta branche, de la filtrer, jusqu'à reconstruire entièrement son contenu, jusqu'à obtenir quelque chose de parfaitement propre.

Une fois ce stade atteint, il est assez rare que l'administrateur d'un projet te laisse directement écrire dans le dépôt officiel (ailleurs que sur tes propres branches). À la place, tu vas mettre la branche à intégrer en ligne et tu vas généralement émettre une « pull request » de façon à ce que l'administrateur l'examine et l'intègre de lui-même (via un pull, donc) s'il lui plaît. Raison de plus pour qu'elle soit irréprochable dès le départ.

Faut-il conserver ses branches de développement distantes pour garder une trace des anciens changements ? (J'ai vu que c'était une option à cocher lors de la fusion de ma branche de développement avec ma branche principale, donc je me posais la question).

Pas forcément, surtout si elle a été officiellement fusionnée, auquel cas elle sera forcément accessible ad vitam æternam depuis la branche principale. En revanche, tu as travaillé longtemps sur une voie et que tu as choisi de revenir en arrière, c'est bien de laisser une référence dessus pour ne pas perdre le travail effectué, même s'il est devenu inutile entretemps.

Concernant les branches de fonctionnalités, une branche correspond dans mon projet à une Windows Form, mais je ne sais pas si je dois encore plus découper mes fonctionnalités et créer plusieurs branches pour chaque petite fonctionnalité de ma Windows Form, ou si cela suffit.

Ce n'est pas nécessaire en effet. Le moto de Git a été un temps « le plus de branches possibles, le plus vite possible »… parce que jusqu'ici, gérer des branches était une plaie. Lors d'une présentation publique, Linus Torvalds avait d'ailleurs posé deux questions à son auditoire :

1. Qui a déjà géré des branches avec CVS ?
2. Qui a aimé ça ?

… si bien qu'en plus du reste, la plupart des gens avaient pris l'habitude de ne jamais s'écarter de la branche principale. En pratique, maintenant, il est assez rare, sauf besoins spécifiques, qu'un développeur donné gère plus d'une ou deux branches — à la fois — en plus de la branche principale.

Je ne comprends pas bien l'utilisation de la commande "fetch". J'ai l'habitude de faire un "git clone" au démarrage de mon projet sur un PC, puis de travailler avec des "git add", "git commit" et "git push", et ensuite sur un autre PC de faire "git pull" et de répéter les commandes pour pousser de nouveaux commits après avoir ajouté du code. Faut-il que j'intègre "fetch" dans ma routine de développement ?

Sous Git, git pull est littéralement un git fetch suivi d'un git merge. Donc si tu utilises git pull, tu fais déjà implicitement un git merge.

L'idée est justement de permettre à l'utilisateur de rapatrier l'état courant du serveur distant et de l'explorer sans avoir à l'intégrer directement sur sa branche si l'on est en train de travailler dessus.

Quelle est l'utilité de la commande "stash" ?

« stash » veut dire « remiser » et cela te permet de mettre temporairement de côté les modifications que tu as faites dans ton dépôt et que tu n'as pas encore enregistrées. Tu vas en avoir besoin lors que tu voudras utiliser git checkout dans un dépôt où tu as des modifications en suspens.

git checkout te permet de rappeler une version donnée de ton historique (ce qui est d'ailleurs tout l'intérêt de faire des commits). En faisant cela, Git va ramener le contenu de tous les fichiers suivis dans ton dépôt à l'état qu'ils avaient lors que tu as enregistré la version en question (et laisser intact tous les fichiers non suivis). Tant que ces fichiers n'ont pas été modifiés, cela ne pose aucun problème : lorsque l'on revient au dernier commit en date (au sommet de la branche), on retrouve bien la version la plus récente de chaque fichier, comme si on ne s'était jamais déplacé.

Par contre, si tu as déjà des changements en cours sur certains fichiers, Git va te dire qu'il ne peut pas effectuer le déplacement car cela écraserait le contenu qui n'a pas encore été sauvegardé, et il va donc te demander de l'enregistrer d'abord, ce qui peut être fastidieux si tu as de gros développements en cours (ce qui, au passage, est aussi une bonne raison de commiter souvent).

De là, si tu as quand même besoin d'explorer le dépôt (par exemple pour y retrouver d'anciennes informations à nouveau nécessaires aujourd'hui), deux solutions : soit tu clones ton projet dans un répertoire à part uniquement pour pouvoir l'explorer, soit tu enregistres tout ce que tu es en train de faire dans un commit en vrac uniquement pour pouvoir te déplacer et tu l'annules ensuite. Aucune de ces approches n'est satisfaisante.

git stash va te permettre de faire exactement la dernière opération, mais automatiquement : Git va prendre tout ce qui est en suspens et effectuer un commit sur une branche spéciale, nommée « stash ». Juste après cette opération, ton dépôt sera marqué comme propre et tu pourras te déplacer à loisir. Une fois revenu à ton point de départ, git stash pop va faire exactement l'opération inverse : annuler le dernier commit et re-marquer les changements en cours comme étant non enregistrés. Tu pourras alors reprendre ton développement là où tu l'avais laissé.

À noter que comme à chaque appel, tous les changements en question sont enregistrés au sommet de la branche « stash », celle-ci fonctionne comme une pile : tu peux donc sauvegarder tes modifications en cours, faire des mouvements, faire d'autres modifications et les sauvegarder à nouveau, te déplacer une nouvelle fois, etc. À chaque fois, git stash pop dépilera les dernières modifications enregistrées. Il existe aussi les commandes git stash apply pour rétablir des modifications enregistrées à un niveau arbitraire sans les dépiler ou, au contraire, git stash drop qui permet d'abandonner des modifications temporaires devenues obsolètes entretemps.

C'est très pratique mais il est fréquent, au départ, d'oublier que l'on a enregistré des modifications. Il arrive même qu'on les réécrive et que, par conséquent, elles fassent double-emploi. Donc n'hésite pas à utiliser git stash list de temps en temps pour t'assurer que la pile est bien vide.

Voilà mes questions pour le moment, j'en ai sûrement d'autres mais elles ne me viennent pas à l'esprit pour l'instant. J'attends avec impatience vos réponses et je remercie ceux qui prendront le temps de lire et de répondre à mes questions.

Elles seront les bienvenues ici.
Bon courage.