Bonnes pratiques git
colas_
Membre
Bonjour !
Je voulais savoir quelles sont vos pratiques git, et s'il y a des bonnes pratiques.
Je m'interroge en particulier sur les branches et sur la branche master (l'utilisez-vous ?).
J'ai l'impression que la création d'une branche peut permettre de sauvegarder l'état d'un projet. Est-ce vrai et n'est-ce pas un détournement d'une fonction de git ?
(autrement dit : est-ce que c'est fait pour ça ?)
Comme je suis informaticien amateur, il me manque (entre autres) les connaissances "culturelles", les bonnes pratiques, les choses que parce qu'on a vu quelqu'un le faire (par exemple, son chef de projet), on fait pareil !!
À l'usage, je trouve que git n'est pas si extraordinaire que ça (ps : je suis seul sur mon projet).
J'aimerais un outil qui puisse me transporter dans le temps et me montrer facilement comment était mon projet il y a x temps : une sorte de timeMachine !!
Merci !
Réponses
Les branches peuvent servir à plein de choses, cela dépend de comment tu préfères travailler. GIT est assez ouvert là dessus. Mais, tout comme avec SVN, une branche reste plutôt un embranchement dans la vie de ton projet, plutôt qu'une sauvegarde de l'état de ton projet (pour ça y'a les commits et surtout les tags)
Créer une branche peut permettre :
- De commencer un développement d'une feature de ton côté, isolé dans ta branche, pour travailler sans déranger ceux qui bossent sur le master. Quand tu as fini et est satisfait de ta grosse killer-feature que tu viens de rajouter, tu peux alors fusionner ta branche (merge) avec le master pour rappatrier sur le master tout ton travail fait sur la branche. Personnellement c'est surtout comme cela que j'utilise les branches.
- De gérer plusieurs lignes de vie du développement de ton application, comme la ligne de vie "develop" pour le développement en cours, la ligne de vie "release" pour toute la phase d'intégration en release, la ligne de vie "hotfix" pour tous les travaux à faire à chaud pour très rapidement corriger des bugs critiques déjà en production, ... c'est le modèle que propose de suivre git-flow, certains aiment d'autres non
Pour des idées et présentations de divers workflows possibles qui sont souvent utilisés avec GIT, cette page est est bon point de départ.A côté de cela, les commits permettent de faire des étapes incrémentales dans ton développement. Les tags permettent de tout simplement nommer des commits (en GIT, un tag n'est rien d'autre qu'un joli nom de ton choix qui pointe sur un numéro de commit), ce qui est utile par exemple pour marquer une version comme "v1.0" ou "v2.1" dans ton cycle de développement, et pouvoir y revenir plus facilement plus tard sans fouiller dans la tonne de commits que tu as fait. Un tag est une milestone si tu veux, un point de repère marquant dans ton développement.
Du coup, ton TimeMachine, bah tu l'as, c'est même aussi à ça que sert GIT à la base (comme tout système de versionning).
- Tu veux retourner à la version v1.0 que tu avais taguée il y a 10 jours ? Rien de plus simple, dans SourceTree, clic-droit sur le tag "1.0" et tu choisis "checkout tag 1.0".
- D'ailleurs, que tu aies tagué le commit / l'état de ton projet auquel tu veux revenir ou pas, ça ne change rien, puisqu'encore une fois un tag n'est qu'un joli nom qui pointe sur un commit.
- Tu veux revenir sur l'état dans lequel était ton projet il y a 10 jours ? Sélectionne le commit correspondant (celui fait il y a 10 jours qui correspond à l'état dans lequel tu veux revenir) et clic droit -> "checkout to this commit". (Que le commit soit tagué avec un joli nom ou pas en fait ça change rien, le nom de tag sert juste pour toi pour mieux t'y retrouver et marquer les commits qui te semblent significatifs mais ça t'empêche pas de revenir à n'importe quel commit en arrière, tagué ou non)
Je t'invite à regarder un peu les tutos sur https://www.atlassian.com/git/tutorial ça fait un tour rapide mais qui me semble pas trop mal foutu pour te mettre dans le bain.
Merci Ali, pour cette réponse !
Je prends le temps de la lire demain
Gitflow est vraiment pas mal comme principe. À user et abuser :-)
Merci pour vos réponses.
@Ali : dans la version française de SourceTree, c'est "récupération...". Je n'avais pas encore utilisé les tags, je vais m'y mettre ! Et... oui, ça marche, j'ai réussi à revenir à état précédent de l'appli. Je me dis que ça va être pratique pour la prochaine appli, histoire de récupérer les premiers stades du développement (ex : mise en place de cocoaLumberJack, etc.)
@yoann : pour l'instant je n'ai pas vraiment compris git-flow. Peut-être pour plus tard. Pour l'instant, c'est sûr que quand je veux "clore" une branche, j'ai plusieurs steps à suivre (changer de branche, puis fusionner). git-flow automatise cela, c'est ça ?
Alors que si tu utilises une interface en anglais pour avoir la terminologie/le vocabulaire anglais (commit, push, pull, tag, checkout, ...), même si tu changes d'outil, passe à Tower, à Xcode, ou autre, ou que tu vas sur GitHub... tu retrouveras tes petits car ça sera toujours les mêmes termes pour les même actions, donc moins de risque de ne plus retrouver comment faire ceci ou cela
La possibilité de revenir à un état précédent de l'appli est très pratique, par contre je ne suis pas sûr que ce soit adapté à l'usage que tu évoques :
- C'est pratique pour revenir en arrière voir comment c'était avant, si tu as une régression ou un bug qui n'était pas là avant et est réapparu, ou si tu as supprimé une fonctionnalité ou un gros bout de code de ton code source et que tu veux le récupérer...
- Par contre revenir au début de ton projet juste pour t'en servir comme base pour la prochaine appli, pourquoi pas, mais partir d'un projet existant pour faire une autre appli totalement différente, c'est pas toujours idéal : il faut changer à la main toutes les valeurs que Xcode a automatiquement générées quand tu lui demandes de créer un nouveau projet et lui files le nom du nouveau projet, comme par exemple le PRODUCT_NAME ou le INFOPLIST_FILE et tout plein de Build Settings basés sur le nom du projet / de l'appli ou de clés dansle Info.Plist, etc, etc...
Je te conseille plutôt de :- Soit te faire des templates de projet Xcode (bon, c'est pas super bien documenté comme feature, se faire ses propres templates compatibles Xcode pour que quand tu fasses "File > New Project" il te propose tes templates et que ça marche, c'est tip top mais faut chercher un peu car y'a pas trop de doc officielle)
- Soit de te faire des Code Snippets dans Xcode (ça c'est bien plus simple, l'interface de Xcode est très simple pour ça), comme ça t'as tes bouts de code tout prêts et réutilisables quand tu veux mettre les quelques lignes à mettre dans ton AppDelegate pour CocoaLumberjack ou quoi
- Mais encore mieux, je te conseille fortement l'utilisation de CocoaPods (cocoapods.org), qui est un outil très puissant pour intégrer des librairies tierces à ton projet avec une facilité déconcertante (depuis que je m'y suis mis je ne m'en passe plus).
En gros avec CocoaPods, tu listes dans un fichier (le "Podfile") les librairies que tu veux, tu ouvres un terminal et te met dans le dossier où se trouve ton xcodeproj, tu fais "pod install" et c'est tout, t'as ton nouveau projet tout prêt, configuré tout pour toi automatiquement, et tu n'as plus qu'à écrire juste le code de ton appli !Au final tu te retrouves avec un workspace contenant toutes les sources des libs tierces (celles que tu as demandées dans ton Podfile, genre CocoaLumberjack) dans un projet "Pods.xcodeproj" que tu n'as normalement pas à toucher, et ton projet avec juste ton propre code d'un côté (MonAppli.xcodeproj) à côté, pas pollué par le code des libs du coup.
Ca t'évite d'avoir tout mélangé, toi tu ne travailles que sur le code qui est dans ton projet MonAppli.xcodeproj.
De notre côté on est passés de plusieurs heures lors du lancement d'un nouveau projet (à préparer un workspace, récupérer les dernières versions de chaque composant manuellement à gauche à droite en allant retrouver les sites ou dépots GitHub, intégrer les fichiers des libs proprement dans notre workspace, ajouter les flags pour ARC/non-ARC ou autre, ajoutes les bons frameworks, ...) à juste 5 minutes (le temps de lister les libs qu'on veut dans le Podfile et lancer la commande quoi), gain de temps + que considérable !!
Et plus fort encore, lorsqu'en cours du projet tu te dis "ah tiens j'aurai besoin d'un composant qui fait ça" :
- D'une part tu peux faire "pod search trucmuche" dans le Terminal, et il va lister tous les composants qu'il connait qui contiennent le terme "trucmuche" dans leur nom ou leur description, ça permet déjà d'avoir une idée des composants qui existent
- Et quand tu as trouvé ton bonheur (ou si tu connais déjà le nom du composant qui t'intéresse), tu as juste à le rajouter dans ton Podfile et à faire "pod update" pour qu'il mette à jour le projet Pods.xcodeproj pour inclure la lib que tu as ajoutée, toute configurée comme il faut et tout.
Bref, CocoaPods c'est magique et c'est que du bonheur :PDu coup certes il existe une ligne de commande éponyme, qui permet de faciliter toutes les suites d'opérations courantes qu'on fait quand on suit la philosophie git-flow, comme une commande pour quand tu commences à travailler sur une nouvelle feature, qui va du coup revenir sur la branche principale si tu n'y étais pas déjà , te créer la branche dédiée pour cette feature à partir de cette branche principale, basculer dessus, etc.
Bien sûr, ces étapes qu'il automatise, d'une part tu peux les faire avec les commandes GIT standard, mais en plus ça n'a du sens que si tu suis le modèle / la philosophie / méthode de travail proposée par git-flow. Sinon autant utiliser les commandes GIT standard et faire ta sauce dans ton coin ^^
Après rien n'impose de suivre les concepts proposés par git-flow. D'ailleurs, je ne te le conseillerai pas forcément tout de suite, même si je trouve ça super " parce que j'utilise GIT tous les jours et ai mis en pratique GIT sur plein de projets donc ai déjà eu affaire à plein de cas d'usage et au cycle de développement type d'un projet " pour un débutant en GIT qui n'est pas encore bien familier avec tout cela, ça fait peut-être un peu beaucoup de concepts à assimiler.
Déjà , utiliser GIT dans son usage standard, à faire des petits commits de ton code régulièrement (préfère des commits de quelques fichiers tous les jours par exemple plutôt que d'attendre des lustres avant de faire un méga commit, ça sera mieux ensuite pour suivre l'avancement de ton projet petite étape par petite étape ou pour revenir en arrière sur un point précis dans ton historique...), utiliser les tags, utiliser un peu les branches quand tu sens que tu vas travailler sur un gros truc et risque un peu de tout casser par exemple, t'entraà®ner à utiliser les commandes GIT, naviguer dans l'historique...
Après quand tu seras à l'aise avec la terminologie GIT (branche, tag, tout ça) et à quoi correspond chaque chose, il sera temps de passer aux choses intéressantes comme git-flow pour encore mieux comprendre tout intérêt que propose les conventions qu'il propose :P
- Tu démarres un projet, tu codes dessus, bref il est bien avancé
- A un moment tu veux implémenter une nouvelle fonctionnalités, disons l'écran de préférences, tranquillement dans ton coin
- Mais après qques heures et commits passées sur l'écran de préférences, tu as un appel du client, qui dit "on a une demande urgente, abandonnez tout ce sur quoi vous bossez, maintenant la priorité c'est de passer toute l'interface en rose fluo"
- Tu pestes contre ce client aux goûts et priorités bizarres qui n'a aucune notion que t'étais en plein chantier en train de bosser sur un truc, mais finalement tu cèdes
- Tu mets donc de côté ta super fenêtre de préférences, et passes du coup du temps sur cette nouvelle priorité "interface rose fluo"
- Quand tu as fini de tout mettre en rose fluo, tu chausses tes lunettes de soleil pour pouvoir continuer à travailler sans être ébloui et tu livres au client pour qu'il soit content
- Du coup tu peux revenir à ta fenêtre de préférences, et finir de la coder pour la prochaine version de l'application, même si le client l'avait oublié tellement il était en train d'admirer le nouveau coloris
Si tu fais tout ça sans jamais faire de branches, tu vas te retrouver dans ton historique de GIT avec juste une seule branche ("master") et plein de commits à la queue-le-leu. Mais surtout, tu vas avoir un problème quand le client va te demander de passer sur sa super feature "ui-rose-fluo" en urgence, car ton code sera en plein chantier (et même peut-être ne sera pas en état de compiler ou bien tu avais encore plein de crash à régler vu que tu étais encore en plein dedans et n'avais pas fini).Et même si ton code n'est pas si en chantier que ça et que ça compile et ne crash pas, si tu codes par dessus ce code en cours de fenêtre de prefs la feature "ui-rose-fluo", quand tu vas livrer cette version rose au client, elle va contenir un bout de fenêtre de préférences non finie (et le client va te remonter des bugs dessus car même si tu lui aura répété 5 fois il n'aura pas compris que cette fenêtre de préférences partielle qu'il a eu dans sa version rose n'était pas finie et que tu bossais encore dessus)...
Bref, un gros boxon.
Alors que si tu utilises les branches à bon escient, tout devient plus facile.
D'ailleurs c'est une des règles imposées quand tu choisis de travailler avec les conventions de git-flow : créer une branche à chaque fois que tu commences une nouvelle feature, pour ne pas perturber la branche principale tant que ta feature n'est pas prête.
Le principe est simple :
- Tu as ta branche "master" qui représente l'état stable de ton application, où tout ce qu'il y a dedans est fini et fonctionne (y'a pas de truc "en chantier" quoi).
- Quand tu commences une nouvelle feature, comme ta fenêtre de préférences, tu crées une branche, appellons-la "prefs"
- Tant que tu travailles sur cette feature, tu commites sur cette branche "prefs". Pendant ce temps, la branche "master" n'est pas affectée (c'est comme si elle ne "voyait pas" tes commits, ils sont seulement dans leur coin dans la branche "prefs"). Tu codes, tu compiles, tu testes, tu commites, tout comme tu le ferais habituellement, tu es juste sur une branche dédiée.
- Une fois que tu as fini ta fonctionnalité, tu peux faire un "merge" (c'est à dire une fusion) de ta branche "prefs" sur le "master", pour intégrer l'ensemble de tous tes commits et de tout ton code sur lequel tu as travaillé concernant cette feature, et que ce code se trouve intégré à la branche principale
---Si on reprend notre petite histoire, cela donnerait un historique de commit GIT représenté par le graphe suivant (chaque lettre représente un commit, le temps s'écoule de gauche à droite) :
Détails de chaque étape (et lien avec l'histoire) :
- commits A, B : quelques étapes préliminaires, tu mets en place ton projet, tes quelques premières lignes de code, l'histoire n'a pas encore commencé.
- Tu veux commencer à travailler sur la fenêtre de préférences. Tu as donc créé une branche "prefs" à partir du commit B (donc une branche qui se base sur l'état du master tel qu'il est au moment du commit B ) pour commencer à travailler sur la base de ce code. (NB : à ce moment-là , la branche "ui-rose-fluo" que tu vois sur mon graphe en ASCII-Art n'existe pas encore " elle apparait avant "prefs" dans mon dessin parce que sinon ça aurait fait un graphe avec des croisements à la fin, mais c'est tout ^^ ce n'est pas lié à l'ordre de création des branches dans notre histoire)
- commits C, D, E : tu écris du code pour implémenter ta fenêtre de préférences. Par exemple tu commences par créer ta fenêtre, mettre en place un peu ton XIB et ton interface, premier commit C, puis tu rajoutes un peu de code derrière tes IBActions pour implémenter 2-3 trucs et tu commites (commit D), tu changes un peu ton XIB car finalement tu changes d'avis, et tu recommites (commit E)... ça avance et tu as écrit pas mal de code et fais de nouveaux fichiers dans ton projet, mais bon pour l'instant y'a pas grand chose qui marche dans cette fenêtre de prefs
- Le fameux coup de fil du client arrive, il te faut abandonner ce que tu faisais sur les prefs. Tu vas devoir repartir de l'état stable que tu avais en B et changer toutes les fenêtres en rose.
- Evidemment, tu ne vas pas commencer à coder ce passage en rose sur la branche "prefs" car tu incluerais alors déjà dans cette future version rose ton code partiel-pas-encore-fini de fenêtres de préférences.
- Tu ne vas pas non plus "revenir en arrière dans l'historique" au sens d'annuler tout ce que tu as fait (remonter dans le temps jusqu'à la date où tu avais fait ton commit B ), car tu ne veux pas non plus perdre ton code que tu as commité en C,D,E
- Mais par contre tu peux revenir sur la branche "master", branche qui n'intègre pas encore tes commits C,D,E et n'est pas pollué par ton code encore en chantier, et à partir de là créer une nouvelle branche "ui-rose-fluo" et basculer dessus. Tu as toujours ta branche "prefs" dans un coin qui t'attend bien sagement, elle existe toujours mais maintenant tu as basculé sur une nouvelle branche, et ta branche active sur laquelle vont se faire tes prochains commits jusqu'à nouvel ordre sera "ui-rose-fluo".
- D'ailleurs pendant ce temps, si jamais tu as d'autres personnes qui travaillent sur ce projet, ils peuvent très bien eux aussi avoir créé des branches pour leurs propres features, ils ne seront pas perturbés par tout ça non plus, et de même leurs chantiers en cours ne perturberont pas ton travail qu'ils n'auront pas encore intégré à la branche master. Ou alors si entre temps (le temps que tu fasses tes commits C,D,E) ils ont terminé leur feature à eux et l'ont intégré au master, bah c'est pas grave, tu baseras ta nouvelle branche "ui-rose-fluo" non pas sur B mais sur un commit B' correspondant au merge de leur branche sur le master, mais s'ils ont mergé leur branche sur le master c'est qu'ils avaient fini toute leur feature et que le code que tu as en B' est un code stable, pas du code en plein chantier.
- Commit F, G, H : Tu travailles sur cette absurde feature de passer toute l'interface en rose fluo. Tu passes 2 fenêtres en rose, tu commites (F) " et comme tu as basculé sur la branche "ui-rose-fluo" qui est maintenant ta branche active, ce commit se fait sur cette branche et pas sur le master ni sur la branche "prefs" que tu avais commencée), tu reposes tes yeux 2-3h, tu passes 3 autres écrans de ton appli en rose, tu commites (G, encore sur la même branche), tu vas vomir, tu termines à passer en rose le dernier écran, tu commites (H)
- Maintenant que tout est horrible comme le voulais le client et que tu as fini de tout passer en rose, la feature est finie, ce n'est plus en chantier, tu vas pouvoir l'intégrer à la branche principale. Tu peux donc faire un "merge" de la branche "ui-rose-fluo" dans la branche "master" pour récupérer sur le master tout le travail que tu as fait sur cette "feature" d'interface rose fluo. Tu vas résoudre les éventuels conflits que tu pourrais avoir lors de ce merge (si par exemple qqun a poussé de nouveaux commits sur la branche "master" entre temps qui rentrent en conflit avec certaines lignes de code que tu as toi aussi modifiées), et commiter ce merge. C'est le commit I.
- Maintenant que cette corvée est finie, tu vas pouvoir revenir sur ta fenêtre de préférences que tu avais laissée en plan. Donc rebasculer sur la branche "prefs", pour y retrouver ton code tel que tu l'avais laissé avant le coup de fil du client, et continuer là où tu étais rendu. Tu termines de coder tes IBActions, tu commit ça en J, tu peaufines les derniers ajustements, tu commites ça en K
- Et quand tout est prêt et que la feature n'est plus en chantier mais prête à être intégrée, tu peux merger ta branche "prefs" dans la branche "master" pour récupérer sur le master toutes ces merveilles que tu as fait pour les préférences de l'appli. Si tu vois des conflits tu les résouds, sinon tant mieux, et au final tu commites ce merge en L
- Ah et puis 1h après tu te rends comptes que certes ce que tu as mergé en L dans la branche "master" ça marche bien, c'est bien une version stable, mais tu as juste oublié de passer ta fenêtre de préférence en rose fluo elle aussi (tu n'avais pas encore la fenêtre quand tu travaillais sur cette satanée feature ui-rose-fluo, et tu as oublié ce détail quand tu es revenu sur la fenêtre de prefs...), bon, ça vaut p'tet pas le coup de faire une branche pour ça quand même, tu restes sur le "master", tu changes directement le backgroundColor dans PrefsViewController.xib, et tu commites ça directos sur le "master", commit "M"
- Il est temps de livrer une version au client, donc tu lui fais un beau paquet cadeau, et tu en profites pour créer un tag sur ce commit "M" pour accoler à ton commit une étiquette avec un nom un peu plus sympa que ça, comme par exemple "Version 1.0", comme ça tu t'y repèreras plus facilement dans le futur si tu dois revenir en arrière dans l'état dans lequel était ton code à l'époque de cette livraison 1.0
- Et pour finir après tant d'efforts, tu vas boire une bière à ma santé, parce que tu l'as bien mérité si tu as pris le temps de lire tout mon roman jusque là
Voilà , j'espère qu'avec cet exemple concret tout s'éclaircira et que l'intérêt des branches sera plus clair pour toi !C'est quoi ce post Ali ?
Fais un tutoriel, ça prendra moins de temps !
Pfff, à 1h10 du matin en plus.
Idem que muqaddar
Sinon, la discussion et les réponses ont l'air très intéressantes...
Moi qui pour l'instant, ne fait que des commits sur le master, les branches, j'évite encore, mais vu le détails des explications et les informations diverses...
Wow !!!
Merci !
OK j'irai boire une bière à ta santé... rue de la soif ?
À propos du passage E -> F, est-ce différent de faire :
(1) check-out en B puis création d'un nouvelle branche
(2) changement de branche puis création d'une nouvelle branche
Perso, je fais (2) mais c'est juste pour savoir !!
Une chose que je fais :
j'ai un fichier encours.rtf dans mon projet, où je décris ce que je fais, classé dans des rubriques (Archi, Interface, Modèle, Moteur, etc.). Quand je commit, je n'ai qu'à faire un copier/coller de ce fichier !
CocoaPods a l'air pas mal du tout !!
Je garde ça en tête.
Merci Ali !
C'est quoi la différence entre "checkout" et "changer de branche" ?